On Mon, Apr 27, 2009 at 08:57:32AM -0400, Mark Phippard wrote:
> On Mon, Apr 27, 2009 at 8:55 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>
> > That said, it still needs to be improved before it can go into a
> > release. The internal unidiff patch application stuff is not done yet.
>
> Been meaning to ask. If you have "old-style patches" that are just
> unidiff, will the new patch application stuff be able to apply it?
Yes. That's the whole point of having it.
> Or does it require the new format? I am assuming it will still apply it
> since the new format just adds more to unidiff, but wondering.
If an SVNPATCH block header is found in the patch file, the block's
body is decoded and the decoded svn protocol commands are used to run
an editor.
Anything else in the patch is either a unidiff, or it is noise.
To apply unidiff portions of a patch file, we used to pass the entire
patch file to /usr/bin/patch, which would ignore the SVNPATCH blocks
as part of ignoring noise, and apply the unidiff portions.
Basically, we were saving the user the hassle of running the command
/usr/bin/patch themselves.
But now, we don't repy on /usr/bin/patch anymore. We parse the unidiff
bits ourselves, and apply them to the working copy ourselves.
This gives us nicer looking merge conflicts, and notifications just
like during update and merge:
$ svn patch /tmp/mydiff.diff
U foo/bar/baz.c
C foo/include/foo.h
G Makefile
$
Anything that contains a unidiff should work. You should be able to
save emails containing inline patches as a file (with mail headers and
all), and pass that file to svn patch to apply any unidiffs contained
in the file -- provided the inline-pasted unidiffs are not messed up.
Stefan
Received on 2009-04-27 16:32:47 CEST