So I've been involved in many discussions about what the interface to
'svn merge' should be -- on email, IRC, and whiteboard. It's a very
hairy design problem.
What I've realized is this: we've been trying to create as many
optimized shortcuts as possible. But the cost of enormous flexibility
is enormous complexity -- complexity not just in terms of programming
("are all these different syntaxes unambiguously machine-parsable?"),
but also in terms of *human* understanding as well. By the time I had
enumerated 8 different flexible syntaxes, I discovered that it would
be nearly impossible to explain 'svn merge' to a newbie. I could
barely keep all the cases straight myself!
In general, it's a Good Thing to optimize syntax around *really*
common use-cases. That's why it took us so many months to finalize a
design for 'svn status'. We all use 'svn st' many, many times per day
while coding.
But 'svn merge' is not nearly as common an operation, and I don't
think numerous syntax shortcuts are appropriate. I (and Karl) are now
of the opinion that's it's better to go for clarity at the cost of
more rigidity.
Here's the greatly simplified proposal. I've written it up as a user
would see the output of 'svn help merge':
-------------------------------------------------------------------------
merge: apply the differences between two paths to a working copy path.
usage: svn merge PATH1[@N] PATH2[@M] [WCPATH]
* PATH1 and PATH2 are either working-copy paths or URLs, specified at
revisions N and M. These are the two sources to be compared.
* WCPATH is the working-copy path that will receive the changes.
- If either N or M are omitted, HEAD revision is assumed.
- If WCPATH is omitted, a value of "." is assumed.
- If PATH1 and PATH2 are identical, an alternate syntax is allowed:
svn merge -rN:M PATH WCPATH
-------------------------------------------------------------------------
All the use cases I've discussed previously can still be accomplished,
just perhaps with a bit more typing in some cases.
Also, I should mention the "common" use case that Ben Collins brought
up. This is a situation where he has a branch checked out, and wants
the working copy to absorb some specific changes from another branch.
Assuming he's sitting at the top of his working copy, he can simply
execute:
svn merge -rN:M branchURL
Or in gstein's scenario, he has two branches fully checked out right
below "." He could then run
svn merge -rN:M branch1-wcpath branch2-wcpath
Yes, for now, you need to *know* the values of N and M. Someday there
will be metadata that already knows those values (can deduce N, and
assumes M == HEAD), and can also avoid the "repeated merge" problem.
But that's later on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 4 23:33:44 2002