On 9/7/07, David Glasser <firstname.lastname@example.org> wrote:
> On 9/2/07, Charles Acknin <email@example.com> wrote:
> > 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
> Hmm, maybe the answer here is to have some sort of "svn patch
> --ignore-textdelta" (with a much better name) so that what you would
> do is run both "svn patch --ignore-textdelta" and patch(1) in series?
> (And wrap that in a shell script.)
'svn patch' already ignores the textdelta (unidiff). Maybe I wasn't
clear enough with "it seeks to the svnpatch header and starts reading
from here". Let me try to clarify. When you feed 'svn patch' with a
unidiff+svnpatch output, it ignores the unidiff and reads the
So, suppose my output (svn diff --svnpatch) is like the following:
Property changes on: .
+ myprop value
--- README (revision 26482)
+++ README (working copy)
@@ -80,3 +80,4 @@
Finally, be sure to see Appendix A in the Subversion Book. It
contains a very quick overview of the major differences between
CVS and Subversion.
========================= SVNPATCH1 BLOCK =========================
then 'svn patch' starts reading right after the svnpatch header, i.e.
at 'eJzTUMgv..' bytes.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Sep 8 12:04:37 2007