On Wed, Mar 14, 2007 at 12:56:22AM -0700, Justin Erenkrantz wrote:
> On 3/14/07, Erik Huelsmann <firstname.lastname@example.org> wrote:
> > 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.'
Exactly. We currently only do the first of those.
Note that _these_ two requirements are mutually exclusive.
> >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
Okay, so this is the difference between the second and third use-cases
in my mail. In some cases, you want to be able to say 'generate me
something that patch will apply', and in some cases you want to say
'generate me something that I can use to replicate this change in my
working copy'. The difference between them is basically how you
represent tree changes.
Now there is no reason at all that the svnpatch format can't be the same
as one of the other two, though it'd be a bit complex: you could encode
the tree-move information into ignored diff hunks. The only reason I'm
calling it out as a separate case is that we may not want to do that by
default. (Simply because it adds a lot of extra cruft that human might
not want to read).
> To be clear, I have major UI issues with us altering our 'svn diff'
> output like that without calling it 2.0 and even then, I still get the
> heeby-jeebies as 'svn diff' is essential to so many people's workflow
> (okay, I admit it - maybe it is just me who uses 'svn diff' with
> patch) that I think altering 'svn diff' to not be patch(1)-able is
> going to cause us loads of grief. -- justin
By default, sure! I wouldn't want to change the default output either.
That's why I was proposing explicit '--format=patch' and
'--format=svnpatch' switches. (Though as mentioned above, we could make
the 'svnpatch' case compatible with the current output).
Received on Wed Mar 14 10:00:37 2007
- application/pgp-signature attachment: stored