You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Charles Acknin <ch...@gmail.com> on 2007/09/03 00:12:38 UTC
svn diff --svnpatch & svn patch
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
svn_io_file_del_none).
- /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?
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/22/07, Karl Fogel <kf...@red-bean.com> wrote:
> "Charles Acknin" <ch...@gmail.com> writes:
> > Just to let everybody know what's going on with this topic: I
> > recently moved and haven't had that much time to work on the
> > svnpatch-diff branch in the past couple of weeks.
> >
> > So here what I'll do from now on if nobody objects. As Ben suggested
> > in this thread, I'll merge this branch back to trunk RSN. But, I'd
> > rather first work on the patch-binary-call thing [1] on the branch and
> > *then* merge, as opposed to first merging and then sending patches to
> > dev@.
>
> Will this be okay for the Oct. 12th branch date for 1.5?
Plenty of chances it will :-) I'll let dev@ know when this feature's
ready for merge though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Karl Fogel <kf...@red-bean.com>.
"Charles Acknin" <ch...@gmail.com> writes:
> Just to let everybody know what's going on with this topic: I
> recently moved and haven't had that much time to work on the
> svnpatch-diff branch in the past couple of weeks.
>
> So here what I'll do from now on if nobody objects. As Ben suggested
> in this thread, I'll merge this branch back to trunk RSN. But, I'd
> rather first work on the patch-binary-call thing [1] on the branch and
> *then* merge, as opposed to first merging and then sending patches to
> dev@.
Will this be okay for the Oct. 12th branch date for 1.5?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
Just to let everybody know what's going on with this topic: I
recently moved and haven't had that much time to work on the
svnpatch-diff branch in the past couple of weeks.
So here what I'll do from now on if nobody objects. As Ben suggested
in this thread, I'll merge this branch back to trunk RSN. But, I'd
rather first work on the patch-binary-call thing [1] on the branch and
*then* merge, as opposed to first merging and then sending patches to
dev@.
Cheers,
Charles
[1] in this same thread:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=129864
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/9/07, David Glasser <gl...@davidglasser.net> wrote:
> On 9/8/07, Jay Levitt <li...@shopwatch.org> wrote:
> > Can't svn patch call patch externally with the unidiff portion if patch
> > is present? That makes things better for people who DO have GNU patch,
> > without making things worse for anyone who doesn't.
>
> Good call. You should be able to configure a path to GNU patch (or a
> similar tool with a similar interface) in the user config directory,
> and 'svn patch' should call it (with the right -p argument!); if 'svn
> patch' can't find it it can print a message saying "text diffs not
> applied, please use an external tool".
OK, here's the behaviour I'm planning to implement:
- look up the --patch-cmd arg on the command line and use it
- fallback if not found: look up patch-cmd setting in the user
config, and use it
- fallback if not found: search $PATH for the 'patch' binary
(svn_io_run_cmd/execvp) and call it
Would that be fine?
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by David Glasser <gl...@davidglasser.net>.
On 9/8/07, Jay Levitt <li...@shopwatch.org> wrote:
> On 9/8/2007 4:11 PM, David Glasser wrote:
>
> > Thus there are three types of patches: those which just need an
> > external patch tool to apply (text mods only), those which just need
> > 'svn patch' to apply (no text mods), and those which need both.
> > Perhaps 'svn patch' should include a header saying which one this is?
>
> Even with a header, that's going to be horribly confusing to users.
> Heck, it's confusing to me, and I haven't used since college.
>
> Can't svn patch call patch externally with the unidiff portion if patch
> is present? That makes things better for people who DO have GNU patch,
> without making things worse for anyone who doesn't.
Good call. You should be able to configure a path to GNU patch (or a
similar tool with a similar interface) in the user config directory,
and 'svn patch' should call it (with the right -p argument!); if 'svn
patch' can't find it it can print a message saying "text diffs not
applied, please use an external tool".
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Jay Levitt <li...@shopwatch.org>.
On 9/8/2007 4:11 PM, David Glasser wrote:
> Thus there are three types of patches: those which just need an
> external patch tool to apply (text mods only), those which just need
> 'svn patch' to apply (no text mods), and those which need both.
> Perhaps 'svn patch' should include a header saying which one this is?
Even with a header, that's going to be horribly confusing to users.
Heck, it's confusing to me, and I haven't used since college.
Can't svn patch call patch externally with the unidiff portion if patch
is present? That makes things better for people who DO have GNU patch,
without making things worse for anyone who doesn't.
Jay Levitt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by David Glasser <gl...@davidglasser.net>.
On 9/8/07, Charles Acknin <ch...@gmail.com> wrote:
> On 9/8/07, Mark Phippard <ma...@gmail.com> wrote:
> > I am still completely confused.
> >
> > Let's say I just edit 5 normal files (java/c etc..) No adds or copies
> > or anything.
> >
> > Can I make an "svnpatch" and apply it with just svn patch?
>
> No, not with *just* svn patch.
>
> If you run 'svn diff --svnpatch' against a working copy that has just
> *contextual* modifications, you'll find the same output as with 'svn
> diff'. That's because the svnpatch part of a patch only carries:
> - tree changes
> - property changes
> - binary changes
>
> (and text changes don't fall into one of these cases).
>
> From your previous post I now understand why you're confused. I think
> you thought the svnpatch block did carry text changes, which is not
> the case.
Interesting. This implies to me that for the majority of patches
(those that are just text mods), the svnpatch block is just a no-op!
Thus there are three types of patches: those which just need an
external patch tool to apply (text mods only), those which just need
'svn patch' to apply (no text mods), and those which need both.
Perhaps 'svn patch' should include a header saying which one this is?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/8/07, Mark Phippard <ma...@gmail.com> wrote:
> I am still completely confused.
>
> Let's say I just edit 5 normal files (java/c etc..) No adds or copies
> or anything.
>
> Can I make an "svnpatch" and apply it with just svn patch?
No, not with *just* svn patch.
If you run 'svn diff --svnpatch' against a working copy that has just
*contextual* modifications, you'll find the same output as with 'svn
diff'. That's because the svnpatch part of a patch only carries:
- tree changes
- property changes
- binary changes
(and text changes don't fall into one of these cases).
Re: svn diff --svnpatch & svn patch
Posted by Mark Phippard <ma...@gmail.com>.
On 9/8/07, Charles Acknin <ch...@gmail.com> wrote:
> On 9/8/07, David Glasser <gl...@davidglasser.net> wrote:
> > Hmm. So, what I mean is, the "+ blabla" change is also encoded inside
> > the 'eJzTUMgvSM3TLcrPL' bytes, right?
>
> No it wasn't designed this way. (I'm now wondering whether Mark did
> also think this way). In the part III of the design doc, it's
> explained what's in each part of the patch. Basically, there's
> nothing *twice* in the patch (but property changes) for the sake of
> redundancy. This also avoids any discrepancy with both information
> being synchronized: what if the user changes the unidiff part of a
> patch and tries to apply with 'svn patch'? He might think 'svn patch'
> is going to handle it properly, where this is not the case yet as 'svn
> patch' doesn't read the unidiff part. I really think each information
> should live in the patch once. I made a special case with properties
> since it's really helpful to have them displayed in cleartext.
>
> But hey, if people think it's better to include text changes in the
> svnpatch block too so that 'svn patch' can handle it all, let's do it
I am still completely confused.
Let's say I just edit 5 normal files (java/c etc..) No adds or copies
or anything.
Can I make an "svnpatch" and apply it with just svn patch?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/8/07, David Glasser <gl...@davidglasser.net> wrote:
> Hmm. So, what I mean is, the "+ blabla" change is also encoded inside
> the 'eJzTUMgvSM3TLcrPL' bytes, right?
No it wasn't designed this way. (I'm now wondering whether Mark did
also think this way). In the part III of the design doc, it's
explained what's in each part of the patch. Basically, there's
nothing *twice* in the patch (but property changes) for the sake of
redundancy. This also avoids any discrepancy with both information
being synchronized: what if the user changes the unidiff part of a
patch and tries to apply with 'svn patch'? He might think 'svn patch'
is going to handle it properly, where this is not the case yet as 'svn
patch' doesn't read the unidiff part. I really think each information
should live in the patch once. I made a special case with properties
since it's really helpful to have them displayed in cleartext.
But hey, if people think it's better to include text changes in the
svnpatch block too so that 'svn patch' can handle it all, let's do it
:-)
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by David Glasser <gl...@davidglasser.net>.
On 9/8/07, Charles Acknin <ch...@gmail.com> wrote:
> On 9/7/07, David Glasser <gl...@davidglasser.net> wrote:
> > On 9/2/07, Charles Acknin <ch...@gmail.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
> svnpatch.
>
> So, suppose my output (svn diff --svnpatch) is like the following:
>
> [[[
> Property changes on: .
> ___________________________________________________________________
> Name: myprop
> + myprop value
>
> Index: README
> ===================================================================
> --- 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.
> +blabla
> ========================= SVNPATCH1 BLOCK =========================
> eJzTUMgvSM3TLcrPL1HQUDCySjFQ0ARCDYXkjMS89FTdlMwi3YKi/AKYpJlVbiWUb2gEY5cl5pSm
> gvWBdebkF4M1ohkIFk5NyQRZBBICAKENIqA=
> ]]]
>
> then 'svn patch' starts reading right after the svnpatch header, i.e.
> at 'eJzTUMgv..' bytes.
Hmm. So, what I mean is, the "+ blabla" change is also encoded inside
the 'eJzTUMgvSM3TLcrPL' bytes, right? And 'svn patch' will apply that
change (based on the svnpatch1 block)? So my suggestion is an option
that makes 'svn patch' skip the textdeltas *inside the svnpatch block*
so that you can apply them with patch(1) in case you've edited them.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Ben Collins-Sussman <su...@red-bean.com>.
If the branch is now stable (not disruptive to the rest of us) and
relatively code-reviewed (presumably by the mentor), then it shouild
be merged to trunk. From there, Charles can submit patches to the
list for review as things get refined... Just like other partial
committers. Does that seem reasonable?
On 9/8/07, David Glasser <gl...@davidglasser.net> wrote:
> On 9/8/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > On 9/8/07, Charles Acknin <ch...@gmail.com> wrote:
> >
> > > Oh yeah sure! I couldn't be more happy to merge this back to trunk.
> > > It doesn't break anything since it's a feature we *add* to Subversion.
> > > I just didn't know when -- usually in Subversion -- it's decided a
> > > branch can be merged to trunk. I assumed it needed some testing
> > > before. But yeah, if it's not going to get much testing when
> > > remaining in a branch, if nobody objects let's go for it.
> >
> > We do all our development work on trunk, not on branches. We only
> > keep branches around for two reasons:
> >
> > * long-term maintenance branches, from which we do releases
> >
> > * short-term feature branches, which exist only long enough not to
> > "mess up" everyone else working on the trunk.
> >
> > It's clear that your work is no longer going to mess anyone else up,
> > so please merge it to trunk. :-)
>
> Is it relevant that Charles only has partial commit access, which
> means we're comfortable with letting him touch any file on his branch
> which he deems relevant to svnpatch work, but not necessarily the same
> on trunk? (Most of our partial commit categories are more clearly
> defined to be specific physical portions of the tree, but svnpatch is
> pervasive throughout various parts of the main source directory.)
>
> --dave
>
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by David Glasser <gl...@davidglasser.net>.
On 9/8/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 9/8/07, Charles Acknin <ch...@gmail.com> wrote:
>
> > Oh yeah sure! I couldn't be more happy to merge this back to trunk.
> > It doesn't break anything since it's a feature we *add* to Subversion.
> > I just didn't know when -- usually in Subversion -- it's decided a
> > branch can be merged to trunk. I assumed it needed some testing
> > before. But yeah, if it's not going to get much testing when
> > remaining in a branch, if nobody objects let's go for it.
>
> We do all our development work on trunk, not on branches. We only
> keep branches around for two reasons:
>
> * long-term maintenance branches, from which we do releases
>
> * short-term feature branches, which exist only long enough not to
> "mess up" everyone else working on the trunk.
>
> It's clear that your work is no longer going to mess anyone else up,
> so please merge it to trunk. :-)
Is it relevant that Charles only has partial commit access, which
means we're comfortable with letting him touch any file on his branch
which he deems relevant to svnpatch work, but not necessarily the same
on trunk? (Most of our partial commit categories are more clearly
defined to be specific physical portions of the tree, but svnpatch is
pervasive throughout various parts of the main source directory.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 9/8/07, Charles Acknin <ch...@gmail.com> wrote:
> Oh yeah sure! I couldn't be more happy to merge this back to trunk.
> It doesn't break anything since it's a feature we *add* to Subversion.
> I just didn't know when -- usually in Subversion -- it's decided a
> branch can be merged to trunk. I assumed it needed some testing
> before. But yeah, if it's not going to get much testing when
> remaining in a branch, if nobody objects let's go for it.
We do all our development work on trunk, not on branches. We only
keep branches around for two reasons:
* long-term maintenance branches, from which we do releases
* short-term feature branches, which exist only long enough not to
"mess up" everyone else working on the trunk.
It's clear that your work is no longer going to mess anyone else up,
so please merge it to trunk. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/8/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> A silly question: since the feature seems to mostly work, is there
> any *danger* in merging it to trunk?
>
> As long as it remains in a branch, it's not going to get much testing.
> When it goes to trunk, it will be effortless for all the developers
> to play around with. And it doesn't seem like it's going to break
> anything, right? As long as 'make check' passes, it seems like it
> will Do No Harm for the rest of us, whether we decide to try it out or
> not.
>
> Also, if it comes to trunk, not only will it get more testing, that
> also gives you 6 weeks to get the bugs out before we branch for 1.5.
> :-)
Oh yeah sure! I couldn't be more happy to merge this back to trunk.
It doesn't break anything since it's a feature we *add* to Subversion.
I just didn't know when -- usually in Subversion -- it's decided a
branch can be merged to trunk. I assumed it needed some testing
before. But yeah, if it's not going to get much testing when
remaining in a branch, if nobody objects let's go for it.
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Ben Collins-Sussman <su...@red-bean.com>.
A silly question: since the feature seems to mostly work, is there
any *danger* in merging it to trunk?
As long as it remains in a branch, it's not going to get much testing.
When it goes to trunk, it will be effortless for all the developers
to play around with. And it doesn't seem like it's going to break
anything, right? As long as 'make check' passes, it seems like it
will Do No Harm for the rest of us, whether we decide to try it out or
not.
Also, if it comes to trunk, not only will it get more testing, that
also gives you 6 weeks to get the bugs out before we branch for 1.5.
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/7/07, David Glasser <gl...@davidglasser.net> wrote:
> On 9/2/07, Charles Acknin <ch...@gmail.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
svnpatch.
So, suppose my output (svn diff --svnpatch) is like the following:
[[[
Property changes on: .
___________________________________________________________________
Name: myprop
+ myprop value
Index: README
===================================================================
--- 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.
+blabla
========================= SVNPATCH1 BLOCK =========================
eJzTUMgvSM3TLcrPL1HQUDCySjFQ0ARCDYXkjMS89FTdlMwi3YKi/AKYpJlVbiWUb2gEY5cl5pSm
gvWBdebkF4M1ohkIFk5NyQRZBBICAKENIqA=
]]]
then 'svn patch' starts reading right after the svnpatch header, i.e.
at 'eJzTUMgv..' bytes.
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by David Glasser <gl...@davidglasser.net>.
On 9/2/07, Charles Acknin <ch...@gmail.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.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/8/07, Mark Phippard <ma...@gmail.com> wrote:
> OK, I do not think that was clear before. I did not think your option
> #1 was ever a real goal for this feature. It would obviously be a
> cool addition, but not a must-have at all.
Mark, could you please have a look at
http://svn.collab.net/repos/svn/branches/svnpatch-diff/notes/svnpatch
and see whether "V PATCHING" part is clear on this matter? If not,
I'll try to improve so that other users don't get it wrong.
> A couple of questions:
>
> 1) Can patches be applied to working copies that do not have the exact
> same revisions of the files that were used to produce the patches? I
> recall this being discussed on the list in the past.
Yes, since svnpatch is revision-less and checksum-less (except for
binary files). And if your browser is still opened on notes/svnpatch,
you'll find of interest part VI :-)
> 2) Are there any public API's in your code to interrogate the patch
> contents? I am trying to think of how a visual patch apply tool like
> TortoiseMerge could be extended to show what is in the patch and allow
> the user to selectively apply portions of it.
Yeah, sounds like a great idea! Here's svn_client_patch() signature:
svn_error_t *
svn_client_patch(const char *patch_path,
const char *wc_path,
svn_boolean_t force,
svn_boolean_t dry_run,
svn_client_ctx_t *ctx,
apr_pool_t *pool);
@a patch_path is supposed to be the full encoded patch. The tool
could pass a subset of a patch -- the selected encoded portion -- and
svn_client_path() would do job. However (!), an editor drive is going
to happen (svn_client_patch() calls svn_wc_apply_patch() to achieve
this), which means we're waiting for open-root/close-edit commands.
So this can't just be a subset, but a subset with enclosing commands.
Besides this little constraint, I think it works: decode, display
contents to user, user selects, add enclosing commands, encode, invoke
svn_client_patch() with this encoded patch subset. I was thinking
aloud.
Note that in theory, 'svn patch' is _very_ similar to 'svn merge', so
there's no reason this can't work.
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Mark Phippard <ma...@gmail.com>.
On 9/8/07, Charles Acknin <ch...@gmail.com> wrote:
> On 9/8/07, Mark Phippard <ma...@gmail.com> wrote:
> > I am still confused about the GNU patch part. Does svn patch apply
> > the patch if you do not have GNU patch or does it require it? Is GNU
> > patch just required for people that want to apply a patch from the
> > unidiff? Is there any difference in the outcome?
>
> GNU patch is not required. We didn't solve the problem of applying
> unidiff yet (not all the platforms Subversion supports have GNU patch;
> injecting GNU patch into Subversion would raise at least licensing
> questions) , so I did rather leave the unidiff part aside (and let the
> user deal with it with her/his own tools). Put differently, we have
> three use-cases depending on whether the input you're feeding 'svn
> patch' with is:
> 1. unidiff only : 'svn patch' does nothing.
> 2. unidiff+svnpatch: 'svn patch' parses the input until it finds
> svnpatch bytes, and processes these. The unidiff bytes are ignored.
> 3. svnpatch only: 'svn patch' processes svnpatch bytes.
>
> To sum up: Subversion handles the svnpatch bytes and the user is free
> to run e.g. GNU patch against the unidiff part of the patch.
OK, I do not think that was clear before. I did not think your option
#1 was ever a real goal for this feature. It would obviously be a
cool addition, but not a must-have at all.
A couple of questions:
1) Can patches be applied to working copies that do not have the exact
same revisions of the files that were used to produce the patches? I
recall this being discussed on the list in the past.
2) Are there any public API's in your code to interrogate the patch
contents? I am trying to think of how a visual patch apply tool like
TortoiseMerge could be extended to show what is in the patch and allow
the user to selectively apply portions of it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/8/07, Mark Phippard <ma...@gmail.com> wrote:
> I am still confused about the GNU patch part. Does svn patch apply
> the patch if you do not have GNU patch or does it require it? Is GNU
> patch just required for people that want to apply a patch from the
> unidiff? Is there any difference in the outcome?
GNU patch is not required. We didn't solve the problem of applying
unidiff yet (not all the platforms Subversion supports have GNU patch;
injecting GNU patch into Subversion would raise at least licensing
questions) , so I did rather leave the unidiff part aside (and let the
user deal with it with her/his own tools). Put differently, we have
three use-cases depending on whether the input you're feeding 'svn
patch' with is:
1. unidiff only : 'svn patch' does nothing.
2. unidiff+svnpatch: 'svn patch' parses the input until it finds
svnpatch bytes, and processes these. The unidiff bytes are ignored.
3. svnpatch only: 'svn patch' processes svnpatch bytes.
To sum up: Subversion handles the svnpatch bytes and the user is free
to run e.g. GNU patch against the unidiff part of the patch.
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Mark Phippard <ma...@gmail.com>.
On 9/8/07, Charles Acknin <ch...@gmail.com> wrote:
> On 9/7/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> > I have a dumb question: is there a design-doc somewhere that
> > describes how to use the feature? I mean, some really simple
> > instructions that demonstrate the new commands and switches, so we
> > understand how to do the testing?
>
> The design doc is at
> http://svn.collab.net/repos/svn/branches/svnpatch-diff/notes/svnpatch.
> It doesn't tell how to use the feature but instead how it works,
> though.
>
> Anyway, using the feature is as simple as appending --svnpatch to 'svn
> diff' subcommand to produce the output ('svn help diff' tells about
> the option), and then use 'svn patch' to apply the patch ('svn help
> patch' also available. (Oops, I have to update this help section so
> that users know Unidiff isn't supported right now.))
>
> So, in a nutshell,
> 1. svn diff --svnpatch > /path/to/output.patch
> 2. svn patch /path/to/output.patch .
I am still confused about the GNU patch part. Does svn patch apply
the patch if you do not have GNU patch or does it require it? Is GNU
patch just required for people that want to apply a patch from the
unidiff? Is there any difference in the outcome?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Charles Acknin <ch...@gmail.com>.
On 9/7/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> I have a dumb question: is there a design-doc somewhere that
> describes how to use the feature? I mean, some really simple
> instructions that demonstrate the new commands and switches, so we
> understand how to do the testing?
The design doc is at
http://svn.collab.net/repos/svn/branches/svnpatch-diff/notes/svnpatch.
It doesn't tell how to use the feature but instead how it works,
though.
Anyway, using the feature is as simple as appending --svnpatch to 'svn
diff' subcommand to produce the output ('svn help diff' tells about
the option), and then use 'svn patch' to apply the patch ('svn help
patch' also available. (Oops, I have to update this help section so
that users know Unidiff isn't supported right now.))
So, in a nutshell,
1. svn diff --svnpatch > /path/to/output.patch
2. svn patch /path/to/output.patch .
Cheers,
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn diff --svnpatch & svn patch
Posted by Ben Collins-Sussman <su...@red-bean.com>.
I have a dumb question: is there a design-doc somewhere that
describes how to use the feature? I mean, some really simple
instructions that demonstrate the new commands and switches, so we
understand how to do the testing?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org