SVN is missing the point?

Our company was using Rational Clearcase for version control about 6 years ago. The developers decided it was way to clunky, error prone and WAY too expensive. We introduced CVS and it has been working fine for a few years now. CVS is widely known, stable and simple. I looked into using SVN a few years ago but the clients were unusable at that time. This year, the SVN discussion came to life again and some of my collegues started playing with it after I mentioned it as being a step forward from CVS.

We’ve been using GForge for a few weeks now as an environment to keep all the project information in one place. In the light of the migration discussion from our old environment, SVN was considered because it promised to “solve” a few things for us:

  • Placing a tag on a very large (3GB) repository can be very quick
  • Updating the local copy takes less bandwith than with CVS, meaning improved performance when working remotely over a poor connection
  • SVN claims to keep the history information when moving or renaming a file (although I think that only applies if you use an SVN client to do the rename/move)

Now that we’ve converted/started a few projects in SVN, we find that SVN is maybe not an improvement over CVS after all. The SVN designers have overlooked a few very important things which professional users absolutely need. We had the following problems with SVN:

  • There is no default eclipse integration. The Subclipse plugin behaves erratic and buggy. Subversive comes with a few SVN adapters of which we are not sure which to pick. The developer side of the SVN/eclipse combo does not work “out of the box”, which adds to setup time and therefore costs money.
  • Finding all the revisions and branches of a file is hard in SVN. It requires manually browsing the repository branches and doing compares. For multiple files, this requires major knowledge of SVN and it’s tools. Needless to say, that also adds to development time, and therefore costs money.
  • Merging branches into the trunk is complicated and requires serious manual administration on the end user side as compared to CVS, see also previous bullet.
  • trunk, branches and versions are part of the directory structure. This seems a bit odd to me, because a versioning system should not interfere with my directory structure. We had a lengthy discussion on how to call and place the “trunk”, “branch” and “tag” directories. At the time it sounded good to talk about, but the more I think about it, it seems completely wrong alltogether to me. The version of a file is determined by its place in a tree? That is just plain wierd.
  • branches and tags are the same thing in SVN. This means that one could modify a tagged file, and nobody would notice without manual checking. This came as a complete surprise to me. We use CVS tags to tag software versions, and do production support based on those tags.

From all the discussion and experiences with SVN on some projects, I think I need to re-think my position on SVN. It suddenly doesn’t seem al that promising to me. CVS does have it flaws, but because it is fairly simple, we have simple workarounds and fixes for each of them. The bandwith problem is easier solved with a better connection, and finding the history of a renamed file can be solved by having a good comment in the odd ocasion that one needs to rename or move a file.

SVN positions itself as a CVS replacement, and it had me fooled for a while, but it is really not all that good from an end users perspective. I really don’t see the point of having a revision of the whole repository state, as opposed to having a version per file. That, and the fact that a lot of the SVN promises only hold up if you use the command-line SVN client, makes SVN a very weak competitor to the widely used, accepted and stable CVS.

There are a lot of rants and flames on the net about people having problems because thy “miss atomic commits” for instance. In the past 20 years of my career, they number of problems arising from commits not being atomic was not big. Most of the problems were people doing partial commits, which they could easily also have done with SVN. Most problems are not because of a tool, but because of the humans that use it, and the natural habbit of humans of making mistakes. Atomic commits solves a theoretical problem which does not lead to big problems in CVS.

The more I think about it, SVN seems to be a nerd’s implementation to a theoretical problem, whereas CVS is a pragmatic solution to a real life situation.

About these ads

