On 3/14/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> On 3/14/07, Erik Huelsmann <ehuels@gmail.com> wrote:
> > 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
>
> 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
I don't care how we call it. Most of the time you can use svn diff +
patch(1). But currently it's not guaranteed to reproduce the correct
tree.
I think the 2 use-cases (local changes vs patch-input) are as Malcolm
says mutually exclusive. Before we start discussing actual
implementations (I'm already sorry I added that example!), I'd like a
list of requirements and a proposed solution to discuss. After that,
we can discuss how to build that into Subversion. Agreed?
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 12:32:45 2007