On 3/14/07, Peter Lundblad <plundblad@google.com> wrote:
> Hi, Justin,
>
> Justin Erenkrantz writes:
> > In other words, how does Malcolm's 'svn diff' outputting something
> > that patch(1) purposely can't read a good idea? I don't like the idea
>
> It might not be a good idea, but it is the way it currently works in
> the -rBASE:WORKING (default) case. An add with history will be diffed against
> the copy source. AFAIK, we don't do that when diffing repo_to_repo and I don't
> know about wc_to_repo. That's a mess, isn't it?
That's because we've been trying to squeeze the answer to 2 questions
into 1 command. The first being 'what did I change locally wrt the
original (base) version?'. The second being 'I don't care what local
changes I have, I want patch(1) to reproduce the tree.'
If we can move the second concept into 'svn patch --create / --apply'
then we'll be able to clean up our act with diff too. The only thing
is, I think we should let the requirement slide that patch(1) should
be able to apply the diff: just like CVS, it doesn't version trees.
What I mean is this: I think that a file-move should look like this in
a patch file:
Base-Revision: 30
Base-Path: source/path
Move-Path: dest/foo
When that file is *also* modified, the diff should only contain what's
actually modified and probably look like this:
Base-Revision: 30
Base-Path: source/path
Move-Path: dest/foo
Index: dest/foo
<your usual patch hunks>
Normal patch output would include the source as a full file removal
and the dest as a full file addition. Especially with an eye toward
review: I don't want to review full-text additions if there's new
code, but only a small percentage.
The patch above can't be applied using patch(1). Now, I can also
imagine there are other situations where it's (IMO) not practical to
have a format which has a requirement that patch should understand it.
I hope I'm being as clear as this is in my mind :-)
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 14 08:51:27 2007