"Charles Acknin" <charlesacknin@gmail.com> writes:
> 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?
Ugh :-(. That's a tough one. The simplest answer for now might be to
notice whether there were copies/moves during the dry run, trap the
error from the external patch program, see if the error applies to any
of the putatively copied/moved items, and transform it into an
"application deferred" warning instead. I realize that's lame, but
it's the best I can come up with right now.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 22 02:51:34 2007