This is an old revision of the document!


  1. There is no way using Subversion to diff a local change (“working copy” in SVN speak) with a different branch.
    • With CVS I can do a MFC, fix the conflicts and compare with CURRENT by using;
$ cd releng7/bin/cat
$ cvs up -j 1.3 cat.c
$ vi cat.c
$ cvs diff -r1 file

When trying this with Subversion:

$ svn diff $Fh/bin/cat .
svn: Target lists to diff may not contain both working copy paths and URLs
$ svn diff $Fh/bin/cat
svn: Not all required revisions are specified
  1. CVS provided more abbreviations for commands.
$ svn info --depth immediates svn+ssh://svn.freebsd.org/base/stable/7
$ svn info --depth empty svn+ssh://svn.freebsd.org/base/head

Seems the Subversion developers are much better touch typists (and fast ones at that) than I am. 1 and 0 should be abbreviations for immediates and empty.

  1. “Forced commits” are missing.
    • When one makes a commit and the log message is wrong (or missing), some shops have disabled cvs admin for users, and instead have use cvs ci -f. There appears to be no way to make a zero-change commit using Subversion.
  1. Subversion import is mostly useless.
    • svn import should keep in mind what CVS knew - vendor branches are valuable thing. svn import should have been a useful tool for repeated imports of a 3rd party based source drops. svn import could have been a nice feature if had the ability to see what files on the branch were missing from the files being imported - and then issued the equivalent of svn rm on them.
  1. Subversion does not let you copy-n-paste revision numbers from svn log:
$ svn log foo
------------------------------------------------------------------------
r325249 | deo | 2008-12-14 01:25:28 -0800 (Sun, 14 Dec 2008) | 1 line
..snip..
# X copy-n-paste the "r325249" as my numbers typing isn't good...
$ svn merge -c -r325249 .
svn: Non-numeric change argument (-r325249) given to -c

This is a stupid as CVS is in that you cannot give its date output from cvs log as-is as an argument to “-D”. Sean C. Farley <scf@FreeBSD.org> tells me that svn merge -cr325249 . does work. (Sean thanks for the info!) [Though I still think the Subversion parser need a clue-by-four.]

  1. Even sillier is that if I checkout a tree and make several commits from within the tree, svn log will not show them. An svn update must be done first. This is really anonying - even more so when doing a merge.
  1. Subversion does not automatically expand keywords.
    • One did not have to do anything to get $Id$ expanded using CVS. With Subversion one must explicity do
svn add foo.c
svn propset svn:keywords "FreeBSD=%H" foo.c

At least one can tweak ~/.subversion/config to add

*.c = svn:eol-style=native; svn:keywords=FreeBSD=%H; svn:mime-type=text/plain

But now ones config file is project specific.

  1. Some error output is useless:
$ cd releng7/usr.bin/logger
$ svn merge -c r175993 --record-only svn+ssh://svn.freebsd.org/base/head/usr.bin/loggger .
svn: File not found: revision 182510, path '/head/usr.bin/loggger'

That wasn't very helpful in figuring out I had a tripple g's misspelling…

  1. There is no option at not having base files in .svn.
    • Thus you will always take up twice the disk space, and spend twice as long doing a check out or update than you need to be - if you're writing to NFS and your Subversion server is just as well, if not better, connected to the client system. This is a major issue at $WORK…
  1. Subversion does not sort files in svn diff output alphabetically.
  1. I cannot figure out what svn log does within a directory [to understand the output]. It does not seem to give a combined log for the entire directory (or subtree) as I hoped it would.
  1. The barren set of 'diff' arguments is quite anoying. The set I often use with CVS are “-u20” to see more context of a diff, and “-Bbw” to not see white space changes. Subversion has turned this into
svn diff --diff-cmd diff -x -u20 -c 99 foo.c}}}
  • versioncontrol/subversionmissing.1237360265.txt.gz
  • Last modified: 2009/03/18 07:11
  • by DavidOBrien