Source Code Control
in [Embedded]
|
From: Richard Phillips on 8 Nov 2006 03:51 Tom Lucas wrote: > In the past our source code control has been based largely around CD > backups and individual's memories of why a change was made and where > the source is stored. I think the time has come whereby a more ordered > method of control needed but I do not want to add a big administrative > burdon to my development processes. > > We are a small R&D department and only one of us is ever likely to be > working on a piece of code at any one time and there are no major > approval processes to be integrated. However, we do produce special > cuts of code for most customers so we have an awful lot of slightly > different versions of the same software that need to be stored in a > manner that can keep on top of it. > > What method/package would people recommend? I've read through the > "Alternatives to Visual Source Safe" thread from July and people there > seemed to advocate CVS/SVN and PVCS. Noone seems to like VSS. > > I would need something that would run on Windows, because the > department is not readed to get nixed up just yet, and I would prefer > it to be cheap/free. I would like to avoid any unnecessary complexity > because I don't envisage the size or number of our projects to change > hugely in the medium term to take advantage of it. > > I could probably survive with a restricted access drive on a network > server with a database/spreadsheet recording what is stored. Perhaps I > could implement a "live" production area and a "development" area and > only the QA director would have access to move development builds into > the live area for release. > > What do you reckon? > > Thanks > Tom Another vote here for Subversion. I have used VSS for years and have a few years experience of ClearCase. I am currently trying to migrate (by winning "hearts and minds"!) our dept to Subversion (from VSS). I've never had any reliability issues with VSS myself, but I found it was weak in a few key areas. If you are new to version control then you probably won't know what I'm on about, but VSS is very poor when it comes to branching support. The more you use version control, the more you will come to appreciate good branching support :) Anyone who's ever tried to make a version controlled minor modification to an old (i.e. not "latest") version of software without interfering with the latest version of code in the database, using VSS will know where I'm coming from. Also, in Subversion the check-ins are versioned "per change" rather than "per file" as in VSS. Much nicer. I've been experimenting with Subversion for months and have been very impressed with it. There are still one or two things I find slightly quirky but that's the same with any new product until you get used to it... R.
From: Tom Lucas on 8 Nov 2006 05:12 "Steve at fivetrees" <steve(a)NOSPAMTAfivetrees.com> wrote in message news:BImdne48dojaQs3YnZ2dnUVZ8sadnZ2d(a)pipex.net... > "toby" <toby(a)telegraphics.com.au> wrote in message > news:1162913592.709382.186890(a)e3g2000cwe.googlegroups.com... >> Tom Lucas wrote: >>> "toby" <toby(a)telegraphics.com.au> wrote in message >>> >>> > - atomic commits (incl renaming), unlike CVS >>> >>> I'm not entirely sure what that is. Does it mean you can rename a >>> file >>> in a project without having to roll the build number of the whole >>> project? >> >> Every change to a Subversion repository increments the revision >> number. >> CVS does not support rename operations at all; Svn implements renames >> (on directories or files) as a history-preserving copy plus a delete >> of >> the original object, wrapped in a transaction. CVS cannot commit a >> group of changes in a single revision (transaction). >> >> Atomic commits allow you to group related or interdependent changes >> and >> thereby aid consistency (e.g. buildability) of your code base at any >> moment in time. > > Atomic commits also mean that the entire commit operation runs, or > none of it. In other words, something like a network glitch won't wind > up with a broken repository. > > Subversion gets my vote too. I'm in the process of converting a > SourceSafe environment to Subversion (using the svnserve stand-alone > server, rather than the web DAV version), and it's going fine. > Everyone in the dept likes Subversion with TortoiseSVN, and we've > noticed immediate benefits (no locked files, better log history > viewing, etc etc). > > Tom, are you in the UK? If so I'd be happy to talk on the phone. Maybe > I can help... We're using an OpenBSD server for the repo store (on a > RAID array, backed-up nightly), and it was trivially easy. I imagine a > Windows installation would be similarly easy, but I've no experience > there... I certainly am in the UK and I'd be delighted to talk to you about it. I assume your number on the website is the one to call - when is good for you? > Steve > http://www.fivetrees.com >
From: David Kelly on 8 Nov 2006 10:01 Grant Edwards wrote: > > There's a huge, basic flaw in VSS's design. It's a single, > monolythic, database file with no centralized server or > control. All of the clients bang away individually at the > database file. If one client glitches the whole thing crumples > to the ground like a house of cards. To which I wish to add that some here have advocated the same client-fileserver approach when using SVN/CVS. I recommend one set up a proper server so that only one application is modifying the archive rather than a multitude of possibly different clients. When running client-fileserver every user has to have permissions to modify every file in the archive. When running client-server only the server daemon has to have complete access to the archive and the users have to access thru the daemon. For me the 95% solution has been to host CVS on FreeBSD via ssh. TortoiseCVS for Windows clients. MacOS comes with CVS preinstalled. BBEdit does CVS (and now SVN) also. SVN would be a 99.9% solution but I'd have to start doing things a bit differently. I wouldn't recommend anyone start anew with CVS.
From: Grant Edwards on 8 Nov 2006 10:05 On 2006-11-08, toby <toby(a)telegraphics.com.au> wrote: > Yet they still sell VSS to customers! Why haven't they been > sued into oblivion for selling something that doesn't work? It's simple: Microsofts customers don't _expect_ software to work. Working with Microsoft products over the years have lowered the customers expectations so far that you can walk up to them, poke them in the eye with a sharp stick, and they'll Say "thank you!" and write you a check for an upgrade to a sharper stick. > Is it plastered in enough disclaimers? Losing or botching up > source code is extremely costly... Yes, it is. >> For my use, I think it is important that I can trust my source >> code control system. ... the very fact that people think that >> using VSS for years without losing data is impressive or >> unusual would turn me against it. Yes it would. -- Grant Edwards grante Yow! It's hard being at an ARTIST!! visi.com
From: toby on 8 Nov 2006 10:17
David Kelly wrote: > Grant Edwards wrote: > > > > There's a huge, basic flaw in VSS's design. It's a single, > > monolythic, database file with no centralized server or > > control. All of the clients bang away individually at the > > database file. If one client glitches the whole thing crumples > > to the ground like a house of cards. > > To which I wish to add that some here have advocated the same > client-fileserver approach when using SVN/CVS. I recommend one set up a > proper server I have always used Apache to serve Svn. This brings several advantages including fine grained access control, logging, SSL, the very handy ability to reference the latest revision using URLs (e.g. I serve latest product documentation to users directly from the repo, instead of a separate copy), and it also constitutes the platform for an enormous variety of related products (Bugzilla, Trac [includes an integrated Svn repo browser], FishEye, ViewVC, WebSVN, or whatever strikes your fancy. Two other crossplatform Subversion client interfaces that haven't yet been mentioned here are SmartSVN (http://www.smartcvs.com/smartsvn/) and RapidSvn (http://rapidsvn.tigris.org/). > > ... I wouldn't recommend > anyone start anew with CVS. Agreed. The http://subversion.tigris.org/ home page makes a nice summary of why not. |