[darcs-devel] conflicted rebase (or rather: rebase with conflicted fixups)

Ben Franksen ben.franksen at online.de
Mon May 25 09:47:28 UTC 2020


Am 24.05.20 um 22:31 schrieb Ben Franksen:
> The new version of rebase is of course incompatible with the old one.
> There is no upgrade function yet; I think writing one wouldn't be too
> hard; this would require to restore a few bits of the old code, which up
> to now I didn't bother to preserve.

The upgrade path here is not quite as clean as it was with your fully
prim based rebase. The latter is a forgetful operation: you convert from
RepoPatches to prims, using fullUnwind as when suspending a patch. To
upgrade to my version of rebase means we read prim fixups and have to
convert them to RepoPatches.

A simple solution is just call fromAnonymousPrim to upgrade prim fixups
to RepoPatches. Assuming that the generated prim patch IDs are unique,
converting an existing "0.0" rebase state won't be any more unsafe than
it already was before the upgrade.

It is tempting to try to do better and check each conflicted suspended
patch to make sure it does not have any dangling references; and if it
does, replace it with its effect. However, this could only be thoroughly
checked for RepoPatchV3, and for this format there are no existing repos
yet, so we don't need an upgrade path. V1 Mergers are definitely
self-contained (they contain all conflicting patches recursively), so
dangling references cannot occur here. For V2 Conflictors I am not so
sure, but neither would I have any idea how to check that they are
valid. The only safe thing we could do here is to unconditionally
flatten them to their effect and then create a new identity for them. I
think this would be overly conservative, though.

I have implemented the simple upgrade scheme sketched above,
back-porting your D.P.Rebase.Legacy.Item module and the associated
changes to the ReadPatch instance for Suspended. The two rebase-format
related tests succeed now, as expected.

BTW, with this last change there remain only two places in the darcs
library where fromAnonymousPrim is called. The other one is in the V2
implementation, and that one is benign as for V2 prims it does not have
to conjure up random prim patch IDs.

I'll look into the last failing tests/hijack.sh as my next step. When
that is understood and fixed, we need to come to a decision: either we
go with this "conflicted fixups" version of rebase and abandon your
fullRewind approach. Or we try to come up with an improved version of a
prim based rebase that somehow fixes its current problems.

Cheers
Ben



More information about the darcs-devel mailing list