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

Re: 'svn merge -rX' UI annoyance.

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-08-04 19:22:36 CEST

C. Michael Pilato wrote:
> I'm constantly frustrated that passing -rX (instead of -rX:Y) as the
> operative range for merge operations doesn't default to -rX:X-1
> behavior. Like, I wanna say "cherry pick a merge of revision 14" and
> I run 'svn merge -r14 ...' only to get bounced for not having
> specified a full revision range.
> What would others think about relaxing the 'svn merge' UI such that
> passing a single revision means, "merge that one revision"?

I'd think that is just the sort of useful default we should have. It avoids
the user having to specify something that the program could work out easily but
which is not trivial for the user or a script to work out. (That is, it's not
a simple constant like "." or "HEAD".)

Of course, for symmetry, "svn diff" should do the same. The trouble is, we've
painted ourselves into a corner by providing some less useful defaults already
in the "diff" syntax, where ":Y" defaults to ":HEAD" for URLs.

In the same vein, WCPATH defaulting to "." is not the greatest decision we have
made. For very often used commands like "status", it's handy, but for less
common and data-changing commands like "commit" and "merge", it perhaps causes
more trouble than it saves, especially if we come later to wish we could assign
a less trivial but still useful default.

So, I don't know. Should "rX" means "rX-1:X" for "merge" but something
completely different, "-rX:HEAD", for "diff" with URLs? I don't much like that.

Though it would be more difficult to implement, I think the proposal to accept
a revision keyword which means "the other revision minus one" is a better
strategy because it can be unambiguous, uniform across different commands, and
extensible in a backward-compatible way.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 4 19:23:22 2005

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.