[darcs-users] darcs2 and hidden cionflicts

[Ben Franksen]

Eric Kow wrote:
>> Could you create a minimal test case that demonstrates this?  I don't
>> see anything on the bugtracker, so that may be useful as well.
> 
> Actually, I've just sent a patch with a small demonstration.  Is this
> the same issue you're facing?  If not, could you add to that test.

First, many thanks Eric, for looking into this.

Your test indeed demonstrates the problem quite well. I only needed to
add --ignore-times to the 'darcs record' calls, otherwise the patches
sometimes didn't get recorded at all, resulting in things like:

ben at sarun[1]: .../darcs.net/bugs > ./hidden-conflict.sh

[...snip...]
cd temp2
echo third > a
darcs record -am 'first to third'
No changes!
cd ..
[...snip...]


Anyway, with the --ignore-times added, I indeed get my dreaded hidden
conflicts:

ben at sarun[1]: .../darcs.net/bugs > ./hidden-conflict.sh
[...snip...]
cd temp2
echo third > a
darcs record --ignore-times -am 'first to third'
Finished recording patch 'first to third'
cd ..

cd temp1
darcs pull -a ../temp2 | grep conflict


The resulting hidden merger patch looks thus:

ben at sarun[1]: .../darcs.net/bugs > darcs changes -v --repodir=temp1 --last=1
diffing dir...
Fri Jun  6 21:54:48 CEST 2008  ben.franksen at online.de
  * first to third
    merger 0.0 (
    hunk ./a 1
    -second
    +first
    merger 0.0 (
    hunk ./a 1
    -first
    +second
    hunk ./a 1
    -first
    +third
    )
    )

> It appears that the darcs2 format deals with this case correctly

Yes, I can reproduce this:

darcs changes -v --repodir=temp1 --last=1
diffing dir...
Fri Jun  6 22:24:28 CEST 2008  ben.franksen at online.de
  * first to third
    conflictor [
    hunk ./a 1
    -first
    +second
    hunk ./a 1
    -second
    +first
    ]
    |:
    hunk ./a 1
    -first
    +third

> (although I was surprised that a conflict got generated there... my
> reading of the wiki led me to think that we would just have the
> intervening change with no conflicts)

If you mean the result should be that file 'a' contains 'third' (and nothing
else), then yes this seems to be the desired behaviour, at least in this
simple case. I don't know how it would look like in more complicated
scenarios.

Anyway: reporting a conflict here is definitely a huge improvement over
silently loosing (parts of) the content of a pulled patch! I am extremely
glad to see that this has been fixed with the darcs-2 format.

All I need now is a way to migrate our multi-branch projects to darcs-2
format... :-) More on that in another thread.

Cheers
Ben