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}}}