> On Dec 7, 2004, at 8:38 AM, David Abrahams wrote:
>> I know it's on the SVN "todo" list, and I'm sure it's harder than
>> it looks and people much more knowledgeable than I have probably
>> thought more deeply about it, but...
>> ...It *seems* like it should be fairly easy to implement
>> something that uses properties to keep track of which revisions'
>> changes have been included in any revision of a file. From there
>> doing a smart merge is "just" a matter of repeatedly merging the
>> disjoint difference ranges between these two lists. The whole
>> scheme could be built into a proof-of-concept wrapper over svn to
>> begin with.
>> Any further insight into this problem would be much appreciated.
> How about the fact that it's "merely" taken hundreds of engineers at
> least 10 years of coding to get this "simple feature" implemented
> correctly in ClearCase and AccuRev? :-)
> There are many smart-merging problems to solve, and this is just one
> of them. You can read about some of the other ones here:
Then why don't you solve the simplest/most common issue of them:
CVSNT has a partial solution for repeated merge and we're very happy
Unitl SVN has some solution we're stuck with CVSNT.
If subversion want's to be a compelling replacement for the CVSNT,
then there has to be some support for repeated merge.
Received on Wed Dec 8 16:16:06 2004
This is an archived mail posted to the Subversion Users