Differences

This shows you the differences between two versions of the page.

--- versioncontrol:subversionmissing [2009/02/03 20:24] – DavidOBrien
+++ versioncontrol:subversionmissing [2022/10/07 03:01] (current) – Move bakeoff stuff under a single namespace KubilayKocak
@@ Line 1: / Line 1: @@
 ===== This page describes some of the things I've found missing in Subversion, when coming from CVS: =====
   - 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;
+    * With CVS I can do an MFC, fix the conflicts and compare with CURRENT by using;
 <code>
@@ Line 19: / Line 19: @@
 svn: Not all required revisions are specified
+</code>
+Answer: Use the svn diff --old --new syntax:
+<code>
+$ cd /usr/src/bin/cat
+$ svn diff --old cat.c --new ^/releng/7.0/bin/cat/cat.c
 </code>
@@ Line 39: / Line 46: @@
     * ''%%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.
-  - Subversion does not let you copy-n-paste revision numbers from 'svn log':
+  - Subversion does not let you copy-n-paste revision numbers from ''%%svn log%%'':
+    *
 <code>
@@ Line 52: / Line 60: @@
 </code>
-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".
+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!)
+  * 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.] Answer: svn merge -c -r42 is equivalent to svn merge -c -42, which performs a [[http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo|reverse-merge]]. The above parsing error was fixed in http://svn.apache.org/viewvc?view=revision&revision=1036032 (fix released in 1.7.0).
-[Though I still think the Subversion parser need a clue-by-four.]
+  - 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 annoying - even more so when doing a merge. Anwser: This is an FAQ: http://subversion.apache.org/faq.html#hidden-log
   - 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
+    * One did not have to do anything to get ''%%$Id$%%'' expanded using CVS.  With Subversion one must explicitly do
     *
@@ Line 85: / Line 94: @@
 </code>
-That wasn't very helpful in figuring out I had a tripple g's misspelling...
+That wasn't very helpful in figuring out I had a triple g's misspelling...
   - 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...
-  - Subversion does not sort files in svn diff output alphabetically.
+Answer: A workaround that offers a partial remedy is to check out a single working copy for the entire freebsd repository at depth empty:
-  - 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.
+<code>
+$ svn co --depth empty svn://svn.freebsd.org/base
+$ cd base
+</code>
+and then update desired branches to depth infinity:
+<code>
+$ svn up --depth infinity head
+$ svn up --depth infinity releng/9.1
+</code>
+With Subversion 1.7, files that don't differ between branches now share the same pristine text base file in the .svn directory.
+  - Subversion does not sort files in ''%%svn diff%%'' output alphabetically.
+  - 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.
+  - The barren set of 'diff' arguments is quite annoying.  The set I often use with CVS are "-u9" to see more context of a diff, and "-Bbw" to not see white space changes.  Additionally, I have "diff -p" in my ~/.cvsrc.  Subversion has turned this into
+    *
+<code>
+svn diff --diff-cmd diff -x -u9 -x -p -c 99 foo.c
+</code>
+Even in the "typical" case, Subversion requires
+  *
+<code>
+svn diff -x -p -c 99 foo.c
+</code>
+Unfortunately, ''%%~/.subversion/config%%'' does not seem to offer any relief from this.
+(Well, you can set ''%%"diff-cmd=/usr/bin/diff"%%'' and rely on one's ''%%DIFF_OPTIONS%%'' environmental variable setting, but then diff'ing is slower than it needs to be in the "typical" case.)
+Answer: This was fixed in 1.7.0. See the 'diff-extensions' option in ~/.subversion/config (to view an up-to-date config template: svn help --config-dir /tmp/conf; less /tmp/conf/config)
+  - Why does Subversion bother to tell me the number of lines in a commit log message?
+    *
+<code>
+r111464 | deo | 2009-01-28 14:45:42 -0800 (Wed, 28 Jan 2009) | 2 lines
+Merge blah into foo.
+</code>
+I don't see the benefit in this output.  Couldn't we get something  more useful instead?  Number of source lines changed in that commit for instance.
+Answer: This was done to help tools that parse svn log output. See the cvsps problem where its log message parser fails if a CVS log message contains a log-message-separator line...
+  - Many Subversion commands bail out in processing their command-line arguments if the command operation cannot be accomplished on a particular file.
+    *
+<code>
+svn rm A B C
+D         A
+svn: 'B' does not exist
+</code>
+Oh!, maybe I need to use --force (e.g. to operate like 'rm -rf').
+  *
+<code>
+svn rm --force A B C
+D         A
+svn: 'B' does not exist
+</code>
+Nope, same thing.  This same stupidity also happens with 'svn propdel svn:executable *'.  Thus forcing one to
+  *
+<code>
+for F in * ; do svn propdel -q svn:executable $F ; done
+</code>
+The "-q" shuts up all the error messages that "svn: Attempting to delete nonexistent property 'svn:executable'".  BUT, it also neuters the exit code.  Thus one cannot know if it was able to perform the operation or not.  So
+  *
+<code>
+for F in *; do
+svn propdel -q svn:executable $F
+if [ $? -eq 0 ]; then echo "svn propdel svn:executable $F" ; fi
+done
+</code>
+Does not work as desired:
+  *
+<code>
+$ svn propdel svn:executable A
+svn: Attempting to delete nonexistent property 'svn:executable'
+$ echo $?
+
+$ svn propdel -q svn:executable A
+$ echo $?
+
+</code>