[darcs-devel] rebase backwards compatibility

Ben Franksen ben.franksen at online.de
Sat Sep 28 20:17:25 UTC 2019


Am 27.09.19 um 18:33 schrieb Ganesh Sittampalam:
> Given we're planning on changing the internal format of rebase
> substantially, I'm wondering which formats we should maintain backwards
> compatibility with.
> 
> We already support the old-style rebase in 2.14 to the extent of being
> able to upgrade it to the current format, and there are some tests of that.
> 
> Do we also want to support the current behaviour of 2.15, which has been
> live for quite a while now? Or is it acceptable to just have a single
> upgrade step from old-style to whatever the final format we release 2.16
> with?
> 
> It'll make things a lot easier but I don't know how disruptive it'll be
> to anyone who's been working with current HEAD. Personally I don't keep
> rebases in progress for long so it won't be an issue (and anyway I'm not
> using HEAD, for bad reasons).

It would be quite disruptive for me and would mean I loose lots of
experimental changes strewn all over the place. Most of them are
conflicted now and resolving those conflicts is always difficult and
requires concentration.

To support the 2.14 rebase upgrade you will need to retain the old
Suspended, RebaseItem, and RebaseFixup data types somewhere, anyway. I
suggest to move them all into a new module D.P.Rebase.Compat, retaining
only the bare data type definition and the instance ReadPatch.

To this we must add a function that converts an old Suspended to a new
Suspended/RebaseContainer. If I am not mistaken, this function is not
hard to define.

The only twist here is that the old Suspended is parameterized over a
RepoPatch type, not a prim type. To read it and construct the old
Suspended, we need to pass in which RepoPatch type is present in our
repo, and the new Suspended/RebaseContainer is no longer aware of that
as it is based directly on the underlying prim type.

I guess it is this difficulty that you had in mind. I think there is a
simple solution but you may not like it: We define a newtype wrapper for
the new RebaseContainer type that retains the RepoPatch parameter:

newtype OuterRebase p wX wY = OuterRebase (RebaseContainer (PrimOf p) wX wY)

This wrapper can now fall back to reading an old Suspended and then
converting it, whenever reading the new RebaseContainer fails,
supporting a seamless upgrade. The wrapper is needed only while we
initially read the rebase patch.

I can think of other solutions if you don't like the outer rebase
wrapper. We could explicitly pass in the readPatch' method, wrapped in a
data type:

data PatchReader wX = PatchReader (forall p. RepoPatch p => Parser
(Sealed (p wX)))

(The RepoPatch constraint can be reduced to whatever the old -> new
conversion requires.)



More information about the darcs-devel mailing list