Fog Creek Software
Discussion Board




What do you use for version control?

This topic may have already been discussed at length, but I can't seem to find it at the moment, so please point me in the right direction if you can.

I have used RCS and CVS a long time ago (still on DOS and OS/2) and have been using CS-RCS for occasional version control of mostly Word-documents, because of its integration with word.

Lately I have had to do some coding again and started of with CS-RCS for that too. But I am not completely satisfied and am curious if there are alternatives that might fit my needs even better.

What do you use and why do you prefer it over other tools? Hopefully your experience leads me to a better match...

Erik

Erik van Linstee
Friday, May 24, 2002

You can search for "cvs" in the handy search feature.  Are the discussions good enough there?

MH
Friday, May 24, 2002

I've been using plain old CVS from cvshome.org. Most of our developers use a mix of desktops. I personally use UNIX, so a cl system with different front ends was a good solution.

Unfortunately, CVS itself is full of bugs, issues, and poor merging. I've been trying to drum up internal support to rewrite it as a web service using XML markup, but so far other projects have kept me too busy. Anybody have anything that is more flexible that runs on both UNIX and Windows?

Dustin Alexander
Friday, May 24, 2002

I've used CVS quite a bit and I don't understand what you mean by "CVS itself is full of bugs, issues, and poor merging".  What things cause you problems? As for "drum up internal support to rewrite it as a web service using XML markup" I can only ask, are you serious? It's not as easy as it may look. If you want to see what an alternative looks like you could try subversion http://subversion.tigris.org/. They've been writing a cvs replacement for a year, with several full time developers and they are still not done. Of course if you have lots of money there is always ClearCase from Rational, I'd stay away from Source Safe from Microsoft, I know people who have lost updates etc.

Alex Moffat
Friday, May 24, 2002

CVS has nearly no bugs. It doesn't always do what you want (e.g., repeat merge is 100% manual and not easy to get right; it can't store "renames" within the repository) but these are not bugs.

Personally, despite its various shortcomings, I've been very happy with CVS as it does do well within its realm, and it has useful add-ons that do most things  I need (web based browsing, "cvs annotate").

If you're looking for alternatives ....

On the free software front, you have Subversion, from the same people who brought you CVS; They describe the project as an attempt to do cvs right (with the 15 years of experience they now have), rather than to innovate - see [ http://subversion.tigris.org ].

There's also 'arch' from Tom Lord - [ http://regexps.com ]; It's much more ambitious, handling distributed repositories, arbitrary branch topologies etc. It's unix centric, but there's a cross platform Perl port underway.

Commercially, there are StarBase, BitKeeper, Perforce and ClearCase that I'm aware of; Of these, everyone that uses any of the first three swears by them, and some also swear by ClearCase. Of these, as far as I know only BitKeeper supports distributed branchs. StarBase has a very-well integrated issue tracking system (it's _extremely_ helpful when the bug database and version control database are always in sync), as does ClearCase. Perforce just plain works (This is what Microsoft uses internally).

Disclaimer: Of the commercial alternatives, I have played with StarBase, but not enough to claim familiarity, and haven't even had this little experience with the other packages.

Ori Berger
Friday, May 24, 2002

Sorry for the unintended deception. What I meant by CVS being full of bugs is that it often acts unpredictably. This is more of a result of the multiple non-friendly front ends that are available in the open source community for dealing with CVS and is not CVS' fault in particular.

I also find it difficult to manage the CVS back end file system, especially if you have little or no knowledge of the file system dynamics. In my mind, developing a purely IT solution as opposed to an OS flavored solution would be easier to manage for current industry professionals. As it is right now, I'm the only one in our company who can work with it [the server]. We consist mostly of senior level programmers who 'don't have the time' to learn 'new fangled techniques'.

What I would like to see is a system that is network manageable and supports modern protocols with a modular and easily extensible base. Something that is so easy to slap a front end on that you don't have to understand any system variances to do so. CVS is good as far as it goes, but its an old technology that is in desparate need of renovation for the new age.

