[darcs-users] Colin Walters blogs on Arch changesets vs Darcs
Zooko O'Whielacronx
zooko at zooko.com
Sun Nov 28 11:49:27 UTC 2004
On 2004, Nov 25, at 23:31, Andrew Pimlott wrote:
> On Thu, Nov 25, 2004 at 09:40:27AM -0400, Zooko O'Whielacronx wrote:
>> By the way, when I
>> reverted the change, it got into a state that looks wrong to me --
>> both
>> patches are present, and there are no merge conflicts or unrecorded
>> changes, but the file doesn't exist. Bug?
>
> Think symmetry.
I don't understand what you mean. Could you please explain further?
> The repo has to be in some state after the conflict, and what other
> state makes sense?
My belief is this:
1. A repository is required to equal the sum of all patches, plus
unrecorded changes.
2. For any two patches that can be combined in the same repository,
the result is required to be intuitive to the user.
a. They could be "non-conflicting" patches which result in something
intuitive to the user, for example one patch changes the contents of a
file and the other patch moves that file. Darcs already does a good
job of this.
b. If there is not such an intuitive result, then they are
"conflicting" patches and they are required to result in an explicit
and visible "conflict" state.
Darcs currently satisfies all these criteria for patches that change
the contents of a file, but it fails to satisfy criterion 2.b. for
patches that add, remove or move files or directories.
The key question is how to communicate to the user that there is a
conflict and what the conflict is. For patches that change only the
contents of a file, darcs does this by simply undoing the effect of the
patches (while leaving the patches in the repo), and putting a conflict
marker into the file itself which does two things: lets the user know
that there was a conflict in this file, and lets the user have a copy
of the contents of the hunks.
This is a simple and elegant alternative to more explicitly signalling
the conflict. For example, darcs *could* have signalled the conflict
by creating a .rej file containing one of the hunks, and changing the
output of "darcs whatsnew" to mention that there is an unresolved
conflict. However, simply putting a conflict marker into the file
itself does the same job more cleanly.
Unfortunately, there is no analogous way to implement conflict markers
at the filesystem level. Removing the file is, frankly, an atrocious
solution. Moving the file into two separate files with different names
(a la Codeville) is a good idea, but if the user invokes "darcs
whatsnew" without the -l option then he won't see the new files, he'll
see only that the old file has disappeared.
Therefore, the only way for darcs to satisfy criterion 2.b. on
filesystem-level changes is to make the conflict notification
explicitly part of the output of "darcs whatsnew" rather than just
changing the state of the repo. darcs already writes "We have a
conflict in file suchandsuch" on "darcs pull". It should emit the same
warning on every "darcs whatsnew" after that, until the conflict is
resolved. (I often miss the conflict notifications from "pull" because
there is so much output from "pull".)
So in answer to your question: "what other state makes sense?", the
problem isn't the state of the repo, but the lack of explicit
notification from "darcs whatsnew" that there is an unresolved
conflict. Even if the state of the repo were left at the current
atrocious behavior of deleting the file, the presence of a notification
from "darcs whatsnew" would make the user experience be okay.
Regards,
Zooko
More information about the darcs-users
mailing list