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

svn diff --svnpatch & svn patch

From: Charles Acknin <charlesacknin_at_gmail.com>
Date: 2007-09-03 02:12:38 CEST

The svnpatch-diff branch might not be stable enough for 1.5 but I
think it has now come to a mature point. I'd like some volunteers
(well, those not to busy with 1.5) switch to the branch and help
giving 'svn diff --svnpatch' and 'svn patch' a hard time in order to
spot possible bugs before we think about merging back to trunk.

A few words for those willing to help:
  * for now, temporary files are left on disk to help debug (use of
    - /tmp/svnpatch[.X] is created when running 'svn diff --svnpatch'
and holds clear-text Editor Commands
    - /tmp/compressedpatch[.X] is created when running 'svn patch' and
holds zlib'ed Editor Commands, decoded right from the base64'ed block
of the svnpatch
    - /tmp/patch[.X] is created when running 'svn patch' and holds
clear-text Editor Commands (i.e. uncompressed /tmp/compressedpatch)
  * 'svn patch' doesn't work unidiff bytes (see bellow).
  * 'svn diff --svnpatch' should work against any kind of diff (wc-wc,
repos-wc, repos-repos)
  * you'll find 'svn diff --svnpatch' tests in diff_tests.py 42
  * 'svn patch' test (well there's only one) in patch_tests.py

Note that I've left a few TODOs behind while writing which I should
hopefully be able to clear in the next couple of weeks.

So, for now, svn patch only cares about the svnpatch block of a patch.
 Which means although you can feed it with a unidiff+svnpatch input
(like for example the output that comes right out from 'svn diff
--svnpatch'), it seeks to the svnpatch header and starts reading from
here. This is because I -- we? -- haven't yet come to a solution
regarding "How do we deal with Unidiff in Subversion?". I'd like to
take the opportunity of this post to open the talk on this matter.
Yet, if you want to apply unidiff+svnpatch, you'll have to run both
'svn patch' and your favorite patch tool (like GNU patch(1)). Let the
debate be open.

Furthermore, I recall I had talked about adding an option to 'svn
patch' in order to decode an svnpatch block (gzip-base64'ed). Should
this feature be? Note that you can already use 'svn patch --dry-run'
to catch a glimpse of what the guts of the encoded block look like.

One last thing: should I file anything in the issuetracker?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 3 02:09:35 2007

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