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!
Received on 2010-09-14 21:19:12 CEST