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? > Or do we look at the "Index" line as well, or instead? No, we don't look there. > The 'file.old'/'file.new' style perhaps isn't well suited to complex > (tree-change) patches, so maybe we don't need sophisticated support for > it and should concentrate on supporting the styles in which any 'old' or > 'new' designations only appear in the leading stripped components of the > paths. I think we need to support both cases. But complex tree changes will be covered by git-style diffs. The case we're looking at is a "normal" unidiff, so there isn't much tree-change support to begin with and we don't need to worry about it. > > b) make svn patch --reverse-diff work for locally added files, > > which currently doesn't work because of a bug -- svn patch > > says the change had already been applied and does nothing. > > +1 to fixing this bug! OK. I'll go down that route so. Thanks!
