[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

_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel

Reply via email to