Also, about rewriting it. Yep. I'm serious. We've got the intellectual assets to back it up internally. Its just the justification I'm looking for. That and the time. Seems like the problem of scarcity dominates every layer of our current sphere.

I've been watching the subversion project for quite some time, although not closely. Anyone actually put the thing into production or test environments?

Dustin Alexander
Friday, May 24, 2002

Sorry about the 'problem of scarcity' comment in advance. My brain is currently an oil and water mix of philosophy and computer science and someone is shaking me.

Dustin Alexander
Friday, May 24, 2002

CVS *is* being rewritten, it's now called Subversion.  The authors have been hacking on CVS for years, and provided much of the useful development on it in the past few years.  It's about to go Alpha, and has some wonderful features.  I'd be willing to bet than in two years, there won't be any question as to the best version control system.

James Montebello
Friday, May 24, 2002

There is also "arch" an up and coming revision control system with a lot of nice features.  Although  it is not particularly mature yet, it is quite useable already.

www.regexps.com

Robert Anderson
Friday, May 24, 2002

<< I also find it difficult to manage the CVS back end file system, especially if you have little or no knowledge of the file system dynamics >>

I don't think any statement could have been more confusing for me. Of all available version control systems (except, possibly, arch), CVS's back end file system storage is by far and large the easiest to understand and (here even arch isn't a contender) the easiest to manipulate.

<< In my mind, developing a purely IT solution as opposed to an OS flavored solution would be easier to manage for current industry professionals >>

That's probably true, but the reason is that current industry professionals are unprofessional. Let me rephrase what you're saying: "I prefer an opaque system I have no undertstanding of, and which I cannot manipulate, over one which uses the well tested, well understood, heavily debugged, widely supported, file system structure". Or do you have a specific setup in mind that is based on something more ubiquitous than a file system?

<< We consist mostly of senior level programmers who 'don't have the time' to learn 'new fangled techniques'. >>
File system? "new fangled"? Seems like we're not working in the same industry.

<<  What I would like to see is a system that is network manageable and supports modern protocols with a modular and easily extensible base. Something that is so easy to slap a front end on that you don't have to understand any system variances to do so. >>
OK now I really, really am at loss. CVS is as network-managable as it gets - you can do 99% of the things through TCP connections (pserver), and the rest are pure file system manipulation (which are also as network-managable as it gets).  What does a protocol being "modern" have to do with anything? It's well documented (though it does have its quirks), it's working, it has several implementations, including libraries you can just plug into your software and use - even though IMHO 'cvs.exe' is the best encapsulation you can have.
YOU CAN'T SLAP A FRONT END WITHOUT UNDERSTANDING THE SYSTEM.  I know it's hard to grasp, but unfortunately, that's the way it is. If you don't handle the specifics in the front end, you either pass them to the user (bad), or deprive the user of real functionality (worse). You can't even use a system properly if you don't understand it. This is always true, but especially so for version control, where things like merge conflicts cannot possibly have a "well defined" resolution.

Check out the explanation of star topology merges and merging of independently advancing branches in the arch documentation, for an example - it goes to great lengths to do "the right thing", but sooner or later you'd have to know _exactly_ what it does or you'd find it "unpredictable" again. And while it is basically simple, the devil is in the details.

<< Also, about rewriting it. Yep. I'm serious. We've got the intellectual assets to back it up internally. Its just the justification I'm looking for. That and the time. Seems like the problem of scarcity dominates every layer of our current sphere. >>
This assertion is not backed up by the rest of your post. CVS has got one thing basically wrong (the fact that tags, branches and revisions are distinct notions), a thing or two somewhat wrong (project wide operations like tagging take time proportional to project size), and a thing or two inconsistent, but all in all it doesn't get many things wrong - most of the implementation details within this framework are very well done. You actually haven't said what it is that you find unpredictable about CVS - being a long time CVS user I know how to use it and it's thus very predictable for me. Tom Lord wrote arch because he didn't like the way CVS (or subversion) did things, but he has very specific scenarios and targets he wanted to achieve.

If you find CVS file based structure confusing, you probably have much less intellectual assets to back this up than you believe. Furthermore, it makes so little business sense to write a version control system unless you plan to sell it, that I'd guess you're working for a government or academic institution which doesn't really have to justify these kind of investments.

Find out what it is that really troubles you about CVS, and solve that problem, possibly through a CVS frontend (and/or any of the other existing tools instead of CVS). This is, for example, what 'mcvs' does - it's a CVS front end that versions metadata (file names, directory names, permissions, etc). It's two hundred lines or so - much less than rewriting would take. It also shows how modular CVS effectively is. There's also a backend module for CVS called nserver that isolates authentication and authorization so that the cvs pserver doesn't have to run with broad permissions and isn't tied to the underlying operating system user list in any way.

CVS and others are showing their age, both negatively (flexibility) and positively (robustness). Unless you have an idea for fundamentally different dynamics (the way BitKeeper and arch did, for example), use an existing version control system - it makes much more sense.

Ori Berger
Friday, May 24, 2002

Thanks for the post. Lots of interesting ideas to pursue.

I think my major problem with CVS is that its fragile. I'm not speaking from a personal standpoint, although I do not claim to be an industry leader in version control theory.

I'm speaking from the implementation standpoint that you refer to when you speak of requiring an understanding of the system in order to function. Currently the way it works is that a person who has no understanding of the system will most definitely break it, either by doing false imports or performing another brain dead error that breaks the repository. The system is not in any way robust or 'idiot proof'.

You see, I don't necessarily agree with your point. I think a versioning system could well be implemented transparently, so that developers do not even know they are working with it. Requiring a deep understanding of system functions is poor UI. I'm not arguing that nobody in the project needs to understand the system, I'm saying that there has to be a way to design a system that does not require significant understanding by all participants to function. Moreover, I'm saying there may be a way to allow users to adapt a front end without having significant understanding of the back end. This is what interface logic and web services/XML are all about.

I spend most of my day working with self adaptive systems that don't require a whole lot of user intuition or maintenance in order to function. Another issue that I have with CVS is that its robustness seems to depend a great deal on the robustness of the underlying file system. It is in no way capable of maintenance and self repair, something that gets on my nerves. If you've ever had to manually go through and hex edit a repository to deal with linefeeds for different systems, you'll understand what I mean. Such a process is so trivial that its automation should be a foregone conclusion.

In the end, I'm not saying CVS does not work. I've been using it for a few years now and I'm happy with the results that versioning has had on our quality of work. I'm simply saying that there is still room for groundbreaking improvements in the areas of robustness, fault tolerance, and simplicity. I'm not posting this stuff as flame bait. I'm actually very interested in people defending the current system, as again I am by no means an expert on these matters.

As for my organization, we do not waste time and money like inefficient groups such as goverments and we are not enitrely profit oriented. Our goals are far and away intellectual as opposed to material. It would be worth the effort to implement just about anything if I could come up with an improvement argument for the group as a whole. If I could walk in and tell them that we can make substantial improvements to a system, that in itself would be the number one reason for development. I am in the wonderful position of working in an environment where the pursuit of ideas is a primary goal. :)

