At work i am forced to use subversion.
I don’t understand why a lot of people rate svn superior to CVS, it has at least three major defects:

  • svn log is incredible slow compared to CVS and p4
  • svn diff has no -u arg
  • At least on linux svn does not respond to CTRL+C

7 thoughts on “svn”

  1. It’s simple:
    – proper atomic commits
    – proper renaming of files and deleting of directories (no more “Attic”)
    – a more generic concept to tagging and branching, and using it is actually fun (and it was a horrible pain with CVS)
    Regarding your criticism: I never perceived svn log to be slow, svn diff produced unified diffs by default, and I never experienced your ctrl-c problem.
    I’m extremely happy with SVN, and would never want to switch back. Here, SVN proved to be very helpful in past projects, and my colleagues feel the pain in the latest project where we are still forced to use CVS due to small timeframes (absolutely no time to migrate as the project must be finished quickly).

  2. Do you use DAV or SSH? We have to use DAV.
    It is okay to use unified diffs by default, but they should not error out if -u is passed. All other diff programs don’t use unified diff per default, so my fingers are usally add the -u without brain interaction.
    An example for slowness: a svn log on a single file (out of a larger repository with around 250 revisions) which was just added takes 90sec in svn.
    I have not yet examined where svn spends the time, but this is definetly too slow.

  3. We also use it via WebDAV, but we never experienced problems like that, and last time I checked, the repository had about 10000 commits, with the latest checkout having a size of about 100 (IIRC) megabytes of source code and resources, and I never noticed any slow behaviour.

  4. Both the log-slowness and the ctrl-c problem are totally real and present on FreeBSD as well – and they drive me nuts while futzing around in KDE’s repo.
    It seems to me that svn pretty much ignores signals while doing certain network operations – I can break svn instantly while it’s printing out a log, but when it’s hanging once again while trying to retrieve the log, I’ll have to wait until it’s done before it’ll react to the break.
    I actually stopped using svn log altogether because of this and browse KDE’s websvn instead.

  5. Ok, after our friendly kerberos admin tuned the Kerberos server, svn log is no longer incredible slow, but just slow (around 10times slower than CVS).
    After talking to people with svn clue, switching to fsfs-Repositories would increase performance by a few percent too.

Comments are closed.