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

Re: gcc source management requirements

From: Robert North <aqh4uyrs3e02_at_sneakemail.com>
Date: 2002-12-11 12:55:35 CET

Zack Weinberg zack-at-codesourcery.com |Subversion list| wrote:

>Branko Čibej <brane@xbc.nu> writes:
>
>
>>Zack Weinberg wrote:
>>
>>
>>>Peter Davis <peter@pdavis.cx> writes:
>>>
>>>
>>>>(2d): Subversion currently doesn't do "smart merging", but neither
>>>>does CVS, and it will in the future.
>>>>
>>>>
>>>I may try to implement this myself, sometime early next year, if no
>>>one beats me to it. Shouldn't be hard.
>>>
>>>
>>Er, Zack? I suggest you think twice before saying "shouldn't be hard"
>>regarding something most of us have carefully avoided, for sanity's
>>sake. :-)
>>
>>Seriously: This is something that's fairly easy to hack up, but
>>excruciatingly difficult to get right.
>>
>>
>
>I'm aware of the difficulties and I have no intention of doing
>anything half-assed. However, I think that the feature can be phased
>in. In 1.0 I would really like to see Subversion record merge
>parents, even if it doesn't do anything with the information yet,
>because it's useful to humans and to future versions of the software.
>This is easy, if properties are used carry the information, which I
>think is reasonable.
>
>The second stage is 'smart merge' to the extent that ClearCase
>implements it: handling only intra-file changes and only when the
>entire content of a branch up to some point has been merged to another
>branch. It seems to me that this should also be easy, because the
>effect is simply to change the greatest common ancestor of the files
>involved in the merge. Just having this is enough for the feature to
>be broadly useful. I'd like to squeeze this into 1.0 but I wouldn't
>mind if it got delayed till 1.1.
>
Yes, I think this is doable in a short space of time.
But, I think it will probably rely on competely different infrastucture
from a 100% safe soloution.
Maybe it's best done in a script.
I was certainly considering a quick hack of this type for my personal use.

<Snip stages 3 & 4>

I think that the sbversioun guys may want handle the full problem by
representing version ancestry with some kind of directed acyclic graph
stucture, with rules to merge, and delete form the graph, plus of course
rules to compute the diffs to appy.

While I'm probably wrong about the method people are thinking of using
for a full implementation, I want
to demonstrate that it's unlikely to mesh well with a restricted
implementation.
    -Rob.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 11 12:56:20 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.