[darcs-devel] rebase backwards compatibility

Ben Franksen ben.franksen at online.de
Thu Oct 3 18:51:35 UTC 2019


Am 30.09.19 um 07:05 schrieb Ganesh Sittampalam:
> On 29/09/2019 22:04, Ben Franksen wrote:
>> Am 29.09.19 um 15:47 schrieb Ganesh Sittampalam:
> 
>>> Just a thought - you could perhaps use "rebase reify" with current darcs
>>> to turn the rebase state into a normal bundle which would be forwards
>>> compatible and you could then resolve the conflicts at your leisure with
>>> a new version of darcs.
>>
>> An interesting idea. It would be even better if could re-suspend them
>> with the new darcs, turning the reified fixups into actual rebase fixups.
> 
> Just obliterate the reified fixup patches (either with obliterate while
> they're unsuspended, or rebase obliterate while they're suspended).

Nice. I haven't tried it, yet, but I agree that should do it.

>>> I hadn't really thought about specific implementations. I don't see it
>>> as a major problem but it'll mean having another "detect the old
>>> situation" entry point. We can pass the patch type in to that entry
>>> point and unwind it before converting to the current representation.
>>
>> My point was that you need to do something like that anyway to support
>> 2.14 style rebase upgrade.
> 
> Right, but the entry point for 2.14 upgrade is via the code currently in
> Named.Wrapped. We would need a different one to support the existing
> structure with non-prim patches. Shouldn't be a big deal but it adds a
> bit of complexity.

We may be able to throw that extra code away, once the new rebase
implementation has settled enough that I can upgrade all my repos. At
that point we can also get rid of the new-style-rebase format.

>> An internal versioning scheme for rebase-in-progress, independent of the
>> versioning of darcs? I would rather use the darcs version directly i.e.
>> "rebase-in-progress-2.16". Or perhaps do this using the "|" combinator
>> in the format syntax, though we'd need to dig up how that works, exactly.
> 
> I don't have particularly strong feelings but this may be a bit
> confusing once we release e.g. 2.18 without changing the format.

Well, I'd find it much less confusing than an independent versioning
scheme for the rebase format. So if I stumble upon a repo and darcs
tells me it cannot understand format rebase-2.16, I know that I must
upgrade my darcs version to at least 2.16. Otherwise I'd first have to
find out which darcs version introduced format rebase-v2.

>> With my proposal we could rename it right now to
>> "rebase-in-progress-2.15.2" for the current version.
> 
> There's not much point in doing it right now if we know we are going to
> have another change shortly and we still need to support the
> "new-style-..." string for your curren repos.

Right, I forgot that.

> We should certainly use
> whatever our new scheme is as soon as we change it again.

Yup.

Cheers
Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 4211 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/darcs-devel/attachments/20191003/7e04afd5/attachment.key>


More information about the darcs-devel mailing list