19 Responses to SVN is missing the point?

  1. Guus Bosman says:

    I agree that SVN is not dramatically better than CVS. I do like the speed improvements for tagging etc, especially on (very) large repositories. Being able to rename and move files without losing version history is also nice. Personally, I find that adding a comment in CVS does not achieve the same purpose, especially when moving large amounts of files around when refactoring.

    I do think Subversion will ultimately ‘win’, and at I’m seeing more and more engineering teams take the step (my team migrated in the winter of 2006).

    Having said that, I respect your assessment. SVN is not so much better, and it does require learning a different paradigm. Especially if, as you indicated, the Eclipse plugins do not work well and the team is used to working with Eclipse, it is questionable if it’s worth for your team to upgrade now. It might be better to wait a year or two and see if the Eclipse tooling improves.

    On a lighter note: CVS is good software because it was invented at the Vrije Universiteit for the Amsterdam Compiler Kit :) http://www.cs.vu.nl/~dick/CVS.html#History

  2. rolfje says:

    Speaking of Eclipse, I think the eclipse landscape is becomming littered with all kinds of versions containing toolsets we don’t need. I loved the “basic Java Eclipse” and then extending it with plugins.

    I looked into IntelliJ, but I’m surprised that it doesn’t do on-the-fly-compilation. It is much more a (very) intelligent editor than an IDE in that respect.

    What does your team use for SVN access and how do you prevent tagged versions of the code from being modified?

  3. You are obviously entitled to your opinions, but given that you are possibly moving to SVN, I figured I would make an effort to help.

    > SVN claims to keep the history information when moving or renaming a file
    > (although I think that only applies if you use an SVN client to do the
    > rename/move)

    You certainly cannot simply move a file in the filesystem and have SVN know about it. Unless you are using something like Subclipse. In which case, Eclipse hands the move operation off to Subclipse to perform. I will point out that the main feature SVN gives you is retaining the history. It still has other problems with how it handles the move when other users changed the moved file, or you are performing merges. See this blog post as an example:

    http://markphip.blogspot.com/2006/12/subversion-moverename-feature.html

    The SVN 1.6 release hopes to improve upon this feature.

    > There is no default eclipse integration. The Subclipse plugin behaves erratic and buggy.

    I develop Subclipse. I do not think that is a fair or accurate description. If you are having problems, please come to the Subclipse users@ mailing list and report problems so we can help and fix them if there are bugs to fix. We have a major release queued up for when SVN 1.5 comes out that I think will make it the best version control plugin for Eclipse.

    > Finding all the revisions and branches of a file is hard in SVN.

    That is true. The SVN design does not lend itself to find this easily. Subclipse has a feature that lets you store some manually entered “breadcrumbs” in the repository that gives some nice UI benefits.

    http://subclipse.tigris.org/branch_tag.html

    I have personally never found this to be even a minor problem. SVN encourages you to think about trees, not files. Usually you know which branch you care about, and then you just want to see what was done in that branch. Obviously, every individual’s background of what they were doing prior to SVN impacts the way they think about this.

    > Merging branches into the trunk is complicated and requires serious manual
    > administration on the end user side as compared to CVS, see also previous bullet.

    I actually think merging in SVN is dead simple. I do not know how anyone handles this in CVS, it is way more complicated. That being said, there is an “ah-ha” moment that most people have with merge in SVN when they get how it works. I have never found the manual management of merge information difficult, but the soon to be released SVN 1.5 is all about merge and making it much simpler. We have written a new GUI merge client for Eclipse that takes advantage of this and makes merge really easy.

    See: http://merge-tracking.open.collab.net/

    You can also get the current dev version of Subclipse and the merge client there. The docs show the client as of last August. It has gotten even better since then. The download is current as of yesterday.

    > trunk, branches and versions are part of the directory structure.

    Obviously the names are up to you, but you basically say that and I know you are talking about the structure. Again, this is probably my favorite feature of SVN. It isn’t going to change, it is a pretty critical design feature. I guess if you do not like it, there is not much that can be said.

    > branches and tags are the same thing in SVN

    Well, to be honest SVN doesn’t really even have branches or tags. It has copies, and copies are aware of their ancestry etc. Branches and tags are a convention that a user of SVN can follow by using these features. Again, I find the ability to update tags to be useful, at least during the tag creation process. It is not hard to use permissions to enforce a tag policy if you are concerned about it. I prefer the “open source” way of commit emails to mailing lists and peer reviews. The entire repository is versioned, nothing can be destroyed. If someone breaks convention and makes a mistake, fix it.

    The repository revision is probably the best feature of SVN. It actually makes tags not really needed unless it is for convenience. For example, an open source project wants to be able to easily tell the consumers of its source code what its releases are. If I do not have these external consumers of my repository, then I do not even create tags. It is not hard to figure out what revision was used to build software, it is easy to embed this in the build if needed. If you know the revision, you can easily get that source, or retroactively make a branch from it to issue a hot-fix. When doing this, I prefer to follow the same policy that the SVN project does. Make the fix on trunk, then backport the revision to the branch. Then you never really have to go looking for where things are. All work is done on trunk or feature branches that are merged to trunk.

    Anyway, hopefully there is something here of use to you. If you run into problems with Subclipse, please remember the mailing list. The traffic is light enough that subscribing is not a burden. The list is moderated, so no SPAM comes through it.

    Mark

  4. rolfje says:

    Hi Mark, maybe subclipse being buggy is overstated, and partially based on my experiences with the plugin many months ago. I did notice that some developers had trouble with it. It may be that this was the same trouble I had with Subversive. I could not easily add files, I got the error message “could not add files” and when doing an update first, it worked.

    Ofcourse you should always update first, but when adding large numbers of files to a repository while somebody else is making small (fast) changes to it is a real burden, and I don’t feel the plugins are helping me solve that. This added to my frustration and frustration generally makes me exegarate my opinion (I’m like 80% of the tech guys out there in that respect).

    For reference: I’m an Apple user, and over time I’ve gotten used to things that “just work”. I expect SVN and eclipse work out of the box and be transparent, and in my opinion it is not there yet.

    I appreciate your comments and will subscribe to your mailing list. As I said we still have SVN projects and I can try subclipse on one of them to compare it with subversive.

    As for branches, judging from what you say I think it will be more fitting to our development process to have a class which can report the build number (repo version) which was used to build the software. This removes the need for tagging. Then, when a customer has a problem, we branch out from the given repo version. This will minimize the number of branches, and therefore also partially solves the “search all modifications of this file” problem.

    I’ll keep you posted.

  5. scaryreasoner says:

    Having used both CVS and SVN, but CVS since about 1997, and svn only recently, I tend to like CVS better, despite its faults.

    Is there a way in svn to do what the cvsps program does?

    (list all changesets, and generate patches from changesets or sets of changesets?)

    See http://www.cobite.com/cvsps/

    Lately been playing around with git. It’s different.

  6. rolfje says:

    I’ve always created these CVS patchsets using the eclipse GUI. I think with any SVN plugin for eclipse you will be able to do the same. I’m not too sure about the command line, I’m not a command line fan.

    CVS Patches are great, I always try to include them in the bug tracking system when I solve a bug. Because they’re human readable, I can see what I did to solve a bug by just looking in the bug tracking system.

  7. Amir says:

    I prefer svn, though I hate teaching web designers how it works!
    The gui clients are just not up to it yet (speed == slooooow)

  8. Amir says:

    Also, I think svn:externals is a much better implementation than cvs aliases, for sharing code between projects.
    svn:externals can reference other repositories, and ‘commits’ do not carry down into these ‘externals’ (auth may be different). It’s a great tool for managing codebases & bundling libraries into your code. Every time you check out or export a repository, it checks out the external library too.
    In fact, it’s the only reason i ever ‘tag’ repositories.

    As far as i remember cvs only supports ‘aliases’ within one repo, and it’s harder to manage permissions to the shared code also.

  9. Dean Laskin says:

    I 100% agree. I used cvs with Eclipse for a few years and found it workable. Now we’re using svn and I’m having to delay a release because svn somehow polluted a previous production tag with changes slated for the next release. I know I made a mistake somehow, but these kinds of things didn’t happen with cvs.

  10. Sybren says:

    It’s now about a year and a half after Rolf wrote this post, and still his complaints about Subversion are as to-the-point today as they were then. One of the Subversion developers made it quite clear: they are keeping the tags-are-branches-are-just-directories mentality.

    I prefer Subversion over CVS. Not because it’s that good, but because my favourite version control system can sync between it and Subversion. Mercurial (http://hg-scm.org/) seems to use the best of both worlds, and more.

    Tags are just tags when you use Mercurial. There is no way to “edit a file within a tag” such as you can do with Subversion, because a tag is just a name for a specific revision. Tags are stored in an easy-to-read file called “.hgtags”. It’s possible to have a commit hook on your central repository that forces the tags file to be append-only, so that you won’t be able to edit tags once they have been added.

    Branching and merging has always scared me with CVS, so much even that I’ve never dared using it. With Subversion things got a little less intimidating, but even then it is rather stupid. You have to remember which revisions you already merged, just in case you want to do another merge later on. This requires proper comments in your commits, otherwise you’re screwed. Having to do this manually is just silly.

    Branching and merging in Mercurial is a lot easier. It’s so easy, in fact, that it can often be done completely automatic. Even more important: the web interface shows the revision graph, check out http://hg.stuvel.eu/flickrapi/graph/tip?revcount=50 for an example.

    The distributed nature of Mercurial takes a little getting used to. However, I find it very pleasant to work with. It allows me to keep my commits small, even when I’m offline (working in the train, for example). It also allows me to do things that can’t be committed at once (combinations of file changes, renames, overwrites, etc. sometimes just won’t fit in a single commit, at least not with Subversion). You can commit several times and only then push the changes to the central repository for everybody to see.

    I wouldn’t know the state of the Mercurial Eclipse plugin, as I don’t use it. I use Eclipse, VIM, Visual Studio and other development tools, and I don’t want to spend time learning another UI for each of them. In other words: I just use Mercurial’s CLI interface, which is very good.

  11. G. Lohmann says:

    Coming from a debate at sourceforge.net about CVS versus SVN. First of, we once used as well used Clearcase and meanwhile switched over to SVN. I also being familiar with CVS.

    But it is really time to move on from that dead cow!

    * There is no default eclipse integration.

    I agree that some times ago the SVN integration in Eclipse was a bit fiddling but with the recent version the integration in the IDE is very smooth. If one is really unfamiliar with it it, there are tons of good HowTo’s showing that it only take a couple of mouse clicks to get it up and running.

    * Finding all the revisions and branches of a file is hard in SVN.

    Uhmm, are we talking about the same tool? Compared to CVS? I for example use TortoiseSVN and it only take me a right click on the mouse to get all the revisions of a file and even the command line of ‘svn log foo.c’ is anything then complicated.

    * Merging branches into the trunk is complicated

    Dunno, but I always been more frustrated and scared about CVS in case of branching and merging. A simple ‘svn copy trunk branch -m “creating a branch”‘ on the command line or a right click on the mouse and it is done in a blink of an eye.

    * trunk, branches and versions are part of the directory structure.

    Yes, but this doesn’t need to be an disadvantage but can indeed be an advantage. Further there is no need to check-out the whole thing. I can create a folder structure including branch, tags, trunk etc. but then only check-out the working directory below the point of interest. In other words all the other stuff is hidden. On the other side if I need to access those data for a merge or comparison it is just walking up in the directory structure. However for an enduser it is usually absolutely irrelevant how data is controlled internally.

    * branches and tags are the same thing in SVN.

    Yes and no, and even then one don’t need to bother about this specific thing. A tag is a hard link to the original source and further branches and tags can be made read-only. Even if SVN is storing this in a file structure one shouldn’t try to check-out and work on this elements. That would be a bad use behavior but not the fault of SVN. Anyway one may search for ‘svn read only pre-commit hook script’.

    * Is there a way in svn to do what the cvsps program does?

    maybe not particular in the way CVSPS does it but SVN supports Changelists. And a patch file is made as simple as a ‘svn diff > ~/patch.diff’

    Anyway the major flaw of CVS meanwhile is its age. When was the latest development of CVS and the latest security fix? Running a CVS server is a major security hole in each company. What does a tool help me if finally my project server get hacked and compromised including data loss or even worse creating an infected product that is shipped to a customer.

    just my 2 cents

    • rolfje says:

      Hi, thanks for pitching in on the discussion :-)

      In our case, the fact that SVN is not part of eclipse, and that tags aren’t really tags as they are in CVS are the reason we don’t switch. Switching costs money, and there’s little we get back for it. It’s not that SVN or GIT or Mercurial or what have you is bad, it’s just that CVS does the job for us, and switching away from it needs a valid business reason.

      The bad user behaviour is something CVS fixes out of the box, and SVN makes me tell each member of my team how to use it, which means extra time lost which could be spent on coding, discussing architecture, stuff that matters.

      Unlike you said, I actually think the strongest point of CVS is it’s age. Everybody knows how to use it, it’s well integrated in a lot of tools. CVS through SSH is as safe as SSH is, and we don’t need intricate rights systems. So where is the business value of switching to SVN?

      I look into versioning systems every now and then, and they all have nice features, but in the end of the day I just need a place to store my files, track history and tag versions, without having to explain all members in my team how to do this-and-that. I’m already struggling to get them to check in hourly instead of at the end of the week ;-)

      • Viðarr says:

        Coming from the same discussion as G. Lohmann over at sf.net, I can see the points about SVN. I agree with most of them, although integration into an IDE is no argument for me personally. But that’s besides the point.

        I’m using CVS, SVN, Git and Mercurial actively in both professional and private projects. I despise SVN because on a really big project it was *really* very very slow. All the nice PR about it being faster was more or less hogwash when it faced a reality-check. All the projects that are currently still in SVN are either because it was requested by the respective team or because we haven’t found the time to migrate.

        Although CVS has its merits, I prefer the DVCS, like Git and Mercurial. The reason being that their merge support (among other things) is far superior to CVS (or SVN). Whenever I’m in an environment where I am forced to use CVS but where I’m not allowed to break the build due to intermediate commits, I use a DVCS repository overlaid with the CVS/SVN working copy and do my stuff in there. Then, when done, I commit changes back to CVS/SVN.

        But Git offers even better workflows specifically tailored at CVS/SVN integration. So it’s not really an “either or”, but instead it can be a quite productive combination …

        And we’ve not even talked about the fact that each copy of a DVCS repo contains the full revision history (and thus a full backup), about patch queues or shelving … all very useful features that come in one form or another with DVCS. Oh, and staging is another thing Git aficionados like to point out.

        But since the discussion was on sf.net, I think it’s more important to point out the advantages of DVCS over CVS/SVN w.r.t. FLOSS projects. After all, having the ability to clone a repo even if the source is read-only gives me the ability to track my own changes and send back patches more easily than any of the classic VCS does.

      • rolfje says:

        Very good points, and the Git overlay on CVS sounds promising, although it adds one step to the commit process, which may lead to slower/less checkins, making team work harder (more collisions when waiting to commit to CVS). I also track Bug commits (issue numbers in commit comments), does Git propagate those to the backing CVS, even if you aggregate commits like you described?

    • mirabilos says:

      “svn log foo”, eh? Try that after removing foo then copying a new foo there.

      I ❦ CVS, and I’ve even written an svn2cvs converter which is so easy because CVS can do much much more than Suckwürstchen. For example vendor branches.

  12. Sybren says:

    I don’t know about git cvs, but mercurial svn does preserve individual commits. I’ve been using it for several Chess projects already. One thing I love with a DVCS is that I commit, and then pull and solve conflicts (if there are any). This means my hard work is safe before it can be messed up by a conflict. It makes solving them much safer and easier.

  13. rolfje says:

    Merging long running branches on a 600.000+ lines of code project without the semantic help of Eclipse is almost impossible to get right. Eclipse knows what a class and a method is, and can do the merge much more intelligently than any commandline language-agnostic tool in my opinion.

    That, and I ‘d like to see a versioning tool do it for Word and Excel files. Now THERE is room for improvement instead of re-defining what a branch and a tag is on each new and cool versioning system.

    • Viðarr says:

      You underestimate the power of merge-tracking (as it is called). Say you use a central server which holds the authoritative copy. In either case, the pushes to that server include all information about the parents of the code that has changed, including merges and more branching. Now, all of that information is also available to your clone of the “central” repo, because ultimately at some point your clone and the central repo share revision history.

      Well, you’d be amazed. All newer versions of MS Office and also OOo use ZIP files which contain other stuff (usually XML). Now, XML can be diffed more easily. So there’s the point to introduce a hook into your VCS and exploit that trait.

      Besides, a branch still means what it meant in CVS. And yes, even on CVS you can move tags and branches, which is why you usually have a convention for naming release tags, so that no one goes about and moves them around …

      But as for Subversion, I also didn’t like the fact that it presented the branches/tags as folders. But what hurt productivity most was its slowness. You won’t have that problem with Git or Mercurial. Promised.

      … and the superior merge support is the cherry on top ;)

  14. rolfje says:

    We use GForge at work, and it looks like the next version is going to support Git, so maybe I’ll have a look at that, too.

    I know the new doc formats are Zipped XML, I’ve hacked around with that once or twice. Still, I don’t seem to recall any versioning system or IDE being able to do a document diff. If you’ve seen the XML MS Word produces you probably know the reason why :-)

    I’ll switch versioning systems no sooner than I find a fast, simple, non-commandline, readily integrated into the IDE solution I can roll out at very low cost, and I can explain the benifits to my boss and my coworkers.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 29 other followers