The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Subversion - is it that good?

I've noticed that a lot of people here recommend Subversion. I'm evaluating it for our company (we currently use CVS), and I can see a lot of advantages.

But there are a couple major issues that bother me. I'm wondering what you guys think -- how do you deal with them, are they really a problem, etc.

* There's no indication in the history of a file, when it gets branched/tagged/copied. So I can't look back and see, for example, that we tagged a file for release three versions ago.
  It seems like there are two uses of a tag. One is to be able to reproduce a file/directory at a certain point in time, which Subversion's copies handle. But another is to be able to indicate a specific revision number for reference. CVS handles this, but Subversion doesn't.

* As a result of this, you don't have any tools like CVSGraph, to draw a chart of the branch history of a file. This is incredibly useful to me. It looks like TortoiseSVN tries to do this, but it takes forever and generates weird results. If Subversion marked a file when it was copied, this would be much easier.

* Because Subversion doesn't have any special knowledge of branches and tags, it makes it difficult for Subversion clients to deal with them. This in turn makes it difficult for users.
  For example, Subclipse (an Eclipse client) had to come up with their own hacked-up file properties to indicate the branch structure of a project. Subversive (another one) tries to guess based on some standard layouts.

I'd like to switch to something better than CVS, but these issues are holding me back. Am I wrong?
Friday, November 30, 2007
Actually, the revision number within Subversion describes the entire repository at a given point in time, so it's actually much easier than CVS.

The thing that might be tough to get your head around is that a given file could have a set of revs that aren't sequential...  7, 102, 500 would mean that the file was changed and committed on those revs only.
KC Send private email
Friday, November 30, 2007
Switching version control system is an expensive process (in term of process adjustment). Subversion has mostly advantages with respect to plain vanilla CVS, but quite a few disadvantages compared to CVSNT (which you probably are using, since merging works well for you). If you care about merging, SVN is definitely not what you want to switch to -- git (if Unix enviroment), Bazaar and Mercurial are.

Friday, November 30, 2007
FWIW, I don't use (because I don't trust) either CVS's or SVN's merging.  I've been bitten a few times in the past when a (CVS) merge undid a bunch of changes because it screwed up the merge.  Mind, it worked fine most of the time, but every once in a while it would completely bollix things up, and they were hard to figure out just because they were unexpected.  (Pop quiz: which is worse -- a bug that occurs 10% of the time, or a bug that occurs 1% of the time?  Hint: Which would be easier to find in testing?)

Anyway, I got in the habit of using BeyondCompare ( ) to compare and manually merge my working copy into a clean copy of the repository.  This works well for me, as I know what I'm doing and can be selective about files (or even code sections) that get merged.
BillAtHRST Send private email
Friday, November 30, 2007
Currently we're using plain CVS (not CVSNT), but I do my serious merging using Eclipse's CVS client. It's the only one I trust.

I've had the occasional problem with merging in CVS on the command-line, but I was hoping Subversion was better at this. Am I wrong? I was hoping it would be at least as good (if not better) than CVS. What kind of problems have you guys had?
Friday, November 30, 2007
My experience: SVN is almost exactly plain-CVS, with efficient branching/tagging, and with less tool support, e.g. TortoiseSVN is not on par with TortoiseCVS.

If branching & tagging are your main problems with CVS, and tool support is sufficient for you -- you might as well switch to Subversion.

Personally, I recommend switching to bazaar instead. It doesn't have the tool support of SVN or CVS, but it is extremely easy to use, and the first version control system which on one hand does branching/tagging/merging correctly, and on the other hand stays out of the way.

Oh, and unlike CVS / SVN, it is easy to distribute/replicate in a variety of ways; most importantly, disconnected operation on a laptop feels the same as connected operation -- you can commit, branch, revert, merge etc, and when you do connect to the server, all this is reflected with all history in the server -- or not -- entirely up to you.

And it also has constantly improving SVN compatibility - using an SVN repository with Bazaar is easier than with Subversion.

Friday, November 30, 2007
My understanding is that subversion operates on project level (folder) rather than on file level. When we do a branch/merge, we always do it on the project level. And we assign meaningful names to tags in order to track the history of a project.
Friday, November 30, 2007
For me the problem is that CVS is supported by all the tools I have, including ones that are obsolete and yet can not be replaced. So I can't move to SVN without impeding my workflow. CVS kind of like the QWERTY keyboard, or ASCII format, it's universally supported.

I agree that CVS sucks and about the merges - I don't recall ever seeing CVS successfully merge anything that more than one person was working on. It is only successful for merging back a single set of changes.

The amount of time I spend dealing with version control is pretty substantial. The amount of time I have saved with version control because it 'saved the day' is extremely small.

