I have a simple repository here with 7 patches in it.  When I try to push to
another repository which has 6 of them but not the 7th, it says I can't because
it would confict, but when I run "mark-conflicts" it says there are none.

Here is the repo.  The patch is the one named "doc: tiny edit to README.txt in
order to test out the version control -> cia.vc path (cia.vc seems to be having
server troubles)".

Attachments

• libtahoeclient_webapi.tar.bz2

Thanks a lot. I can reproduce this:

> $ darcs --version
> 2.1.2 (release)
> $ mkdir repo6
> $ cd repo6
> $ tar xjf ../../download/bugs.darcs.net/file553/libtahoeclient_webapi.tar.bz2
> $ darcs unpull -a -p 'doc: tiny edit to README.txt in order to test out the 
version control -> cia.vc path .cia.vc seems to be having server troubles.' --
repodir=libtahoeclient_webapi
> Finished unpulling.
> $ darcs mark-conflicts --repodir=libtahoeclient_webapi
> No conflicts to mark.
> $ cd ..
> $ mkdir repo7
> $ cd repo7
> $ tar xjf ../../download/bugs.darcs.net/file553/libtahoeclient_webapi.tar.bz2
> $ darcs push -a --repodir=libtahoeclient_webapi ../repo6/libtahoeclient_webapi
>
> darcs failed:  Refusing to apply patches leading to conflicts.
> If you would rather apply the patch and mark the conflicts,
> use the --mark-conflicts or --allow-conflicts options to apply
> These can set as defaults by adding
>  apply mark-conflicts
> to _darcs/prefs/defaults in the target repo.
> There are conflicts in the following files:
> ./README.txt
> Apply failed!
> $

But I am not sure what to make of it.

Best regards
Thorkil

Is the working directory of the repository you are pushing to clean?

I am not sure I understand the question. "darcs whatsnew" says "No changes!" in 
both repo7 (the original) and repo6 (original with one patch missing). The 4 
patches related to README.txt are:

> Mon Feb 16 22:12:38 CET 2009  zooko@zooko.com
>   * add note about TGPPL, remove README.txt now that I have ndurner's README
>     move ./COPYING ./COPYING.GPL
>     hunk ./README 10
>     -  (at your option) any later version.
>     +  (at your option) any later version. Also, you may use it under the 
terms
>     +  of the Transitive Grace Period Public Licence version 1.
>     duplicate
>     |rotcilfnoc [
>     |rmfile ./README.txt
>     |]
>     ||:
>     |hunk ./README.txt 1
>     |+ndurner wrote this.
>     |addfile ./README.txt
>     |:
>     rmfile ./README.txt

> Mon Feb 16 22:07:52 CET 2009  ndurner@web.de
>   * remove README.txt
>     conflictor [
>     hunk ./README.txt 1
>     +ndurner wrote this.
>     ]
>     |:
>     rmfile ./README.txt

> Mon Feb 16 21:55:45 CET 2009  zooko@zooko.com
>   * doc: tiny edit to README.txt in order to test out the version control -> 
cia.vc path (cia.vc seems to be having server troubles)
>     hunk ./README.txt 1
>     +ndurner wrote this.

> Mon Feb 16 21:33:29 CET 2009  zooko
>   * doc: create an empty placeholder README.txt to test cia bot
>     addfile ./README.txt

To my untrained eye, the second of these (* remove README.txt) looks as if there 
has been a conflict earlier. Perhaps the changes represented by the second and 
third patch were carried out in separate repositories, then pulled together. I 
have tried that, working from an empty repository, and it seems possible. But 
again, what exactly to make of this, I don't know.

Best regards
Thorkil

On Tue, Feb 17, 2009 at 10:32:42 -0000, Thorkil Naur wrote:
> >     duplicate
> >     |rotcilfnoc [
> >     |rmfile ./README.txt
> >     |]
> >     ||:
> >     |hunk ./README.txt 1
> >     |+ndurner wrote this.
> >     |addfile ./README.txt
> >     |:
> >     rmfile ./README.txt
> 
> > Mon Feb 16 22:07:52 CET 2009  ndurner@web.de
> >   * remove README.txt
> >     conflictor [
> >     hunk ./README.txt 1
> >     +ndurner wrote this.
> >     ]
> >     |:
> >     rmfile ./README.txt

Sounds related to the new darcs 2 semantics (duplicate patches don't
conflict).  Can we boil this further down into a minimal test case?

Zooko: are you blocking on this?  Or do you need us to think of a
workaround?

May be worth adding Igloo (just because he may be a bit interested)

This seems to be one way:

> $ mkdir X
> $ darcs init --repodir=X
> $ touch X/f.txt
> $ darcs add --repodir=X X/f.txt 
> $ darcs record --repodir=X         
> Darcs needs to know what name (conventionally an email address) to use as the
> patch author, e.g. 'Fred Bloggs <fred@bloggs.invalid>'.  If you provide one
> now it will be stored in the file '_darcs/prefs/author' and used as a default
> in the future.  To change your preferred author address, simply delete or edit
> this file.
> 
> What is your email address? me
> addfile ./f.txt
> Shall I record this change? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
> What is the patch name? Create f.txt in X
> Do you want to add a long comment? [yn]n
> Finished recording patch 'Create f.txt in X'
> $ echo f.txt contents >>X/f.txt 
> $ darcs record --repodir=X
> hunk ./f.txt 1
> +f.txt contents
> Shall I record this change? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
> What is the patch name? Add f.txt contents in X 
> Do you want to add a long comment? [yn]n
> Finished recording patch 'Add f.txt contents in X'

At this point, we have repository X with f.txt: Created and contents added as 
separate patches.

> $ mkdir Y         
> $ darcs init --repodir=Y
> $ darcs pull --repodir=Y X
> Tue Feb 17 13:29:01 CET 2009  me
>   * Create f.txt in X
> Shall I pull this patch? (1/2)  [ynWsfvpxdaqjk], or ? for help: y
> Tue Feb 17 13:29:32 CET 2009  me
>   * Add f.txt contents in X
> Shall I pull this patch? (2/2)  [ynWsfvpxdaqjk], or ? for help: n    <<=== Note 
n here
> Finished pulling and applying.
> $ rm Y/f.txt 
> $ darcs record --repodir=Y
> Darcs needs to know what name (conventionally an email address) to use as the
> patch author, e.g. 'Fred Bloggs <fred@bloggs.invalid>'.  If you provide one
> now it will be stored in the file '_darcs/prefs/author' and used as a default
> in the future.  To change your preferred author address, simply delete or edit
> this file.
> 
> What is your email address? me
> rmfile ./f.txt
> Shall I record this change? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
> What is the patch name? Remove f.txt in Y
> Do you want to add a long comment? [yn]n
> Finished recording patch 'Remove f.txt in Y'

So Y has the create f.txt patch and adds the remove of the empty f.txt.

> $ darcs pull --repodir=X Y
> Tue Feb 17 13:31:09 CET 2009  me
>   * Remove f.txt in Y
> Shall I pull this patch? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
> Backing up ./f.txt(-darcs-backup0)
> We have conflicts in the following files:
> ./f.txt
> Finished pulling and applying.
> $ darcs revert --repodir=X  
> rmfile ./f.txt
> Shall I revert this change? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
> Do you really want to revert this change? y
> Finished reverting.

Something like that may have happened, who knows.

> $ mkdir Z
> $ darcs init --repodir=Z
> $ darcs pull --repodir=Z X
> Tue Feb 17 13:29:01 CET 2009  me
>   * Create f.txt in X
> Shall I pull this patch? (1/3)  [ynWsfvpxdaqjk], or ? for help: y
> Tue Feb 17 13:29:32 CET 2009  me
>   * Add f.txt contents in X
> Shall I pull this patch? (2/3)  [ynWsfvpxdaqjk], or ? for help: n   <<< Note n 
here
> Tue Feb 17 13:31:09 CET 2009  me
>   * Remove f.txt in Y
> Shall I pull this patch? (3/3)  [ynWsfvpxdaqjk], or ? for help: n   <<< Note n 
here
> Finished pulling and applying.
> $ rm Z/f.txt 
> $ darcs record --repodir=Z
> Darcs needs to know what name (conventionally an email address) to use as the
> patch author, e.g. 'Fred Bloggs <fred@bloggs.invalid>'.  If you provide one
> now it will be stored in the file '_darcs/prefs/author' and used as a default
> in the future.  To change your preferred author address, simply delete or edit
> this file.
> 
> What is your email address? me
> rmfile ./f.txt
> Shall I record this change? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
> What is the patch name? Remove f.txt in Z
> Do you want to add a long comment? [yn]n
> Finished recording patch 'Remove f.txt in Z'

Z is now like Y, but the removal of the empty f.txt is a separate patch, not a 
pulled one.

> $ darcs pull --repodir=X Z
> Tue Feb 17 13:36:26 CET 2009  me
>   * Remove f.txt in Z
> Shall I pull this patch? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
> Finished pulling and applying.

And here we are:

> $ darcs changes -v --repodir=X
> Tue Feb 17 13:36:26 CET 2009  me
>   * Remove f.txt in Z
>     duplicate
>     |rotcilfnoc [
>     |hunk ./f.txt 1
>     |+f.txt contents
>     |]
>     ||:
>     |rmfile ./f.txt
>     |hunk ./f.txt 1
>     |-f.txt contents
>     |:
>     rmfile ./f.txt
> 
> Tue Feb 17 13:31:09 CET 2009  me
>   * Remove f.txt in Y
>     conflictor [
>     hunk ./f.txt 1
>     +f.txt contents
>     ]
>     |:
>     rmfile ./f.txt
> 
> Tue Feb 17 13:29:32 CET 2009  me
>   * Add f.txt contents in X
>     hunk ./f.txt 1
>     +f.txt contents
> 
> Tue Feb 17 13:29:01 CET 2009  me
>   * Create f.txt in X
>     addfile ./f.txt
> $ 

Further, we can reproduce the conflict:

> $ mkdir A
> $ darcs init --repodir=A
> $ darcs pull --repodir=A X
> Tue Feb 17 13:29:01 CET 2009  me
>   * Create f.txt in X
> Shall I pull this patch? (1/4)  [ynWsfvpxdaqjk], or ? for help: y
> Tue Feb 17 13:29:32 CET 2009  me
>   * Add f.txt contents in X
> Shall I pull this patch? (2/4)  [ynWsfvpxdaqjk], or ? for help: n   <<< Note n 
here
> Tue Feb 17 13:31:09 CET 2009  me
>   * Remove f.txt in Y
> Shall I pull this patch? (3/4)  [ynWsfvpxdaqjk], or ? for help: y
> Tue Feb 17 13:36:26 CET 2009  me
>   * Remove f.txt in Z
> Shall I pull this patch? (4/4)  [ynWsfvpxdaqjk], or ? for help: y
> Finished pulling and applying.

Now A is X with the patch to add contents to f.txt missing.

> $ darcs push --repodir=X A
> Tue Feb 17 13:29:32 CET 2009  me
>   * Add f.txt contents in X
> Shall I push this patch? (1/1)  [ynWsfvpxdaqjk], or ? for help: y
> 
> darcs failed:  Refusing to apply patches leading to conflicts.
> If you would rather apply the patch and mark the conflicts,
> use the --mark-conflicts or --allow-conflicts options to apply
> These can set as defaults by adding
>  apply mark-conflicts
> to _darcs/prefs/defaults in the target repo. 
> There are conflicts in the following files:
> ./f.txt
> Apply failed!
> $ 

And we get the problem.

