[darcs-users] darcs conflicts/dependencies -- is patch theory the place to start?

[AntC]

Owen Stephens <darcs <at> owenstephens.co.uk> writes:

>> 
>> I'm trying to understand conflicts and why they're so problematic.

Thanks Owen and everybody for the fulsome replies. [And apologies for double-
posting -- I thought my first attempt had disappeared. BTW my second attempt 
includes some references to support the example -- papers by Ian L in 2006 and 
2008.]

> The complications arise due to the need to be able to conceptually consider a
> darcs repo as a *set* of patches, where the order in which (non-dependent)
> patches are pulled doesn't matter.

Thanks, yes I understand a repo is conceptually a *set* of patches, and not a 
DAG [as KevinQ points out]. And yet ... by the time you've commuted a patch 
round to the target of a pull, it might have morphed quite a bit. It has the 
same 'moral effect' but is it the *same* patch??


> A conflict must therefore always track the other patches that it conflicts
> with, and must update this tracking whenever it is commuted with other
> patches/conflicts. I did write a quick wiki page on conflictors a while
> back, which may help to shed some light on their
> behaviour/implementation:         http://darcs.net/Theory/Conflictors

Thanks for the ref. Aha! That's the first place I've seen discussion of 
duplicates (which is what my example is about).

So as an outsider trying to understand the theory:
- There's lots of talk of conflicts/dependencies.
- But it's all very abstract, very few examples,
- and no distinction between duplicates vs hunk conflicts, etc.
- Are there perhaps different sub-categories of conflicts?
- Are some less intractable than others?

> But be warned, conflictors are fairly complicated, and their implementation
> is really difficult to pick apart - we are definitely wanting to replace
> them with something better.

It's not clear from what I've read (again apologies if I've not reached the 
right places), that if a depended-upon patch is already pulled to the target 
repo, that doesn't count as a conflict.

> [snip]

> Currently, in darcs' implementation, there *would* be a conflict between
> two files created with the same path, but in different repos, see this
> page:    http://darcs.net/Ideas/AddAddConflicts

Thanks for the ref. So this is a key difference with duplicate files: is the 
duplicate intended as the *same* file, or just a coincidence? (And 
since 'Makefile' is a very common name, it's impossible to tell. Having an 
internal GUID that's tied back to the originating patch is the only way.)

>> [snip]
>> - At the point of 'sliding' past the Create towards the end of Fork B,
>> - Detect it's the same patch and identical effect, so they 'cancel out'.

> Well, essentially, but it's done before any real commutation is attempted.

Thanks, "before commutation is attempted" is the bit I didn't understand.

> [snip] perhaps I just don't understand your proposal.

What I had in mind about the sorta-commutation is:
- suppose there's a file named F in the target repo
- but it's *not* the same F as in the source.
- Because after pulling the patch to Create F into the target,
- it got renamed to H -- with the same GUID
  (This is similar to the Makefile example on the AddAdd page.)
- So the Change F in the source repo
- needs to be morphed to Change H in the target.

AntC