Am 13.04.2018 um 23:03 schrieb Guillaume Hoffmann:
> * decide if include DarcsDen as part of Darcs' repository to avoid bitrot

A bold move. I understand the motivation but I am not comfortable with
the idea of adding external and to a large extent completely unrelated
code to Darcs.

I think with backpack finally happening we may have a better option:
darcsden could define a signature for everything it uses from the darcs
library. We can then check whether we still conform to this signature
and also have it documented.

> * depend on cryptonite for SHA256 and SHA1 hashing?

I am definitely +1 on that one. I would like to get rid of much of the
low-level stuff that has been added to Darcs in the past, mostly as
work-arounds for deficiencies that have long since been fixed/added in
upstream libraries. Unfortunately, cryptonite in particular has an API
that I have a hard time wrapping my head around. Perhaps I should just
contact the author(s) and ask them to help us with the conversion.

> * switch test suite from test-framework to tasty? (Just because tasty
> is claimed to be more maintained than test-framework).

As long as test-framework /is/ maintained I would hesitate to do that. I
guess it is a lot of work and the gain, if any, minimal.

> Also more ideas are welcome.

One issue I would very much like us to attack is a refactor of the
rebase functionality such that the rebase patch is stored separately and
not mixed in with the normal patches. Recently discovered (and,
thankfully, now fixed) issues show how the current solution is brittle
and prone to subtle interactions. This would also get us rid of the
NamedWrapped module and data type, and also, perhaps, some of the
advanced type level programming stuff that has been added to make the
mixing of different patch types safer (Darcs.Patch.RepoType). I have
made attempts in this direction before but I think I need Ganesh's help
to sort out the details.

When/if we do that, we may consider refactoring the unrevert
functionality from using a patch bundle to storing a proper Darcs patch,
perhaps re-using the rebase patch format to track any necessary fixups
when the context changes.

Longer term plans:

In-repo branches. I wrote a lot about that lately, no reason to repeat
everything here. The main idea is to generalize inventories so that we
can have multiple "heads". Probably needs a few more rounds of
refactoring in Darcs.Repository.Hashed before we can start to implement
that. Somewhat related are my attempts at specifying and (partly)
implementing identifiers for repo states.

New patch format for darcs-3. My current thinking is that we want:

* Prim patches based on FileUUID. The current implementation passes all
property checks but it is not yet feature-complete: replace patches are
missing, hunk moves which I definitely want to have in the next format
are still stubs mostly (I need to port my implementation of them for
Prim.V1 to Prim.FileUUID, but that should be easy), plus the open design
questions I recently mentioned on @devel.

* On top of that, an implementation of the camp conflictors. I completed
a full implementation of the core algorithms (commute and merge) last
November but as usual got side-tracked (see my discussion with Ganesh on
@devel back then). A few design questions are still open IIRC but I
think we can sort them out as we go.


darcs-users mailing list

Reply via email to