I'm about ready to say that version control is not worth it for a lot of projects, and the fan boys are all wrong.
Tony Chang
Saturday, December 01, 2007
Ps - I think the essential problem is that 3 way merging is an intractable problem whenever the edits overlap. Because of this, manual merges are the rule not the exception. Therefore, version control should LOCK files, not allow unlimited checkouts. CVS AND SVN's design choices here are WRONG.
Tony Chang
Saturday, December 01, 2007
My personal experience has been using CVS and SVN for many years with some bad experience using ClearCase along the way.

In my experience if you are using CVS it makes a lot of sense to migrate to SVN because:

1) Migrating from CVS to SVN will require the least amount of training or tool migration compared to alternatives.

2) At worse, you'll run into the same number of bugs. In my experience SVN server is a less buggy than CVS.

3) The new revision numbers are much easier to work with.

4) It is my impression that tool support is actually the same for both.

5) SVN has worked flawlessly for me for everything *except* merging Visual Studio 2005 project files (which are XML based). We repeatedly encountered bad merges but it occurs infrequently enough for us to track down. I have never had merge problems with any other files (and like I said this was very rare) but it was disturbing to discover.

My personal opinion is you should migrate from CVS to SVN without hesitation and then consider future alternatives. Personally I don`t buy some of the alternatives I`ve seen so far, like ClearCase, because they were such a pain in the ass to use. SVN is fine for merging 99% of the time and for the 1% of the time it is not it is not worth dealing with all the extra overhead of ClearCase to do it.

My favorite part of CVS or SVN is the ease of use. They might not be the most powerful things in the world but they provide the best cost-benefit curve I`ve come across.
Gili Send private email
Sunday, December 02, 2007
It's worth switching to SVN from CVS for one reason: SVN versions directories. CVS doesn't. Ever need to rename a file? CVS considers it a whole new file unless you go mucking around in the repository. SVN tracks the renames. And file moves, and directory creation, etc.

Plus all the other things svn does better. ;-)
Chris Tavares Send private email
Sunday, December 02, 2007
Merging is why I really like the Eclipse CVS client. It shows you all the changes, so you can choose which files you want to merge manually, and which to merge automatically. Plus this gives you a chance to review the incoming changes.

Also, Eclipse's "pinned" synchronizations let you do repeated merges to the same branch, without having to keep track of when you last merged. So far the Subversion clients that I've seen can't match it.

I'm starting to lean toward sticking with CVS. The one Subversion feature that's really tempting me is the fast branches/tags. But that doesn't seem worth all the downsides. Maybe in a few years when it has matured.
Sunday, December 02, 2007
The next version major of Subversion will have much better merge tracking.

You might want to consider switching when it comes out.  Subversion is considerably better the CVS and, unlike CVS, is actually being improved.
Almost H. Anonymous Send private email
Monday, December 03, 2007
"Therefore, version control should LOCK files, not allow unlimited checkouts. CVS AND SVN's design choices here are WRONG."

I must disagree. I've always thought that an exclusive lock model is just a way to kill productivity for no good reason. Each to their own, of course. :)

90% of the merges I've done even VSS could handle without user intervention (and that's saying something). Most of the remainder are easily dealt with in Windiff (which every developer should know, IMHO).

However, what I'd find useful in an SCC tool would be the ability to define:

1.  File types/names which can't be automatically merged (Win32 resource and resource.h files spring to mind).
2.  Projects between which automated merges should not be made in a specific (or both) directions without user review.

Features such as the above (I'm sure we could come up with a bucketload more if we tried) can reduce the risk for the edge cases whilst letting the tools do the easy repetitive stuff.
Anna-Jayne Metcalfe Send private email
Wednesday, December 05, 2007
Windiff? Sorry...I meant WinMerge!
Anna-Jayne Metcalfe Send private email
Wednesday, December 05, 2007
Anna is correct. CVS/SVN take an optimistic view of change collisions.

Seriously, frequent, repeated collisions between developers smells like a potential project management/planning problem. I'd want to investigate why this was happening so often.
Thursday, December 06, 2007

Subversion is excellent. The command line interface is simple (compared with CVS). The UI tools (like TortoiseSVN) are good quality. SVN is virtually bullet proof.

However, at the 1,000 foot view, you might want to consider a change manager that can be used business wide. A lot of developers think they need a single repository, when the business itself should be using a single repository. Consider diagrams, ERDs, brochures, user manuals, source code, and so forth.

While SVN is great for developers, it might not meet the needs of the entire company. There are tools available that might be better suited.

For example:
Dave Jarvis Send private email
Friday, December 07, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz