> So this can succeed only if c does not conflict with either of its
> sibling cancelled branches, that is, if c^ commutes with all sequences
> ("paths") in the cancelled branches, that is, all elements of {d, e;f,
> e;g, e;h;i}. We then get
>
> a--b'-c'
> |\
> d' e'-f'
> |\
> g' h'-i'
>
> where we dropped the result of commuting c^ past.
I think I'm missing a piece (or maybe you made a mistake). Where does
c^ come into the picture? Also, shouldn't b be unmodified?
Let me go through this in a bit more detail, to explain what I mean
and help myself make sure I understand.
I'll simplify your example a bit to this:
a--b--c
|\
d e
Actually, I'd rather put the patches on the edges. I guess the above
tree becomes:
a b c
*--*--*--*
|\
d| \e
* *
I can see two ways to represent that tree with linear sequence of patches:
(a) Create a conflictor e' by commuting (d^, e) <-> (e'', d'^), and
represent the above tree as a b d e'' c. I guess this is the Darcs
way.
(b) a b d d^ e e^ c. This follows my idea of handling conflicts by
cancelling out everything involved in the conflict.
Now, we want to rearrange it to:
a b c'
*--*--*--*
|\
d'| \e'
* *
In version (a), that just means re-ordering d e'' c to c' d' e'. In
version (b), it means reordering d d^ e e^ c to c' d' d'^ e' e'^. Does
that all sound correct?
> Note that we did employ inversion of the patch c here, but it is now
> apparent that it is only needed temporarily to move the conflicted
> branches to a new context.
>
> I think this theory is completely equivalent to that of Darcs in the
> sense that all operations have the same semantics. However, we can no
> longer represent the set of patches in a linear sequence, so this would
> have to have quite a different UI.
I wouldn't be surprised, except note that I found two interpretations
(a) and (b) above. (I didn't realize that until I began writing this
email.)
I wonder if the (b) interpretation allows some other applications of
inverses, other than conflict resolution. For example, you can go
through the same motions if there's only one branch in the "conflict"
(e.g. take my simplified example above but without the "e" branch).
This is nonsensical for actual conflict resolution (with just one
patch, there can't be a conflict), but maybe appending the sequence
d^c could mean c is an "amendment" to patch d.
> Whether that helps in your quest for a theory with unrestricted
> commutation is hard to say. The side conditions we have to impose on
> whether we are allowed to commute b;c to b';c' do have a certain
> similarity to how your "re-arrangement" of sequences depends on the context.
>
> Conflictors in Darcs can be seen as "internalizing" the relevant parts
> of the above tree structure /into/ the (conflicted) patch
> representation. This is the source of their complexity. What we gain
> form that is the possibility arrange all patches in a repo in a linear
> sequence where commutation is the only allowed (and required) form of
> sequence re-arrangement.
Maybe it would be helpful to formalize this connection. If nothing
else, it might be an alternative way of explaining the Camp theory.
Actually, for all I know this is exactly how I'm supposed to think of
conflictors in Camp. I never fully understood that write-up; maybe I
should take another look.
> It *may* be that the tree representation is more efficient, however, so
> I think it might be worth exploring this region of the design space.
Thanks, this email was helpful. Besides efficiency, I wonder if the
tree point of view is easier to understand when the conflict is
complex. Or, without touching any implementation or UI, I wonder if it
could just be useful as an alternative way of explaining how
conflictors work.
> Cheers
> Ben
_______________________________________________
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
