[Gnu-arch-users] Re: darcs vs tla

[Catalin Marinas]

Thomas Lord <address@hidden> writes:
>     > From: Dustin Sallings <address@hidden>
>
>     >         There was a comment earlier about how you have to understand
>     > darcs' concepts of patch theory to use it properly, but it seems
>     > to me that arch requires way more understanding than darcs does
>     > for normal use.
>
> That's probably true but only because it let's you do more, too.

Actually, the darcs patch operators include all the arch merging (plus
the hypothetical pure-merge). Apart from this, I agree that arch has
more features.

Why is 'tla update' needed? Because you might want to get a big patch
you do not control and you prefer to fix the conflicts/rejects caused
by applying your changes. 'tla replay' is quite useful for
cherry-picking and also by merging external changes on top of the
existing changes. These two mainly decide which set of patches is
applied first and which is applied in the context of the other.

'tla star-merge' looks (correct me if I'm wrong) like applying a big
patch composed of several external changes on top of the existing
changes (a 'replay' but smarter if you use --three-way). It has some
features like determining which patches were merged in which
direction.

All of these are not needed in darcs and a 'pull' command is
enough. Arch needs all of these because the patches are applied based
on the context (the diff/patch tools) but darcs calculates the
position. You will never get errors like "text to be patched not
found" with darcs.

An example for those who don't know how darcs works (I don't fully
understand it either), two trees with a set of changes (tree B created
by branching after the A3 patch):

Tree A:    A1 A2 A3 A4 A5 A6
Tree B:    A1 A2 A3 B4 B5 B6

After A3, the development continued in parallel on the two
trees. Later on, you want to merge the latest changes in tree A onto
the tree B. You have 3 (or 4) ways to do this with arch, depending on
whether the B4-6 are more important (or easier to fix if conflicted)
than A4-6. It is also likely with arch that some hunks cannot be
applied at all because the context is not found (star-merge
--three-way might be able to fix this but it doesn't work well if you
cherry-picked changes before).

Darcs will not change the B4-6 patches but try do derive the A4-6
patches so that they can be applied after B4-6. If two patches
conflict (i.e. A4 and B4 change the same lines of a file), a merger
patch is created which contains both changes in a 'star-merge
--three-way' or CVS-like conflict (in-file marks). This merger patch
can also include other merger patches. After all the merge is
completed, the conflicts can be resolved and darcs unwinds the merger
patch so that the derived A4-6 patches are correctly determined
(i.e. if one of the hunks in A4 conflicts with other in B4 and you
decided to only keep the B4 change, the corresponding hunk in A4 is
removed from the derived A4).

I think a 'star-merge --three-way' with the ability to cope with
cherry-picking would pretty much get close to the darcs style of
merging but the individual changesets would be lost ('pure-merge
--three-way' might not be feasable since you might not care about
conflicts too far away in the history, which might be removed by later
changes).

Maybe somebody with more darcs knowledge can explain this better (or
we could cross-post to the darcs-user list).

Catalin