Thanks for the time you put into that post, by the way. I am grateful that you feel strongly enough to work with me on an understanding of your viewpoints.

Dustin Alexander
Saturday, May 25, 2002

I can smell the steam rising from what must be the world's largest pile of horseshit...

Nat Ersoz
Saturday, May 25, 2002

I'm quite taken with the smell, myself. ^_^

Dustin Alexander
Saturday, May 25, 2002

Clearcase.  But it may be overkill for your needs. 

http://www.rational.com/clearcase     

Bella
Sunday, May 26, 2002

StarTeam from Starbase Corporation.

James Ladd
Sunday, May 26, 2002

Responses to three details:

1.  CVS is not full of bugs -- it's full of bug fixes.  The CVS codebase is nearly a perfect example of Joel's assertions about the fact that mature code tends to be ugly and brittle.  Its code is a nightmare, but CVS mostly does what it is supposed to do, rather well.

2.  I can confirm that writing a new version control system as a system of XML web services is a pretty big undertaking.  We're doing it here at SourceGear (see vault.sourcegear.com).  It's a big project, and we obviously plan to sell it as a product.  I can't imagine tackling something like this as an internal effort.  Very few companies could absorb the development costs, but very many companies could grossly underestimate the effort involved.

3.  As far as I can tell, there is no actual confirmation that Microsoft uses Perforce internally.  They use a tool which is called SourceDepot.  That tool is *rumored* to have been based on Perforce, but that's a very unconfirmed rumor.  My personal opinion is that the rumor is not terribly credible and has very little evidence to support it.

