[darcs-devel] experiment: modular primitive patches and hunk move

Ben Franksen ben.franksen at online.de
Sun May 23 12:43:05 UTC 2021


I was thinking a bit more on how Prim.V1 relates to Prim.FileUUID. What
do you think about the following claim/postulate:

In the Prim.V1 world, we can associate ("recover") a unique identity for
all tracked file system objects (files, directories) using the unique
identity of the patch that adds them. More precisely, what uniquely
identifies FS objects is the /prim patch identity/ i.e. the patch
identity (hash of the meta data) plus the index of the prim patch inside
the named patch at the point (i.e. in the context) where it was
originally recorded.

(For the sake of discussion, please temporarily ignore the fact that we
don't store prim patch identities for RepoPatchV1/V2.)

If this is true, and I think it is, then perhaps the best way forward is
to unify Prim.V1 and Prim.FileUUID using the above method to retro-fit
FS object identities into Prim.V1 and its associated ApplyState (Tree),
rather than define a new monolithic prim patch theory.

The ultimate aim is a fully decoupled implementation of a file system
prim patch theory along these lines, i.e. one that is parametric in the
underlying theories about file /content/. Below that, I envision a
generic layer for pluggable primitive content patch theories, selected
by file type, that are all orthogonal to each other because you cannot
ever have any "mixed" operation involving objects belonging to different
file types. Hunks and hunk moves and replaces would belong to the file
type "line-based text", another file type would be "binary", and other
special types could be added later *without* loosing compatibility
between repositories. (Of course you need a darcs version that knows how
to handle all the content types that occur in a repo.)

Cheers
Ben



More information about the darcs-devel mailing list