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. I've just 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:
- Fork B wants a patch from Fork A that is a change in content for file F.
- But preceeding this change in Fork A 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 fork B.
At first sight that scenario seems daft:
- Presumably F didn't exist in the repo at the common point of origin
where A and B forked apart. (Otherwise the create couldn't have been valid.)
- So the change to F wouldn't be valid in Fork B.
- So Fork B should be pulling both the create and the change.
But on further thought I saw it:
- Fork B has already pulled the patch to create F.
- (Let's furthermore say that the only difference between the forks
is that B has some unrelated change to file G.)
So we have:
- O -> Fork A -> Create F -> Change F
-> Fork B -> 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 Fork B tried to pull both the Create and Change, there would
be a conflict with the Create that's already in Fork B?
(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 we have to 'slide' the patches through all intervening
changes.)
So to resolve this scenario, would this approach help?:
- The Create F in Fork B must be pulled from Fork A.
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 Fork B.
- Then 'slide' both the Create and Change into Fork B.
- 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'.
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?
Thank you
AntC
_______________________________________________
darcs-users mailing list
darcs-users@darcs.net
http://lists.osuosl.org/mailman/listinfo/darcs-users
