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

merging enchancement request

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-01-09 17:37:56 CET

I'd like to file a new enhancement request, assuming everyone agrees
with this proposal. (I'm not sure whether it would be post-1.0 or
not.) The proposal is super simple; don't be scared by by
verbosity. :-)

When our merge process discovers a conflict, we drop three fulltext
files into the working directory:

    filename.UUID.mine
    filename.UUID.rX
    filename.UUID.rY

This always happens, regardless of whether diff3 is able to insert
conflict markers (text files) or not (binary files).

The problem is that these filenames are optimized for the common case
of merging a set of changes from one branch to another:

    svn merge -rX:Y http://some/branch .

But Brandon Ehle points out that when you're merging vendor branches
(in the way recommended by our docs), it involves importing vendor
releases into separate directories and then comparing them:

    svn merge http://vendor/branch/1.0 http://vendor/branch/1.1 .

The problem here is that the things being compared are in the same
(HEAD) revision. So when you get conflicts, you end up with things
like:

     filename.UUID.mine
     filename.UUID.r182
     filename.UUID.r182

And it's basically impossible to tell which of the .r182 files is on
the "left" or "right" side of the merge.

The enhancement I'm recommending is that we add the words 'left' and
'right' to our output suffixes, to disambiguate:

     filename.UUID.mine
     filename.UUID.left.r182
     filename.UUID.right.r182

If no one objects, I'll file an enhancement issue. Really, this is
probably a five-minute code change too. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 9 17:40:42 2003

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.