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

svn merge interface

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-04-04 23:32:31 CEST

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

    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

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.