If I have a pair of patches, one which does a change and one which undoes that
change, they can be pushed together into a repository with a conflicting change
in the same place, silently losing the change in the repo that was pushed to.

Testcase:
mkdir noconflict
cd noconflict
mkdir repo1
cd repo1
darcs init
echo A > f
darcs add f
darcs record --ignore-times -a -m A -A me

cd ..
darcs get repo1 repo2

cd repo1
echo C > f
darcs record --ignore-times -a -m A-C -A me

cd ../repo2
echo B > f
darcs record --ignore-times -a -m A-B -A me
echo A > f
darcs record --ignore-times -a -m B-A -A me

darcs push -a

Now, in repo1, the file contains "A", and "C" has been lost without asking me to
resolve any conflicts.

Edwin

This sounds rather bad.  Edwin, does it happen in unstable as well?

(I think I've had similar issues with darcs rollback at some point, basically
the same thing as Edwin's except that the inverse patch is generated by darcs
rollback, and I was pulling C in.

 A
 |
 +----B----A (rollback)
 |
 +----C

It made me very superstitious and generally scared of rollback for a while...

It does happen in the current unstable.

Hello Edwin,

Thanks for the report! Please turn your example sequence into a test script and
submit it to the darcs unstable repo via 'send'. If the test is still failing,
it should get added to the "bugs" directory, with a note in the script to refer
to "issue436". If the test passes now, it should go in the "tests" directory. 

The other ".sh" tests there will be provide some useful example boilerplate
stuff to use, like "export EMAIL=test", which causes darcs to quit prompting for
an "author" name. 

   Mark

I tested with Edwin's test script tonight. First, I reproduced the issue with
the old fashioned repo format. 

Then I changed "darcs init" to "darcs --init-2". I also had reverse the "push"
to be a "pull" so conflicts were allowed by default. 

Then darcs2 noticed the conflict and behaved well, ending like this:

Backing up ./f(-darcs-backup0)
We have conflicts in the following files:
./f
Finished pulling and applying.

###

The conflict in "f" is between "A" and "C". Because I think we already have
tests like this, I'm not adding Edwin's test to the test suite, although it is a
nice and simple test. 

###

This does bring up the question for me of what the default repo format for
"init" should be in darcs 2. 

I would say casual users of darcs would mostly be using "darcs get" to start
their repos, or having private repos. "darcs get" of course preserves the format
by default, and for private repos, there are no compatiblity issues. 

Darcs users who publish public repos are more likely more advanced and aware of
the tradeoffs of having a public repo in the "hashed" format vs darcs-2 format. 

Leaving the old fashioned repo as the default encourages the use of it, and
means that darcs2 will continue to be seen as "buggy" when the weaknesses of it
are run into, and the development and QA teams for darcs will continue to spend
time triaging and investigating bug reports for issues that are already fixed in
the new format. 

( Of course, when repos are published in darcs-2 formats and users don't have
darcs-2 binaries available to get them with, there will be other problems...)