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



More information about the darcs-users mailing list