In spite of all these details, I still don't know what to make of it.

Best regards
Thorkil

> Sounds related to the new darcs 2 semantics (duplicate patches  
> don't conflict).  Can we boil this further down into a minimal test  
> case?

I believe it is related: I and one other person independently rm'ed  
README.txt.  In my branch I had already written a patch which edited  
README.txt before I rm'ed it.  I think that's how it went.

According to the philosophy of test-driven development, we shouldn't  
fix this bug until we first have an automated test of it which we can  
use to make sure that darcs never again regresses in this way.

> Zooko: are you blocking on this?  Or do you need us to think of a  
> workaround?

No.  Thanks for the concern!

Regards,

Zooko

It might be helpful if we got a clear picture how we should expect darcs
to behave here.

Either mark-conflicts should report a conflict and the push should fail
or mark-conflicts should not report a conflict and the push should
succeed, but what we're getting is that mark-conflicts does not report
a conflict, yet the push fails.

So (warning, ASCII art)

        | mark-conflicts | apply
  ------+----------------+-------
  good? | conflict!      | conflict!
  good? | no conflict    | ok
  bad   | no conflict    | conflict!

Hmm... not sure which of the "good" situations is the right one.
I'm guessing it's #2 if it's just duplicate patches that we're dealing
with.

Marking urgent.  We definitely need to understand what's going on here.  It may
not actually be serious, but it could be something scary

Alright, it looks like we need somebody to turn Thorkil's test case into a
formal bug.

Are you up for it, Thorkil?  Thanks! :-)

I've turned Thorkil's test case into a regression test (NB: BSD3
licensed, copyright Thorkil).  It's being crunched through by my staging
repository as I write this, so it should appear on darcs.net shortly.

I don't know for sure, but looking at the history of this bug, I think
we can be fairly confident that Thorkil's case captures the problem,
that mark-conflicts does not seem to treat duplicate patches as conflicts.

Note that we may actually have the *opposite* problem here, that darcs
apply is being too strict.

In any case, we now need somebody to investigate the causes of the bug.

I will will remove the failing test case for this issue since this is
not a bug! (BTW, whether we move to hub.darcs.net or not, our bug
tracker should definitely allow to close an issue as 'invalid' or
'not-a-bug'.)

Whether applying a patch results in a conflict or not does depend on the
context in which we apply the patch. This is a trivial observation. The
strange thing here is the context: if a duplicate of the patch to be
applied is already present (and results in a conflict), then adding it
one more time results in a duplicate patch that /resolves the conflict/.

Indeed, after pulling 'Remove f.txt in S' , darcs mark-conflicts indeed
says:

Conflicts found in the following files:
./f.txt

and applies the conflict resolution which consists of

> darcs whatsnew
rmfile ./f.txt

The duplicate from T does exactly this, so it counts as conflict
resolution and the conflict is no longer shown when it is applied.

Note: all this has /nothing/ to do with push/apply versus
mark-conflicts, both behave consistently the same when the context in
which the patch is applied is the same.

The test case sets up two repositories with different contexts, so I 
agree with bf's analysis that the test case is invalid.

However the original report still seems valid: there's a repository 
with 7 patches. If you create a new repository with just 6 of those 
patches (and nothing) else and then pull in the 7th troublesome one, 
you get a conflict on the pull but there isn't a conflict in the 
original repository.

It's actually to do with the ordering of the patches. You can 
reproduce it in the original repository by reordering it so that the 
troublesome one is at the end, and then mark-conflicts reports a 
conflict. So original ordering = no conflict, new ordering = 
conflict.

That said, duplicates are involved and they're weird, so I'm not 
sure this is worth investigating anyway.

Ah, thanks Ganesh, i never looked at the original problem. I may do that
and perhaps I can create a better test case. I agree that there is
probably not much we can do about it, but I would still like to
understand it a bit better than I do now before I am ready to file it 
under "mysterious duplicate bug, forget it".