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

[Ganesh Sittampalam]

[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.]

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.

> 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?

> In other words, we can for the moment ask the question of how your
> repository will behave if you never resolve a conflict yourself, but
> only pull resolutions from other repos.  That should define the
> semantics adequately, I think.

I should hope so, since you should always be able to get the same set of 
patches in your repo by pulling as you can by recording locally.

> 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?

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?

Cheers,

Ganesh