You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by SteveKing <st...@gmx.ch> on 2003/04/05 17:16:06 UTC
svn_client_patch()
Hi,
I'd like to make a request for a new/missing function:
svn_client_patch()
as the 'reverse' of svn_client_diff().
The GNU patch program is not installed on every
system and it has a _lot_ of options to set.
Also it would be more user friendly if an 'svn patch'
would exist because it wouldn't be necessary to
learn the parameters of another tool.
What would be great is if svn_client_patch would also
take a log message and include that in the diff file.
Then the svn_client_patch would extract the log
message and store it somewhere (in a file or registry)
and on the next commit the log message from the
diff file would get automatically filled in...
I haven't found an issue for such a function - shall I
write one?
Stefan
Re: svn_client_patch()
Posted by SteveKing <st...@gmx.ch>.
> This all feels pretty arbitrary to me. Cmpilato wants to add property
> support to 'svn patch'. SteveKing wants to add log message support.
> But the *ultimate* goal is a patch format that does much more than
> that -- as Sander says: understands add, rm, copy, move.
>
> So where do you draw the line when defining this new patch format? Do
> you implement 'svn patch' with just one of these features? Two of
> them?
>
> I'm asking a sort of meta-question here: is this one of those
> situations where the new patch format is just going to sort of
> 'evolve' by feature creep, or are people actually going to sit down
> and design the format first?
After reading all the suggestions for the new patch format I'd
like to add another one: what if the patch format includes
really everything mentioned above, wouldn't that be like
local commits? I mean commits doing locally until a connection
to the server is available and then do the actual commits.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Sunday, April 6, 2003, at 12:01 PM, SteveKing wrote:
>> On Sunday, April 6, 2003, at 11:37 AM, SteveKing wrote:
>>
>>> If the patch file doesn't have to be in a text like format so
>>> the user can read it then why not do this:
>>
>> if the patch isn't in text format, you're going to see a large
>> resistance to using it from most open source developers. mailing off
>> a
>> patch to a mailing list works well because one can just glance at it
>> and see what it's doing. if your proposed solution is something
>> opaque
>> (or even just cryptic text like the old xml stuff we had back in the
>> day), it seems like a showstopper to me.
>>
>> -garrett
>
> to make it 'readable' again:
> apply the patch
> do an svn diff > readable patch file
> svn revert
>
> I guess this won't make it a showstopper?
you've still taken a 1 step process ('look at the patch in the email
this guy just sent me') and made it into 5 ('receive email', 'detach
patch from email', 'apply it to correct version of the code', 'run svn
diff', 'look at what he changed'). in my mind, that's a showstopper.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by SteveKing <st...@gmx.ch>.
> On Sunday, April 6, 2003, at 11:37 AM, SteveKing wrote:
>
> > If the patch file doesn't have to be in a text like format so
> > the user can read it then why not do this:
>
> if the patch isn't in text format, you're going to see a large
> resistance to using it from most open source developers. mailing off a
> patch to a mailing list works well because one can just glance at it
> and see what it's doing. if your proposed solution is something opaque
> (or even just cryptic text like the old xml stuff we had back in the
> day), it seems like a showstopper to me.
>
> -garrett
to make it 'readable' again:
apply the patch
do an svn diff > readable patch file
svn revert
I guess this won't make it a showstopper?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by Tom Lord <lo...@emf.net>.
Ewww, let's not jump the gun on this one. Sitting down and
designing a patch format first is a much better idea IMNSHO.
If we have the time for that before 1.0 I don't know. We
certainly told Tom in the past that we didn't.
My possibly imprecise recollection is that I not only suggested
working on a changeset format, but also warned that I thought
consideration of changeset functionality would naturally lead to a
revisitation of some pretty deep elements of the svn design. So at
roughly the same time, I was proposing a "stop and have a design
review" phase.
In other words, what I was told there wasn't time for was much larger
in scope than just working on changeset formats.
So, having had some off-list interaction with some svn hackers, I have
a somewhat better feel for the multi-faceted "state" of the project
and its various interests. In that light, I would still propose a
design review phase: immediately after 1.0, concurrently with
supporting 1.0 adopters and clearing the board of the low hanging
fruit that was nonetheless pushed off to "after 1.0".
Between now and then: can/should/how work on changeset formats and
functionality proceed? I think that's an interesting question.
I'm pretty sure the CollabNet team can't justify spending time
on that feature pre 1.0.
[....]
I'd be reluctant to ship 1.0 with a non-designed patch format,
since it will be hard to change it once we call it stable.
RE: svn_client_patch()
Posted by Sander Striker <st...@apache.org>.
> From: SteveKing [mailto:steveking@gmx.ch]
> Sent: Sunday, April 06, 2003 6:16 PM
> ok, then what about this:
> additional to the 'binary' patch the patchfile also includes the output
> of svn diff so the user can read it?
> The patch file would have on top the diff output and attached a textual
> representation of the binary part - like an email with an attachment.
> That way the user can still read the patch file, and it will also be
> possible for the patch to contain log messages, renames, ...
Ewww, let's not jump the gun on this one. Sitting down and designing a
patch format first is a much better idea IMNSHO. If we have the time for
that before 1.0 I don't know. We certainly told Tom in the past that
we didn't. I'm pretty sure the CollabNet team can't justify spending time
on that feature pre 1.0. Ofcourse, others can invest their time as they
see fit, but they'll have to do without some of the core eyes (and brains)
while working on this.
I'd be reluctant to ship 1.0 with a non-designed patch format, since it will
be hard to change it once we call it stable.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by SteveKing <st...@gmx.ch>.
> > if the patch isn't in text format, you're going to see a large
> > resistance to using it from most open source developers. mailing off
> > a patch to a mailing list works well because one can just glance at it
> > and see what it's doing. if your proposed solution is something
> > opaque (or even just cryptic text like the old xml stuff we had back
> > in the day), it seems like a showstopper to me.
>
> Yeah, I agree.
>
> Steve, I'm not sure you know this... but in the very early days of
> Subversion, we didn't have a repository at all. 'svn commit' actually
> wrote out a tree-delta into an XML file, and 'svn update' read and
> applied the XML file to the working copy. Our XML file, was, in
> effect, a tree-aware patch format. Exactly as you descirbe.
>
> But it contained binary data (svndiff), and wasn't very easy to read.
> There was no way we could inflict our XML DTD as a "standard".
> Ultimately that code got deleted once we had a working repository. :-)
ok, then what about this:
additional to the 'binary' patch the patchfile also includes the output
of svn diff so the user can read it?
The patch file would have on top the diff output and attached a textual
representation of the binary part - like an email with an attachment.
That way the user can still read the patch file, and it will also be
possible for the patch to contain log messages, renames, ...
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by Ben Collins-Sussman <su...@collab.net>.
Garrett Rooney <ro...@electricjellyfish.net> writes:
> On Sunday, April 6, 2003, at 11:37 AM, SteveKing wrote:
>
> > If the patch file doesn't have to be in a text like format so
> > the user can read it then why not do this:
>
> if the patch isn't in text format, you're going to see a large
> resistance to using it from most open source developers. mailing off
> a patch to a mailing list works well because one can just glance at it
> and see what it's doing. if your proposed solution is something
> opaque (or even just cryptic text like the old xml stuff we had back
> in the day), it seems like a showstopper to me.
Yeah, I agree.
Steve, I'm not sure you know this... but in the very early days of
Subversion, we didn't have a repository at all. 'svn commit' actually
wrote out a tree-delta into an XML file, and 'svn update' read and
applied the XML file to the working copy. Our XML file, was, in
effect, a tree-aware patch format. Exactly as you descirbe.
But it contained binary data (svndiff), and wasn't very easy to read.
There was no way we could inflict our XML DTD as a "standard".
Ultimately that code got deleted once we had a working repository. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On Sunday, April 6, 2003, at 11:37 AM, SteveKing wrote:
> If the patch file doesn't have to be in a text like format so
> the user can read it then why not do this:
if the patch isn't in text format, you're going to see a large
resistance to using it from most open source developers. mailing off a
patch to a mailing list works well because one can just glance at it
and see what it's doing. if your proposed solution is something opaque
(or even just cryptic text like the old xml stuff we had back in the
day), it seems like a showstopper to me.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by SteveKing <st...@gmx.ch>.
If the patch file doesn't have to be in a text like format so
the user can read it then why not do this:
to create the patch file use svn_client_commit() but
instead of sending the data over the wire to the
server simply store it in a file.
to apply the patch use svn_client_update() and instead
of getting the data from the server get it from the patch
file.
I'm not sure if that is possible (is the data from and to
the server the same?) - but if it is I think that would
be the fastest solution with a high amount of reusing
already written code.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn_client_patch()
Posted by Sander Striker <st...@apache.org>.
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Sunday, April 06, 2003 4:13 PM
> "Sander Striker" <st...@apache.org> writes:
>
> > >>>> Someday, if/when we have a patch format that does more than
> > >>>> conventional patch format, then we can consider a new tool.
> > >
> > > That was what I was asking for - a patch format which also includes
> > > the log message.
> >
> > And includes renames, copies, additions and deletions... and properties
> > (and possibly even merge history, but that could be in properties aswell).
>
> This all feels pretty arbitrary to me. Cmpilato wants to add property
> support to 'svn patch'. SteveKing wants to add log message support.
> But the *ultimate* goal is a patch format that does much more than
> that -- as Sander says: understands add, rm, copy, move.
>
> So where do you draw the line when defining this new patch format? Do
> you implement 'svn patch' with just one of these features? Two of
> them?
>
> I'm asking a sort of meta-question here: is this one of those
> situations where the new patch format is just going to sort of
> 'evolve' by feature creep,
I certainly hope not. I do not wish to end up with yet another 'libsvn_wc'...
> or are people actually going to sit down and design the format first?
Yes please. But we shouldn't let 1.0 depend on this _at all_.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by Ben Collins-Sussman <su...@collab.net>.
"Sander Striker" <st...@apache.org> writes:
> >>>> Someday, if/when we have a patch format that does more than
> >>>> conventional patch format, then we can consider a new tool.
> >
> > That was what I was asking for - a patch format which also includes
> > the log message.
>
> And includes renames, copies, additions and deletions... and properties
> (and possibly even merge history, but that could be in properties aswell).
This all feels pretty arbitrary to me. Cmpilato wants to add property
support to 'svn patch'. SteveKing wants to add log message support.
But the *ultimate* goal is a patch format that does much more than
that -- as Sander says: understands add, rm, copy, move.
So where do you draw the line when defining this new patch format? Do
you implement 'svn patch' with just one of these features? Two of
them?
I'm asking a sort of meta-question here: is this one of those
situations where the new patch format is just going to sort of
'evolve' by feature creep, or are people actually going to sit down
and design the format first?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: svn_client_patch()
Posted by Sander Striker <st...@apache.org>.
> From: SteveKing [mailto:steveking@gmx.ch]
> Sent: Sunday, April 06, 2003 9:10 AM
> > > > IMHO we would do better to recommend that people install a patch
> > > > program than take on the responsibility of maintaining such code
> > > > ourselves.
>
> Please be kind if I'm asking here stupid questions, but isn't subversion
> already doing something similar like patch when doing merges?
'something similar like patch'... well, define 'similar'. We do something
similar to diff3 -mE, but we skip the textual diff creation step and
directly output the merged file (with conflict markers).
Having to parse patch files opens a whole new can of worms...
>>>> Someday, if/when we have a patch format that does more than
>>>> conventional patch format, then we can consider a new tool.
>
> That was what I was asking for - a patch format which also includes
> the log message.
And includes renames, copies, additions and deletions... and properties
(and possibly even merge history, but that could be in properties aswell).
> Ok, I admit it isn't a feature which can't wait but
> I would definitely mark it as 'nice to have' and therefore maybe
> even file an issue for post-1.0?
AFAIK we already have such an issue.
>> 1. Property diff application.
>
> Never noticed that properties weren't applied with patch. Now
> that would be something that even might mark the gnu patch
> useless for some scenarios. Imagine if someone does some
> changes which _need_ some changes in the properties to
> get the whole patch to work - then the sent in patch file
> can't be applied...
It would be nice to create a new patch format which will work with
regular 'patch' for trivial changes.
>> 2. Conflict markers!! Regular 'patch' will just crap out on
>> conflicting hunks -- this behavior is poo. 'svn patch' could
>> behave just like 'svn merge', except from a stream source
>> instead of a repository. :-) Now tell me that isn't Goodness!
Errm... You mean apply the patch to the source it was created against and
then do a diff3 (or something more sophisticated. More on that later)
between the creation source, the patched source and the working copy?
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by SteveKing <st...@gmx.ch>.
> > > IMHO we would do better to recommend that people install a patch
> > > program than take on the responsibility of maintaining such code
> > > ourselves.
Please be kind if I'm asking here stupid questions, but isn't subversion
already doing something similar like patch when doing merges?
> > > Someday, if/when we have a patch format that does more than
> > > conventional patch format, then we can consider a new tool.
That was what I was asking for - a patch format which also includes
the log message. Ok, I admit it isn't a feature which can't wait but
I would definitely mark it as 'nice to have' and therefore maybe
even file an issue for post-1.0?
> 1. Property diff application.
Never noticed that properties weren't applied with patch. Now
that would be something that even might mark the gnu patch
useless for some scenarios. Imagine if someone does some
changes which _need_ some changes in the properties to
get the whole patch to work - then the sent in patch file
can't be applied...
> 2. Conflict markers!! Regular 'patch' will just crap out on
> conflicting hunks -- this behavior is poo. 'svn patch' could
> behave just like 'svn merge', except from a stream source
> instead of a repository. :-) Now tell me that isn't Goodness!
I vote for that!
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by cm...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> kfogel@collab.net writes:
>
> > IMHO we would do better to recommend that people install a patch
> > program than take on the responsibility of maintaining such code
> > ourselves.
> >
> > Someday, if/when we have a patch format that does more than
> > conventional patch format, then we can consider a new tool.
>
> I agree. We've talked about this idea in the past.
I don't remember the outcome of past discussions, but I disagree.
I've long wanted 'svn patch', for two main reasons:
1. Property diff application.
2. Conflict markers!! Regular 'patch' will just crap out on
conflicting hunks -- this behavior is poo. 'svn patch' could
behave just like 'svn merge', except from a stream source
instead of a repository. :-) Now tell me that isn't Goodness!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by Tom Lord <lo...@emf.net>.
As Karl says, someday when 'svn diff' is able to produce a
"next generation" patch format that describes tree changes,
then it makes sense to have 'svn patch' which interprets the
new format as well.
- Ben, who is waiting for Tom Lord to start a project to
define said format. :-)
Tom Lord is eager (at least as far as these things go) to work on said
project and has a considerable start on it in the form of arch's
mkpatch which has yielded both a (strong) straw-man candidate, and a
variety of useful experience regarding that straw-man, both positive
and negative. He concedes that, minimally, the mkpatch format should
be serialized in a human-readable form (for most purposes), and he
would wish to gently remind you that such a format ultimately has some
implications throughout revision control, and that it would make sense
to "some day" work out those implications in the context of
subversion. He has, for roughly a year now, advertised and sought
support for undertaking such a project with the resources and
seriousness it deserves.
But when he isn't busy talking in the third person about himself, Tom
is currently rather distracted by the kind of financial emergency that
results from being unemployed for two years, after experiencing some
other disasters, all of which has not only eaten his modest savings,
but most recently left him quite significantly behind on all bills and
without budget for more than a few days more of food (never mind
electricity, water, connectivity and so forth). So, while Tom
believes he has quite a bit to contribute to the design and
implementation of revision control systems and source management
technology generally (not to mention some software projects in other
domains), he is rather frustrated by the rather ironic circumstance
that more than a year after the release of the first self-hosting
version of arch, when he is finally getting some pretty interesting
and encouraging uptake on the matter, it may very well be far too late
to do much more than hope to find an unoccupied, warm, subway grate in
some city more hospitable to the homeless than San Francisco. He
shudders to think that at this late stage, even a conventional
employment arrangement would postpone his financial recovery for a
considerable period -- an important consideration at his advanced age
of thirty-seven.
While he may have been somewhat ... er ... "flamboyant" in his
professional youth, and may have landed quite by chance in some rather
dysfunctional career situations, no doubt facts which contribute
substantially to his current unemployment, in the past few years at
least, he has generally despised the seeming necessity of public drama
regarding his circumstance -- at least to the extent, I can tell you,
that he does not exaggerate it. A drowning man generally lacks the
options either to dissemble, or keep his voice down. The author's
understanding, gentle reader, is that Tom mentions some details of
this circumstance only because he sees few options to repair the
situation himself, and calls upon his fellow hackers throughout our
industry to help hack the situation, in all of its multi-faceted
aspects.
If Tom were speaking directly, I think he would want to close this
note by acknowledging and expressing gratitude for those individuals
who have staved off the subway-grate option for the past couple of
months with their generous, personal, financial contributions -- they
have kept him in chicken wings and home-made pizzas and curries along
with the occasional fiscally irresponsible beer -- and they have,
above all, helped to keep him from completely giving up hope.
Back to the topic:
2. Conflict markers!! Regular 'patch' will just crap out on
conflicting hunks -- this behavior is poo. 'svn patch' could
behave just like 'svn merge', except from a stream source
instead of a repository. :-) Now tell me that isn't Goodness!
Whether conflict markers are goodness or not depends heavily on the
nature and functionality of adjacent tools. There are good reasons
to think that neither patch-style .rej files or merge-style conflict
markers are quite the right thing. It's an interesting area to visit
with a fresh perspective.
"You will save me, or I shall drown." -- A generation of (mostly) dead
English teachers everywhere, stressing the importance of "proper"
grammar when in a pinch.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by Ben Collins-Sussman <su...@collab.net>.
kfogel@collab.net writes:
> IMHO we would do better to recommend that people install a patch
> program than take on the responsibility of maintaining such code
> ourselves.
>
> Someday, if/when we have a patch format that does more than
> conventional patch format, then we can consider a new tool.
I agree. We've talked about this idea in the past.
The reason we have 'svn diff' is because there's no easy way to use
plain old GNU diff to produce a patchfile describing every changed file.
(You'd have to run 'svn status', grep for 'M', cut out the filename,
and pass to GNU diff, along with some pattern to locate the text-base.
Yuck.)
But plain old GNU 'patch' works fine. You just run 'patch -p0 <
patchfile' as usual.
As Karl says, someday when 'svn diff' is able to produce a "next
generation" patch format that describes tree changes, then it makes
sense to have 'svn patch' which interprets the new format as well.
- Ben, who is waiting for Tom Lord to start a project to define said
format. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn_client_patch()
Posted by kf...@collab.net.
IMHO we would do better to recommend that people install a patch
program than take on the responsibility of maintaining such code
ourselves.
Someday, if/when we have a patch format that does more than
conventional patch format, then we can consider a new tool.
"SteveKing" <st...@gmx.ch> writes:
> I'd like to make a request for a new/missing function:
>
> svn_client_patch()
>
> as the 'reverse' of svn_client_diff().
> The GNU patch program is not installed on every
> system and it has a _lot_ of options to set.
> Also it would be more user friendly if an 'svn patch'
> would exist because it wouldn't be necessary to
> learn the parameters of another tool.
>
> What would be great is if svn_client_patch would also
> take a log message and include that in the diff file.
> Then the svn_client_patch would extract the log
> message and store it somewhere (in a file or registry)
> and on the next commit the log message from the
> diff file would get automatically filled in...
>
> I haven't found an issue for such a function - shall I
> write one?
>
> Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org