In the camp paper Ian draws the conclusion that we need to add "names"
(universally unique identities) to prim patches. He claims that otherwise "the simple natural merge algorithm breaks down in the
presence of duplicate patches". This is correct. However, I don't
agree with the conclusion. Instead I think we should extend the merge
algorithm so that it can cope with such situations, for two reasons:
First, Darcs has /always/ allowed us to create situations like that.
Adding identities to prim patches would mean that we can't fix this
until we make yet another incompatible change to the patch format.
Second, being able to replace an implicit dependency with another one
that makes the same change is a very useful feature.
To fully implement that feature we must accept that we cannot define a
'merge' function for sequences of named patches with the same simple
type as for unnamed patches. If we can't pull (all) common patches to
the common past, then the result of merging ps:\/:qs no longer has the
simple form (qs':/\:ps'). In general we can only expect it to give us
a /partial/ merge (as:\/:bs) -> (bs':/\:as'), where the as and bs are
initial stretches of ps and qs up to the first common patch. We have
to return whatever remains of both sequences, too. With the remainders
we can now (again) compute a Fork with all common patches that /can/
be commuted to the heads and the remaining diverging sequences, for
which we do the next partial merge, and so on, until both lists are
empty.
Implementing that is not difficult. The main problem is that a lot of
the command implementations need to be adapted to this new merging
scheme. In particular, I am currently unsure if and how it would
interact with patch selection.
|
