Revision Control with SVN

Revision Control with SVN

Today we finally switched to Subversion as our revision control system at work. After using CVS for about ten years, the list of things we didn’t like about it became long enough to justify switching to something different.

At first it wasn’t quite clear what that “something different” would be; many KDE people (mainly from the Linux camp) suggested to use Git but that’s a no-go for us (we need our revision control system to work on Windows as well), leaving aside that some people here would probably rather walk over broken glass than adjusting their work style. 🙂

Since we’ve been using Subversion for quite some time at KDE, and we know that it feels very much like CVS (minus the annoying things), it came as a natural choice. First attempts to convert our internal repository went very well, and now – with the switch being final – many scripts which were developed as little side projects to KDE, such as ‘svnlastchange’, become useful to us, too.

And I don’t have to do the mental switch between svn and cvs all the time when moving between the office and home. 🙂

The biggest advantage Subversion gave me so far is related to merging patches: I have different checkouts for different Squish branches (one for 3.2, one for HEAD^H^H^H^Htrunk, et cetera) and very often I’m committing something to one checkout and then want to merge the same patch to the other checkout. I wrote a little script for that called ‘ilc’ (for ‘integratelastchange’ ;-)) which makes that very easy. With that script I can just do


$ cd ~/src/squish/trunk
// .. Hack away ..
$ svn ci foo
Sending foo
Transmitting file data .
Committed revision 12000.
$ ilc 12000 ../32-branch

And that’s it. However, I’d like to get rid of the revision number argument so that when the script is invoked with just one argument, it will always integrate the revision which I just checked in. Unfortunately the different types of revisions (COMMITTED and BASE and PREV and whatnot) confuse me a bit, I couldn’t find the right one yet.

Maybe some reader knows how to do that?

Even if that can’t be solved, I can now hardly imagine how we managed to survive this long with CVS on KDE. 🙂

3 Comments

  1. Thiago Macieira 13 years ago

    Hey Frerich

    Subversion special revisions are:
    HEAD = current latest revision in the repository
    BASE = the revision you checked out
    COMMITTED = the last changed revision of a given file or directory
    PREV = COMMITTED-1

    So, let’s suppose there’s a file called foo.c that was changed in revision 91. When you did “svn up” you got revision 100. At this point, it’s:
    HEAD = BASE = 100
    COMMITTED = 91
    PREV = 90

    Then a co-worker (let’s call him Harri) comes and makes a modification somewhere in the repository. HEAD advances to 101. But your BASE doesn’t, because you haven’t run “svn up” again.

    If what you’re looking for is “the last change I committed”, you want the diff between PREV:COMMITTED. I.e., svn merge -r PREV:COMMITTED wc1 wc2.

    One more thing: Subversion 1.5 will include branch/merge management.

  2. Author
    Frerich Raabe 13 years ago

    > If what you’re looking for is “the last change I committedâ€?, you want the diff between
    > PREV:COMMITTED. I.e., svn merge -r PREV:COMMITTED wc1 wc2.

    When using -r PREV:COMMITTED, I have to specify the single files to merge though, right? One thing I like about the current implementation is that I can just specify a target directory and then it’ll integrate all the changes done in the given revision into that target directory.

  3. Jason Voegele 13 years ago

    I think svnmerge.py is what you are looking for:

    http://www.orcaware.com/svn/wiki/Svnmerge.py

Leave a reply

Your email address will not be published. Required fields are marked *

*