[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
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

This is an archived mail posted to the Subversion Dev mailing list.