[darcs-devel] darcs 2.16 TODOs

Ben Franksen ben.franksen at online.de
Mon Jul 20 00:22:51 UTC 2020

Hi Ganesh

>>> - Rename 'new-style-rebase-in-progress' to something else
>>> (rebase-in-progress-2.16?)
>> Sigh. I really wish we could dispense with this format alltogether but i
>> guess there is no other way to make older darcs versions fail here.
>> "rebase-in-progress-2.16" is okay. Can we keep support for
>> "new-style-rebase-in-progress" as a (read-only) alias, at least until
>> darcs-3.0? Or is that too much hassle?
> I think that's fine. This still needs doing though.

Okay. I might give that one a try, doesn't sound especially difficult.

There is one more point wrt rebase. I remember you sent two more patches
attached to one of our long discussions about the three rebase variants,
one with a test and one that changes the order of the force commutes on
unsuspend, which definitely improved the behavior with conflicted
suspended patches. I am not sure these were ever screened and I think
they should go into 2.16.

>>> - Go through the outstanding review backlog
> I'm doing this now, as you'll have seen, particularly now that I've got
> back to a just about ok state with the tests.

I did notice, thanks a lot!

> I still don't have a lot of free time to keep up so if new patches keep
> appearing intended for 2.16 it might keep slipping or the patches would
> have to go in unreviewed.

Sorry for that! I was already thinking about marking patches as "should
/ should not go into 2.16". I think I will stop sending patches that
aren't intended for 2.16 until we are ready for release. Note that the
last 8 or so patches are all quite simple follow-ups on your review. I
can self-accept them if that helps.

There is one patch on the tracker that I haven't screened yet because it
introduces a changes in behavior and I wanted to give you time to
consider that properly. This bundle also contains fixes to the output of
rebase commands when used interactively. That makes me think it should
perhaps go into 2.16. I do think the behavior changes are an
improvement, but if you disagree or want to postpone the decision I
think I could break out the refactors and the fixes.

>>> - document "darcs-3" format appropriately so that people don't use it by
>>> mistake
>> It's good you thought about that one, I agree this is important. But
>> perhaps we should make this change (only) on branch-2.16?
> I think it should happen on the trunk. That way we have to make an
> explicit decision to make darcs-3 format visible and it won't slip into
> 2.18 by mistake if still not finalised then.

Okay, makes sense.

Where/how do you think this should be documented? I think the only way
to produce a darcs-3 repo now is by using 'darcs init --darcs-3', so
perhaps this would be the right place?

Do you think we should also add a warning when this command is invoked?


More information about the darcs-devel mailing list