Stefan Sperling wrote on Wed, Sep 15, 2010 at 21:40:16 +0200: > On Wed, Sep 15, 2010 at 06:15:58PM +0200, Daniel Shahaf wrote: > > 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) > > Looking at the patch(1) man page, it sounds like we don't really need > to reinvent the wheel here: > > patch will choose the file name by performing the following steps, with > the first match used: > > 1. If patch is operating in strict IEEE Std 1003.1-2008 > (``POSIX'') > mode, the first of the ``old'', ``new'' and ``index'' file names > that exist is used. Otherwise, patch will examine either the > ``old'' and ``new'' file names or, for a non-context diff, the > ``index'' file name, and choose the file name with the fewest path > components, the shortest basename, and the shortest total file name > length (in that order).
(OT: using 'old' first means it'll use "foo.orig" if that's the old path and my editor uses .orig extension for backup files) > > 2. If no file exists, patch checks for the existence of the > files in an > SCCS or RCS directory (using the appropriate prefix or suffix) using > the criteria specified above. If found, patch will attempt to get > or check out the file. > > 3. If no suitable file was found to patch, the patch file is a > context > or unified diff, and the old file was zero length, the new file name > is created and used. > > 4. If the file name still cannot be determined, patch will > prompt the > user for the file name to use. > > I suppose we could implement the method described in step 1. Which of the two methods described in step 1 do you have in mind? Whatever we do, the algorithm should be predictable, i.e., a user should be able to know (from reading a patch) what path it would be applied to. > That would make us compatible to UNIX patch, and should resolve the two > use cases I have in mind. > > Step 2 doesn't apply to us. Step 3 is used already. Step 4 could be > implemented as well (but I'd prefer to do that post-1.7). > > Thoughts? >
