Re: conflict on added files

[Pierre Asselin]

Derek Robert Price <derek@ximbiot.com> wrote:
> Paul Edwards wrote:

>>+         # Test Conflict
>>+         mkdir ${CVSROOT_DIRNAME}/aaa
>>+         ${testcvs} checkout aaa >/dev/null 2>&1
>>+         cd aaa
>>+         echo aaa >one.c
>>+         ${testcvs} add one.c >/dev/null 2>&1
>>+         ${testcvs} commit -m "." one.c >/dev/null 2>&1
>>+         rm one.c
>>+         ${testcvs} remove one.c >/dev/null 2>&1
>>+         ${testcvs} commit -m "." one.c >/dev/null 2>&1
>>+         ${testcvs} update -j 1.2 -j 1.1 one.c >/dev/null 2>&1
>>+         ${testcvs} commit -m "." one.c >/dev/null 2>&1
>>+         ${testcvs} tag -r 1.2 tag1 one.c >/dev/null 2>&1
>>+         ${testcvs} tag -r 1.3 tag2 one.c >/dev/null 2>&1
>>+         echo bbb >>one.c
>>+         ${testcvs} commit -m "." one.c >/dev/null 2>&1
>>+         ${testcvs} update -j tag1 -j tag2 one.c >/dev/null 2>&1
>>+
>>+         dotest_fail conflict-1 "${testcvs} commit -m test one.c" \
>>+ "${PROG} [a-z]*: Up-to-date check failed for .one.c'
>>+ ${PROG} \[[a-z]* aborted\]: correct above errors first!"
>>+         cd ..
>>+         rm -fr aaa
>>+         rm -fr ${CVSROOT_DIRNAME}/aaa
>>+         ;;
>>  
>>

> I haven't studied this enough to be certain what you were aiming for, 
> but CVS certainly shouldn't be reporting that one.c is not up-to-date. 
>  The update previous to your conflict-1 test should have reported a 
> conflict, but everything is up-to-date.

When I type in the steps in Paul's script, the "update -j" gives

    $ cvs update -jtag1 -jtag2 one.c
    cvs update: file one.c exists, but has been added in revision tag2

So the update failed.  However,

    $ cvs status one.c
    ===================================================================
    File: one.c             Status: Up-to-date

    Working revision:    1.4     Wed Jun 11 00:33:25 2003
    . . .

I'd say Paul has a point.  I'm not sure the patch is enough.  The
status would change to 'conflict', but the file would contain no
conflict markers, right?  How is one to remember what the conflict was
about?

Paul's patch is probably useful to him, because his processes create
more add conflicts than usual, but it's not a general solution.

Five things can happen in the sandbox, and the same five can happen
between the two -j revisions:

    file never present
    file added
    file unchanged
    file modified
    file deleted

The update command should really handle all 25 combinations and leave
the sandbox in a state where any conflict can be identified.  This would
require changes to more than just update.  In a couple of the 25 cases,
I'm not even sure what correct action should be!