[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn patch pitfalls

From: Charles Acknin <charlesacknin_at_gmail.com>
Date: 2007-10-21 00:31:14 CEST

I seem to meet lots of unexpected traps with 'svn patch' these days,
especially with copy and move operations since this is what I've been
working on more or less recently. I have two of them in mind:

* dry-run patching with copy and move operations

This one is rather because of the way we use GNU patch. Basically,
'svn patch' calls the external tool on any given output. That is,
even when dealing with copy and move operations, which the tool
doesn't understand/speak. Consider the following unidiff patch
created after iota2 was copied from iota (svnpatch bytes aren't
displayed):

[[[
Index: iota2
===================================================================
--- iota2 (revision 1)
+++ iota2 (working copy)
@@ -1 +1,2 @@
 This is the file 'iota'.
+bla
]]]

Now run 'svn patch --dry-run patchfile' (or even 'patch -p0 --dry-run
< patchfile'), and GNU patch bails out it can't find such a file.
Why? Because it's dry-run, and thus 'svn patch' didn't copy the file
it would have copied if not in dry-run mode. Let's remind that 'svn
patch' *first* operates on serialized editor commands and *second*
sends unidiff to an external program, precisely to avoid this kind of
problem (when not in dry-run). But with dry-run, we have a problem,
iota2 is missing when the external tool is invoked and expects to see
it. I would hate to have to execute editor commands as if it wasn't
dry-run, let the external tool run in dry-run, and then revert, to
solve this problem.

(Note this isn't a problem when dealing with new files, i.e. add-file
operation, since GNU patch knows (because of lack of context I guess)
the file is new and doesn't expect it to be on disk.)

Thoughts?

* Should svn diff --svnpatch imply --no-diff-deleted as well?

When a file is schedule-delete, either because of a delete or a move,
the unidiff appears with deletion lines of the file (diffs against
/dev/null). Nothing new. The point is, when applying the patch,
delete-entry will first remove the file from disk, then the external
tool will try to apply unidiff and won't find the file and prompt the
user. So should we turn on --no-diff-deleted when --svnpatch is?

Help welcome :-)

Charles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 21 00:31:27 2007

This is an archived mail posted to the Subversion Dev mailing list.