[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: summer of code 2007

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-03-14 08:51:11 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.