[darcs-devel] Re: [darcs-conflicts] alternate (simplified) conflicts proposal.

[David Roundy]

On Thu, Jul 13, 2006 at 10:24:00PM +0100, Ganesh Sittampalam wrote:
> [btw: I suggest we stop CCing so much stuff to darcs-devel. I'm sure 
> everyone there is aware there's active semantic discussion going on, and 
> can follow it on darcs-conflicts if they want. There seems little point in 
> having darcs-conflicts as a separate list if everything goes to 
> darcs-devel anyway. I'll leave it to you to stop though, so there isn't a 
> broken thread on darcs-devel if you don't want to.]

I'm torn.  I think soon we'll be talking repo format, which is very
relevant to anyone on darcs-devel, but right now we're talking
semantics.  I'm vaguely optimistic that this time things will move
pretty quickly to implementation.

Also, some of these semantic issues (like making identical changes
with different names count as the same change) are of interest to any
darcs developer.  My leaning is to leave this discussion on
darcs-devel for now.

> On Thu, 13 Jul 2006, David Roundy wrote:
> >A *resolution* is a change that has no effect, but which specifies a 
> >single sequence of changes that are to be killed.  *Note: this 
> >definition doesn't define all behavior of a resolution, nor is it 
> >intended to.*
> 
> So if we want to replace A and B with a completely different patch, we use 
> two resolutions to kill them and apply a third patch R instead? (perhaps 
> in the opposite order). Or we could choose to keep one of the two live and 
> just kill the other.

Right.  I think we need to kill them first and then apply the
resolution patch, since otherwise the contexts wouldn't be right.

> >A *live conflict* is a sequence of changes that conflict with other
> >changes in the repository--with those changes also being part of
> >another live conflict.
> 
> By the last part, do you just mean that if A is a live conflict because of 
> B, then B is also a live conflict? I think it's a bit confusing if so, 
> perhaps because the use of the word 'conflict' here is a bit confusing - 
> to me it implies a set of conflicting things. I can't think of a concise 
> alternative, though. Perhaps refer to a patch or patch sequence as being 
> "in conflict" instead?

Yes, that's what I meant.  How about:

A change is part of a *live conflict* if it is one of a sequence of
changes that conflict with other changes in the repository.

and the extra bit isn't necesary since conflicts are mutual.

> >A *live change* is a change that is either depended upon by a live 
> >change, or has not been specified in a resolution.
> 
> What about patches that are specified in resolutions that are themselves 
> in conflict?

Ah, you mean the resolution is in conflict? I'm starting to think that
perhaps resolutions should never be in conflict.  Well, there's one
case where they are in conflict.  If they resolve a change that's
depended upon by a live change, then the resolution is in conflict
with that live change.  But I'm starting to think that apart from that
issue, they should never conflict.  They already require special merge
and unpulling rules (since they eat up other changes), and I think
that one can extend those so that a resolution can be merged with any
change (or sequence of changes) that has its same context, which will
be the case for any change that doesn't depend on its contents.

> I'm a little concerned that the ability of a resolution to remove multiple 
> patches at once will lead to confusion.
> 
> For example, consider the sequence AB, which commutes freely but conflicts 
> with another patch C, and that we want to remove A and B to solve the 
> conflict. We could either resolve A and then resolve B, or we could 
> resolve both at once. Now suppose we have pull in a patch D which depends 
> on A. This will make A live once more, but A conflicts with its own 
> resolution (doesn't it?), so now the resolution is in conflict. If we 
> resolved A and B in a single resolution, does this leave B live or dead?

I am thinking that perhaps we should require that a resolution resolve
a dependent sequence of changes.  That makes resolutions more
composable and more unique, since for a repository holding N changes
there would be only N resolutions possible, much nicer than the O(N!)
that would otherwise be possible.  Which works well with the
non-conflictingness of identical patches, as well, by increasing the
probability of identical patches.
-- 
David Roundy