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

Re: svn commit: r996581 - in /subversion/trunk/subversion: libsvn_diff/parse-diff.c tests/cmdline/patch_tests.py

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 15 Sep 2010 18:15:58 +0200

Stefan Sperling wrote on Tue, Sep 14, 2010 at 21:18:26 +0200:
> On Tue, Sep 14, 2010 at 12:49:06PM +0100, Julian Foad wrote:
> > Right. The issue seems to be "How do I determine what path I should
> > apply the patch to?" If the patch style is
> >
> > --- wc/file
> > +++ wc/file
> >
> > or
> >
> > --- old_wc/file
> > +++ new_wc/file
> >
> > then you're going to be stripping the first component so it doesn't
> > matter which path you use. If the patch is just to one file and looks
> > something like
> >
> > --- wc/file.old
> > +++ wc/file
> >
> > or
> >
> > --- wc/file
> > +++ wc/file.new
> >
> > or
> >
> > --- wc/file.old
> > +++ wc/file.new
> >
> > then obviously it's not so simple and the patch consumer (person) may
> > need to be able to tell "svn patch" which path it should look at if
> > we're to be able to handle cases like this.
>
> Yes. I've been trying to come up with a good UI for selecting the right
> filename for svn patch to use. Any ideas?

Paraphrasing my commit reply a few hours ago, how about:

* Always use the name from the /^+++/ line by default (regardless of --rd).
* Have a --strip-extension flag. (Effect: filename loses everything after the last dot)
* Have a the following config option:
[[[
# ~/.subversion/config
[miscellany]
patch-strip-extensions = .new .old .orig .org ~ \
                         .merge-left .merge-right .working
]]]
for extensions that are stripped automagically.

Sounds sane? (I haven't thought about this /too/ much, so beware of
bugs in the above idea)

Daniel
Received on 2010-09-15 18:16:46 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.