[ANN] Monticello Versioning
Colin Putney
cputney at wiresong.ca
Wed Jul 23 22:03:01 UTC 2003
On Wednesday, July 23, 2003, at 01:30 PM, Julian Fitzell wrote:
> Colin Putney wrote:
>> On Wednesday, July 23, 2003, at 12:36 PM, Avi Bryant wrote:
>>> The way Monticello currently does a three-way merge is by combining
>>> two patches - so, for example, if you have
>>>
>>> B
>>> /
>>> A
>>> \
>>> B'
>>>
>>> and you want to produce C by merging B and B', you take the patches
>>> (B-A)
>>> and (B'-A) and combine them (possibly resolving conflicts in the
>>> process)
>>> into the patch (C-A). You then apply (C-A) to A and get C.
>>>
>>> Now, your 4-way case probably isn't as simple as combining the
>>> patches
>>> (E'-D') and (D-A), and then applying the resulting patch to A - or
>>> is it?
>>> What are the cases where that wouldn't work? (As you can see, I'm
>>> still being lazy).
>> Yup, I think it is that simple. The one caveat is that it's possible
>> to produce an inconsistent snapshot (ie, one with unfulfilled
>> dependencies), which you can't do with a three way merge.
>
> Well, in CVS or SVN with, let's say C code, it is definitely not that
> simple - but I can't remember the details and don't have time to look
> it up right now - I will do so at some point. Like I said in my other
> email, though, it is possible that it *is* that simple in this case
> because of the extra information we maintain (SVN doesn't do anything
> with ancestry yet).
No, of course. If you're dealing with line-oriented diffs between text
files, it's much more complicated. Luckily our situation is much
simpler, not so much because of extra information, as because we model
the semantics of of the code rather than the contents of a bunch of
files.
>> Let's say that (C'-B') added a class, and (E'-D') added a method on
>> that class. If you apply (D-A) and (E'-D') to A, you end up with the
>> method, but not the class. That's semantically correct, in that it is
>> what you asked for, but you can't actually load it into the image.
>
> Yes, when you start merging stuff you absolutely need to know what you
> are doing. But this is also the case if you merge two whole branches
> together: you probably won't end up with missing classes but you may
> have other incompatibilities that aren't detectable as conflicts but
> do still break.
>
> This is why I always make a big deal when people commit unlrelated
> things together or make line ending changes while making code changes.
> If your commits are small, you can say that you need, version X, Y, Q,
> and R to get a particular piece of functionality that you want out of
> a discarded branch. Or you can revert a particular change by applying
> those changes in reverse.
No, it's not the same problem.
With a three-way merge, you can't produce an inconsistent snaphot. You
can produce a snapshot that doesn't work correctly - it may not pass
its tests, for example, but it will always represent a state of the
package that you could have created in the image and then saved as a
version.
With the four-way merge scenario, it's possible to produce a snapshot
that won't even compile. That breaks an important invariant within
Monticello, and I don't think we want to allow that.
Colin
More information about the Squeak-dev
mailing list
|