[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 12:32:26 CET

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

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?



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

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.