I just ran darcs unrevert and it said "We have conflicts".  Is that  
supposed to happen?  I would have assumed that you just lose the  
option of unreverting if you've made a conflicting change.  Also, I  
then said not to do any unreverts but it appears to have still  
changed my working directory.  :-(

HACK bryces-powerbook-g4-12:~/playground/allmydata/tahoe/trunk$ darcs  
unrevert
Backing up ./src/allmydata/web/check_results.py(-darcs-backup0)
We have conflicts in the following files:
./src/allmydata/web/check_results.py
hunk ./src/allmydata/web/check_results.py 618
-            return T.div[T.a(href=return_to)["Return to file/ 
directory."]]
+            return T.div[T.a(href=return_to)["Return to parent  
directory"]]
Shall I unrevert this change? (1/2)  [ynWsfvplxdaqjk], or ? for help: n
Skipped unrevert of 1 patch.
You will not be able to unrevert this operation! Proceed? yes

On Tue, Apr 07, 2009 at 18:09:10 -0000, Zooko wrote:
> I just ran darcs unrevert and it said "We have conflicts".  Is that  
> supposed to happen?  I would have assumed that you just lose the  
> option of unreverting if you've made a conflicting change.  Also, I  
> then said not to do any unreverts but it appears to have still  
> changed my working directory.  :-(

My guess is that the following scenario crept up:

 revert
 pull a change that conflicts with the reverted change
 unrevert (now we have a marked-up conflict in the working dir)

which seems plausible

Yes, that might have been what happened.  Is this behavior expected, then?

On Tue, Apr 07, 2009 at 18:40:54 -0000, Zooko wrote:
> Yes, that might have been what happened.  Is this behavior expected, then?

I don't find it particularly surprising.

The alternative would be not to let you pull the patch (because of a
potential conflict with unrevert, or alteratively, warn you of the
unrevert conflict, which would lead to spurious conflicts).

This just lets you dump a conflicting change into the working directory,
which I don't find shocking.

I'm going to mark this not-our-bug (for want of an "invalid" priority)  for now,
as I think this is an expected behaviour.  Feel free to reopen if you feel
otherwise.