[darcs-users] darcs conflicts/dependencies: am I understanding right? Are they too restrictive?

[Anthony Clayden]

Hi darcs team,

Can I first say what an interesting intellectual puzzle is
patch theory. I can really see the usefulness in being able
to 'cherry pick' patches, and do so being sure I'm getting
the same 'moral' effect.

Can I also say that it's really hard to figure out what's
going on in the darcs world from the wikis and published
papers. (This is by way of apology if there's already an
answer to my question -- it's just that I've failed to find
it.)

I'm trying to understand conflicts and why they're so
problematic. I saw in one of the papers an example [Ian L's
2006 paper An Algebra of Patches, section 4.1 Dependencies;
similar to Ian's 2008 paper Darcs Patch Theory, Definition
5.5 'sensible' patch sequences.]:
- I want a patch from you that is a change in content for
file F.
- But preceeding this change in your repo is a patch that
creates file F.
==> So there's a dependency: can't commute a change to a
file before its creation, in order to 'slide' it round to my
repo.

At first sight that scenario seems daft:
- Presumably F didn't exist in the repo at the common point
of origin
  where you and I forked apart. (Otherwise the create
couldn't have been valid.)
- So the change to F wouldn't be valid in my repo.
- So I should be pulling both the create and the change.

But on further thought I saw it:
- My repo has already created F.
- (Let's furthermore say that the only difference between
the repos
   is that I have some unrelated change to file G.)

So we have:
- O -> yours ->             Create F -> Change F
    -> mine  -> Change G -> Create F -> (try to) Pull the
Change F

Am I right in thinking the Pull would give a conflict under
darcs theory?
That the Change F would have to commute with the Create F,
but can't?
And similarly if I tried to pull both the Create and Change,
there would be a conflict with the Create that's already in
my repo?

(Of course the situation could be a lot more complicated: F
could have been renamed or moved along the way; there might
be other changes to the content of F -- which is why darcs
has to 'slide' the patches through all intervening changes.)

So to resolve this scenario, would this approach help?:
- The Create F in my repo must be pulled from yours.
  Not just create a file which happens to have the same
directory/name
  (that could just be a concidence).
- Pulling the Change F detects the dependency on Create F,
  and validates that the patch is already pulled into my
repo.
- Then 'slide' both the Create and Change into Fork B.
- At the point of 'sliding' past the Create towards the end
of my history,
- Detect it's the same patch and identical effect, so they
'cancel out'.

I think this should manage the risk of combinatorial
explosion, because the rule is that depended-upon patches
must have already been pulled into the target repo.

I understand that real-life conflicts are much more complex,
and are typically conflicts of partially overlapping 'hunk'
changes. But would it help there to have a rule that
depended-upon patches must be already pulled into the
target?

[This is something like the thinking in
Loh/Swierstra/Leijen's 2007 A Principled Approach to Version
Control, using an 'internal identifier' for the file (or the
change) that points to the patch where it was first
created.]

Thank you
AntC