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. Cheers Ben _______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
