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

Re: RFC: change 'svn merge' default behavior.

From: Eric Gillespie <epg_at_pretzelnet.org>
Date: 2004-01-15 20:55:49 CET

Ben Collins-Sussman <sussman@collab.net> writes:

> Mike Pilato points out that if diff and merge have different
> default behaviors, it makes it impossible to run diff as a "dry
> run" for a merge.

As Greg Hudson points out, it is not impossible.

> It's likely that you'll see very different results. That's
> really the Really Big Argument for keeping diff/merge's default
> behaviors consistent.

I don't think it's such a big argument. This is not the common
case for diff.

> Further, Sander points out that the main time 'svn diff' needs
> to ignore history is when you're comparing unrelated vendor
> import trees. This isn't all that common a use-case... not
> nearly as common as using 'svn diff' for a merge dry-run.

I don't think that's it.

My primary point all along has been this:

svn export URL1 1
svn export URL2 2
diff -ru 1 2

should do the same as

svn diff URL1 URL2

It shouldn't matter whether the URLs represent files or
directories or vendor branches or whatever. In other words, Just
Diff Them Dammit! :)

If svn diff is to behave differently than diff(1) by default, we
should rename it. I don't like that option though...

> So here's a better proposal, one that I/kfogel/cmpilato like:
>
> * make diff and merge both default to noticing ancestry.
> * rename the existing long option to '--ignore-ancestry'
> * recommend this flag for vendor branching use-cases.

I don't like it.

--
Eric Gillespie <*> epg@pretzelnet.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 15 20:56:56 2004

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.