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

[Ganesh Sittampalam]

Hi,

On 23/05/2021 13:43, Ben Franksen wrote:

> 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.

I think this is true, but it doesn't address the question of commute
behaviour. The most important thing we want to improve on from Prim.V1
is to not have conflicts (in the sense of things needing to be handled
at the RepoPatch level) between patches that cause name collisions.

> 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.)

Agreed about separating different kinds of content - this was one of the
other directions I wanted to go with my refactoring that I forgot to
mention. But I don't think it depends on unifying Prim.FileUUID with
Prim.V1.

Ganesh