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.
>> 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?
>> 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 the markup as
well as the pending changes that remove the conflicting patches.
Furthermore, pending changes are (at least in Darcs) unnamed prims. That
makes sense because when the user edits a file or says something like
'darcs add filename', we don't yet have a patch name for that prim.
The only viable solution to this problem would be to store the "open
conflict" patches separately from regular pending patches and also make
them "unrevertable". But again, that seems to be equivalent to what you
have in Darcs with conflictors.
Cheers
Ben
_______________________________________________
darcs-users mailing list
darcs-users@osuosl.org
https://lists.osuosl.org/mailman/listinfo/darcs-users