Eric W. Sink
Sunday, May 26, 2002

I work for a (quite small) company that has implemented its own in-house Source Code Control system. It's written in Perl, is about 10 years old, and is rather a pain to maintain (I know - I'm the one employed to maintain it).

We've been looking for some way to move from this internal system to an externally maintained one (commercial, Open Source, whatever - Perforce seems to be the favorite option amoungst those asked, having a nice does-just-what-it-says-on-the-tin simplicity about it). It's not just a case of moving our source repository between systems, though, as we have assorted scripts and utilities that use the current system. To move systems we'd have to re-write all the scripts and whatnot first.

This is where something like a SOAP interface would be good. Ideally, we could implement a set of standard SOAP functions as an interface to our system and gradually re-write all our existing code around that. What's more, we could use any nice GUI clients and utilities around that work with this standard SOAP interface.

I've been investigating a few options, and found an open-source project called SourceJammer the other day that does this sort of thing - it's a Source Code Control system that presents a SOAP interface. A SOAP-based solution seems to be simpler to implement than something like WebDAV - to document a SOAP API you just list each function, what it does and what its parameters are. WebDAV seems to need a heafty protocol-definition document as documentation, which looks like it'd take a bit of wading through.

David Hicks
Monday, May 27, 2002

Dustin Alexander:

<<If you've ever had to manually go through and hex edit a repository to deal with linefeeds for different systems, you'll understand what I mean. Such a process is so trivial that its automation should be a foregone conclusion.>>

You know that you can setup scripts to run at commit time to deal with this, right? Edit the 'commitinfo' file in your repository's CVSROOT and commit it back. Voila, automation! And it can do any sort of transformations or checks you can imagine.

Whenever I find myself doing something horribly tedious like "hex edit a repository to deal with linefeeds for different systems", I ask myself whether the smart and Lazy (in the Perl sense) people who created the system would deal with this mundane crap. Every single time, the answer has been no and the tools have been there all along, undiscovered by me.

Chris Winters
Tuesday, May 28, 2002

These points are all quite good. Playing with CVS, I think anyone would get the idea rather quickly that it is a codebase with years of work into it. It has all of the benefits of a tried and true solution, and also all of the problems. Joel says rewriting is the bane of any projects existence, but does this cover projects that were written before the very design methodologies that we use to refactor them?

A SOAP interface would be nice on a source control system. Definitely something to keep an eye out for.

I agree with you that the time it takes to implement something like this as well as it is currently implemented would more than likely cripple a small corporation. I'm hoping that one of the Open Source projects gets to it first before we feel the need to move our code base. Something like this would be a great benefit to the community. :)

Dustin Alexander
Tuesday, May 28, 2002

We currently use VSS for corporate docs as well as code.

We are moving to CVS (probably) for code and SharePoint on top of VSS for docs over the next few months.

Anonymous
Tuesday, May 28, 2002

[Dustin Alexander]
> A SOAP interface would be nice on a source control
> system. Definitely something to keep an eye out for.

  The two SCC projects with SOAP interfaces that I know about so far:

http://vault.sourcegear.com/
http://www.sourcejammer.org/

  Both say they have SOAP interfaces, but neither have documentation for them. If anyone knows of any others, please say. It looks like I might have to implement a SOAP interface for our current in-house SCC system, so a published, standard, SOAP SCC interface would be nice.

David Hicks
Wednesday, May 29, 2002

*  Recent Topics

*  Fog Creek Home