[darcs-devel] [patch2008] introduce new rebase format (and 2 more)

Ganesh Sittampalam bugs at darcs.net
Sat Mar 7 17:07:45 UTC 2020


Ganesh Sittampalam <ganesh at earth.li> added the comment:

On 07/03/2020 10:29, Ben Franksen wrote:

> I think the right thing to do here, at least for the intermediate
> formats (i.e. between official releases), is to provide automatic
> upgrade. That is, if it finds an outdated rebase state, the user is
> prompted to confirm and then it gets upgraded to the latest version.
> This would be similar to the internal version for the index or the patch
> index, where we also do automatic upgrades. (Though I concede that the
> situation with the indexes is somewhat simpler since we can re-generate
> index information from scratch if it is outdated, which is not true for
> an existing rebase state.)
> 
> If we do it like that, we can use a simple number for the (intermediate)
> rebase versions, independent of the darcs release. This number should be
> embedded inside the rebase patch to make it independent from _darcs/format.

> [...] But I really need an upgrade path. There are lots of
> errors I find (and usually fix, sooner or later) in my daily use of
> darcs. This is invaluable to keep bugs from creeping in. And I usually
> do have a number of open rebase states and loosing them would be bad.

Using the version numbers inside the rebase patch for upgrading is a
good point I hadn't thought of. It actually already has a version number
there. If we silently update the format in ReadPatch, then it'll be a
lot easier.

I could actually switch back to the "new-style" name given the idea of
using the rebase version number instead. On the other hand I'd somewhat
like to drop that particular name, so maybe switching the format
specifier is a good idea anyway. Or maybe the new format specifier could
be some kind of alias rather than being a full blown separate one.

But regardless, supporting old formats does incur some overhead: both in
dragging around old code and in testing that the old format works.

My current submission goes through three phases:

- introduce rebase-2.16 format, that otherwise looks just like new-style
- switch to RebaseChange for storing suspendeds
- switch to prims instead of repo patches
   [technically this won't actually change the format because
    unconflicted repo patches are currently stored just like the
    underlying prim, and even before this patch we don't have any
    conflicts in rebase, but I'd rather avoid relying on this.]

I am keen on keeping the patches broken up because it really helps to
keep the changes logically separate, which they are. But I am also
unkeen on supporting those intermediate states :-)

In practice if we just push them to screened and then reviewed together,
I don't think you will actually encounter those states. But it is a bit
unprincipled.

How about if, during the intermediate states, darcs just printed out a
warning that when using rebase that the current state is temporary? So I
would introduce the message in the first patch, and remove it once I'd
finished making changes.

Removing it would also be a good point to add backwards compatibility
tests for the new format. Any future changes would then need a new
upgrade path.

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch2008>
__________________________________


More information about the darcs-devel mailing list