[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