> > But yes, I realized after writing it that I never covered inverting
> > extended patches.
> >
> > Thinking about it more, I think I've found some problems. Let's say s
> > is the starting context of A and B, and A ends with a and B ends with
> > B. Here are three problems:
> >
> > (a) I'm not sure inverses exist in general.
>
> I had thought that was the easy part:
>
> (a, b, (Qi), (nj), X, Y)^ = (b, a, (Qi)^, (nj)^, Y^, X^)
>
> where inversion for a set of names is the set of inverted names. You do
> need names to be invertible.
The trouble is that doesn't give compatible starting/ending contexts
according to the definition of starting/ending context in Chapter 4.
I want the ending context of A to be the starting context of A^ and vice versa.
But, for example, let's see what happens when you commute A;B to B';A'
and try inverting B'. (contexts aAbBc)
B' is (a, c, A;B, [B], {}, {A}). Its ending context is (a, c, A;B, {B}, {A}).
If you take B'^ to be (c, a, B^;A^, [B^], {A^}, {}), then the starting
context of B'^ is (c, a, B^;A^, {A^}, {B^}).
Probably those two contexts should be considered equivalent, but under
the current write-up they're not.
> > Maybe I
> > should change the last three words to "recording new primitive
> > patches"?
>
> Yes. Applying suggests you already have a patch.
Done:
https://hub.darcs.net/falsifian/misc-pub/patch/d6c3c2d848c8512f9d6dc6e4694f982b02742112
> > Here's my attempt to work through an example of the problem:
> >
> > * Suppose primitive patches A^ and B don't commute and we try to merge
> > A and B. So, we permute AA^B to AB'A^' and then drop A^' from the end.
> > Let c' be the starting context of A and B (because I called it c' in
> > Chapter 7).
>
> (I would rather use the primed notation "c'" for the extended context
> throughout.)
Good idea. Done:
https://hub.darcs.net/falsifian/misc-pub/patch/bab89c7257ee66c8b2936e3dea2109439bc24b38
I noticed while changing it that I had them mixed up in at least one place.
> Okay, I see the problem now. Thanks for explaining.
>
> In Darcs we don't have this problem because we do not distinguish
> between primitive and extended contexts. You can just revert the
> conflict markup and record anything you like. If this happens to overlap
> (i.e. depend on) the changes reverted by the conflict, then it is
> regarded as a conflict resolution. It is clear that this cannot work in
> your theory, so you need something else to mark a conflict as resolved.
> Sounds like an interesting problem indeed.
>
> As I remarked a while ago in a different discussion, adding a proper
> force-commute operation to darcs is unsound for the simple reason that
> we could no longer unambiguously define what it means for a repo to have
> (unresolved) conflicts: (force-)commuting any two patches makes the repo
> conflicted. Your approach solves that problem nicely, but now you have
> to find a way to get away from a conflicted repo state.
>
> Regarding your proposed solution, I think Proposition 5 cannot be true
> unless you add inverses. Here is a counter example: we have prims
> A;(B\/C), where neither A;B nor A;C commute as prims. The extended
> universe of patches adds the force-commuted sequences B';A' and C';A'',
> together with their mid-contexts. But that's it: you get two sides of
> the cube, with a common edge (A). Without inversion there is no way from
> the mid-context of B';A' to that of C';A''.
>
> If, however, you add inverses, then Proposition 5 is trivial.
I was assuming the primitive patch theory already has inverses. Is
that not normal?
I think I've found a new problem with Proposition 5, though.
Suppose A, B and C are three mutually conflicting patches with
starting context s.
Suppose I merge A and B, then I use Proposition 5 to navigate back to
the starting context s so that I can continue recording new patches.
The problem: now if I pull in C, it looks just like any other new
patch to be recorded starting at context s. So, by marking the A\/B
conflict as resolved, I've made my repository unaware that C should be
considered to be a conflict.
The only way I can think of to solve this involves recursively adding
new contexts and patches to our underlying patch theory to keep track
of what's been resolved. But I fear this may lead to some
exponentially large data structures like in Darcs-1 when the newly
added things themselves conflict.
Here's my unsatisfactory idea in a bit more detail. We add a new
context s{A, B} to the universe which has the same repo state as s,
and intuitively means "s, except we've seen a conflict between A and
B". We make s{A, B} behave like a primitive context, in the sense that
every primitive patch with starting context s can be converted to a
new (differently named) "primitive"-like patch that does the same
thing but starting at s{A, B}. (In practice, the implementation would
probably not need to be aware of whether it's recording a real
primitive patch or a "primitive"-like patch.) We can then record new
work from the state s{A, B} as if we were at a primitive context. To
resolve the A\/B conflict, we first apply Proposition 5 to get back to
s, then we apply a new patch (this also needs to be added to the
universe) called Resolve{A, B} with starting context s and ending
context s{A, B}. Resolve{A, B} conflicts with anything that conflicts
with A or B, but should be designed so that it commutes with other
"primitive"-like patches where possible.
I think something like that would solve the problem I just raised, but
I fear if you get conflicts between the Resolve{...} patches, and then
get conflicts between the Resolve{...} patches for those conflicts, it
could get bad.
I hope there's another way to solve it, or that my idea above turns
out not to be as bad as I thought, or it turns out this new problem
isn't really a problem after all.
James
_______________________________________________
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
