On Sun, Nov 22, 2020 at 07:58:18AM +0100, Ben Franksen wrote:
> Am 21.11.20 um 22:25 schrieb James Cook:
> > I was, however, thinking that deactivation would be "permanent" or
> > "sticky", in the sense that once a prim patch has been deactivated, it
> > cannot be re-activated except by obliterating the thing that
> > deactivated it.
>
> What is that "thing that deactivated" a patch, say P?
>
> If it is any other patch Q (present in our repo) that conflicts with P,
> which is how I understand the idea, then your patch theory is equivalent
> to that of Darcs! Because this is exactly what a conflictor is/does: it
> "deactivates" any previous conflicting patches (unless they have already
> been deactivated). It also deactivates itself, of course.
>
> But we wanted to design a different patch theory. One where I can pick
> and choose among conflicting (sequences of) named prims. And where any
> conflict resolution I am doing manually is just another conflicting
> variant I add into the mix. Or at least that is how I understood the idea.
>
> Let's make this all a bit more concrete:
>
> Show me a scenario in which your system behaves differently from Darcs
> in a user-visible way. A simple example to demonstrate what you want to
> achieve.
I put some examples in the write-up I just linked
(https://www.falsifian.org/a/xxOw/misc.pdf). Section 4.1.1 shows that
it allows a few different ways to resolve conflicts, including
Darcs-style replacement of the original patches, or keeping one of the
two patches and "rebasing" the other one on top of it (by recording a
new prim patch with a new name, but which is intended to have the
effect of the other conflicting patch). I think it could also be used
to allow non-destructive manipulation of repository history; I wrote
about that in 4.1.5 but didn't go into much detail.
> >> However, after writing the above I realised that this idea has a serious
> >> flaw: a repo is no longer defined by the set of patches that it
> >> contains! If A and B conflict, then one repo may have {A,(B)}, while
> >> another repo has {(A),B} (where the notation (X) means that X is inactive).
> >>
> >> If instead of marking patches as active/inactive we add inverses for
> >> inactive patches, as you proposed above, we can avoid that problem. So a
> >> conflict resolution always has to be a new patch that (at least) inverts
> >> all but one of the conflicting alternatives. Such a theory will be even
> >> closer to that of Darcs with (V3) conflictors.
> >
> > This is essentially my motivation for making deactivation "permanent".
> > It makes merging of repos easier to reason about.
>
> You need to be clearer about what you mean when you say "permanent". In
> a distributed VCS you cannot influence what happens in other
> repositories. So a (named prim) patch may be active in one and inactive
> in another repo. When these repos exchange patches, will they have to
> exchange information about active/inactive state of their patches? In
> that case you violate the principle of "a repo is a set of patches". If
> not, then how can the overall behavior be any different from that of Darcs?
In the end, I was able to allow patches to be re-activated. (It might
have been simpler not to, but I think it's worth the complexity.)
My section on "destructive" and "non-destructive" operations (4.2.4)
suggests a possible definition for "permanent". A state of affairs is
"permanent" if it persists through any non-destructive operation.
For the most part, my write-up actually does violate the principle that
"a repo is a set of patches", but this is mitigated by two things:
* A partial ordering on repositories, that shows we can still make
sense of what should happen when pushing/pulling and recording new
changes.
* In Section 4.2.11 I attempt to show how to keep some aspects of "a
repository is a set of patches". Specifically, a "tree patch
repository" (Definition 21) is in some sense identified by the set of
"tree patches" in it.
> >> It is also unclear to me how to handle a repo with unresolved conflicts:
> >> on the one hand the inversion is part of the resolution instead of being
> >> part of the (conflicted) patch, but on the other hand we cannot have
> >> both conflicting patches applied! So your VCS will have to add some sort
> >> of "automatic resolution patch". Unfortunately, such a patch cannot be a
> >> first class citizen; for instance, we cannot obliterate it.
> >
> > Hopefully we won't need the "automatic resolution patch". Instead, we
> > could do this. First, create pending changes that deactivate both
> > conflicting patches, but don't record them yet. Then modify the working
> > directory by adding conflict resolution markers. The user should then
> > resolve the conflict by editing the files. When they record, the two
> > pending deactivations will be included as part of the "conflict
> > resolution" patch they make.
>
> What if I revert all pending changes? This will remove
