> >> I still wonder if a consistent patch theory *different* from
> >> camp/darcs-3 could be devised in which conflict resolutions really are
> >> freely exchangeable with the conflicted patches instead of depending on
> >> them. In other words, we may *choose* one of the conflicting patches as
> >> the resolution (creating a new one if none are suitable). I think this
> >> would require, in the tree view, to add a special flag to mark such
> >> patches as the chosen resolution. This would make the theory more
> >> symmetric and would perhaps also make resolving conflicts easier to
> >> handle; and perhaps simplify commute and merge, too. I haven't thought
> >> this through, though, and it may turn out that this doesn't work.
> >>
> >> Cheers
> >> Ben
> >
> > I think the goal I described in my other email just now would end up
> > looking something like this, but with inverses on all the not-chosen
> > branches instead of a flag on the chosen branch.
>
> Let me know if you have something concrete that looks promising.
>
> Cheers
> Ben
Hi Ben,
I just picked this up again. I do not have a solution right now, but I
did find an example showing a limitation of the "tree view" which I
wanted to share.
Feel free to ignore this and just wait to see if I have positive news to
share later. This is mostly an exercise for me to write up what I found
for future reference.
First, a quick recap for some context. I think you framed it best in the
quotation at the top of this email. I would like a patch theory where
conflict resolutions are just new patches that replace the conflicting
ones, and don't depend on the patches they're resolving.
We had talked about doing this by representing a repository as a tree of
patches rooted at the start context, and one path from the root is
flagged as the "chosen resolution" (or, everything outside that path is
marked as deleted).
My example will show that if we do things that way, we must allow
patches to appear in more than one place in the tree (in other words,
multiple patches with the same name). Fortunately, these duplicate
patches don't appear along the "chosen resolution". So, if we're
careful, they might not cause any real trouble, but it's still a bit
disappointing to me, since it would have been neat and tidy to have
every patch just appear once.
I'm going to start thinking about what we can do if we simply accept
that our repository might have multiple patches with the same name
(but not along the chosen resolution).
********
The example: suppose we want to merge these two repositories.
b a d
*-->*-->*-->*
|
|f
v
*
c a' e
*-->*-->*-->*
a and a' have the same names. For this example, I'm not concerned
with the chosen resolutions, but you could imagine for example
they're b,a,d and c,a',e.
Suppose:
* b and c conflict.
* a conflicts with f;
* b and f don't commute;
* d doesn't commute with b or a;
* e doesn't commute with c or a.
Just to show that could really happen, here are some patches that behave
like that:
* a and a' create a file called "a".
* b and c create a file called "b".
* d and e both delete both files "a" and "b".
* f creates "a" and deletes "b".
I claim the merged repository must have two patches with the same name.
Proof:
The merged repo has to be a tree with all the patches a, b, c, d, e, f.
(This is an assumption --- when we merge repos we keep all the patches,
and repos are always trees.)
Since d depends on both a and b, our tree must have a node where both a and b
are applied, i.e. a path from the root with the names a and b.
Similarly, because e depends on a and c, there must be a path from the
root with the names a and c.
Suppose the merged tree has only one patch named a. (Otherwise we're
done.) Then the a,b and a,c paths both have to share that same patch.
Since b and c conflict, a has to come before both b and c. The situation
looks something like this:
a b d
*-->*-->*-->
|
|c
v
*-->*
e
Now, f has to appear somewhere in the merged tree. f depends on b but
conflicts with a. So somewhere in the tree there needs to be a patch
named b that doesn't have a before it. So we need another patch named b.
QED.
In other words, the merged repo either has two patches named a, like
this:
b a d
*-->*-->*-->*
| |
|c |f
v v
* *
|
|a'
v
*-->*
e
or has two patches named b, like this:
a b d
*-->*-->*-->
| |
|b' |c
v v
* *-->*
| e
|f
v
*
We could simplify the example by removing f and asserting a doesn't
commute with b or c. But I think that situation could not arise in
practice: if we see a in the context b and also in the context c, that
implies it commutes with both, otherwise how could it have ended up in
both places?
--
James
_______________________________________________
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
