[darcs-devel] open questions regarding FileUUID

[Ben Franksen]

Am 08.06.2018 um 16:34 schrieb Ganesh Sittampalam:
> On 05/05/2018 11:34, Ben Franksen wrote:
> 
>> I had one minor success with D.R.Pending: it is possible to eliminate
>> the PrimClassify dependency by abstracting the functionality for sifting
>> of prim patches into a class. The hope here is that this interface can
>> be implemented by FileUUID. The Problem is that the interface is ugly
>> and not well specified: I just turned the functions isSimple, crudeSift,
>> and siftForPending into class methods, copying what documentation was
>> there. I think this is what was previously done for PrimCoalesce, which
>> is similarly ad-hoc (its docs raise more questions than they answer).
>> Still this is a small improvement.
>>
>> I am currently trying to separate out the functions in D.R.Hashed that
>> work with pristine trees (to a new module D.R.Pristine) in order to get
>> a better picture for how an interface may look like that is polymorphic
>> over the ApplyState. I fear this will in the end require advances type
>> hackery with singleton types via D.P.RepoType because we need a way to
>> distinguish what to do depending on the patch type (and thus its
>> ApplyState). If someone (Ganesh?) has an idea how to do that I would be
>> grateful for hints...
> 
> Sorry for the very belated reply. I don't think this belongs in
> D.P.RepoType, which is basically a hack for dealing with things like
> rebase that should really be handled at the repository level rather than
> by smuggling groups of patches within a container patch.

Hm, you are probably right with that. BTW, I would be very glad if we
could join efforts to eliminate this particular wart, i.e. handle the
rebase patch at the repo level. I have the feeling this shouldn't be
that hard to do.

> In general I'd expect this kind of change to be possible by weakening
> the constraint (ApplyState p ~ Tree) to something more general like
> (PristineXXX (ApplyState p)), where Tree would be an instance of the
> PristineXXX class as well as any other pristine implementations.

Thanks. Yes, this sounds like the right way to go.

> As you mention the existing PrimXXX classes like PrimClassify,
> PrimCoalesce etc are very ad hoc and resulted from a similar exercise in
> abstracting the previous code - which was again tied to a specific patch
> type. Having the classes at least makes it possible to see what is
> required where and to start refactoring the methods further.

Yes. It's still quite difficult to come up with good generalizations.
For instance, D.R.Diff the diff algorithm is the main point where new
primitive patches are created. I think we need a way to translate Tree
changes to changes in the ObjectMap; the Tree is what the user sees and
a difference between Trees is our only way to find out implicitly what
the user has changed. We will have to come up with such a translation
anyway, in order to write a converter for existing repos...

Cheers
Ben