On 3/14/07, Peter Lundblad <firstname.lastname@example.org> 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:
When that file is *also* modified, the diff should only contain what's
actually modified and probably look like this:
<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 :-)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Mar 14 08:51:27 2007