[darcs-devel] PrimWithName wrapper and UUIDs

[Ganesh Sittampalam]

On 24/02/2020 21:12, Benjamin Franksen wrote:

> To make a long story short: I think there is no need to invent these
> UUIDs out of thin air. Because with RepoPatchV3 we already have
> perfectly suitable UUIDs, namely the PrimPatchId of whatever prim patch
> created the object in question.

One possible drawback of this approach is that the UUIDs of objects will
ultimately flow from the PatchInfo of the creating patch. So when we
amend, or rebase the patch, the UUID of the object will have to change.
That's manageable by propagating a rename-style fixup, but it feels a
bit awkward.

> There is a reason why FileUUID was never fully integrated into Darcs and
> it's not just that nobody bothered to do it. The main problem is that
> some of the interfaces we expect prim patches to implement simply make
> no sense and thus cannot be usefully implemented for new prim types.
> Also, lots of Repository and UI code require ApplyState p ~ Tree. You
> mentioned a long time ago that to integrate new prim types we need to
> generalize this constraint with a suitable class constraint and I agree
> that this is what needs to be done. The details of such a refactor are
> still very much unclear to me

I always find that kind of refactor flows quite nicely once you start
changing the types. Not 100% sure where the best place to start would
be, maybe in the RepoJob constructors.

Ganesh