Re: join not producing conflict

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

Paul Edwards <kerravon@nosppaam.w3.to> writes:

> On cvs 1.11.9, on Windows or Unix, this doesn't produce
> expected results nor does it failsafe.  Is this a known bug
> or operator error etc?
> 
> Thanks.  Paul.
> 
> 
> rm -fr $CVSROOT/test
> mkdir $CVSROOT/test
> cvs get test
> cd test
> echo aaa >temp.txt
> echo bbb >>temp.txt
> echo ccc >>temp.txt
> cvs add temp.txt
> cvs commit -m "." temp.txt
> cp temp.txt temp2.txt
> echo ddd >>temp.txt
> cvs commit -m "." temp.txt
> cp temp2.txt temp.txt
> cvs diff temp.txt
> 
> # Why does this come up with "M temp.txt" instead of
> # inserting the change, probably with conflict markers
> # because two people have effectively made independent
> # and conflicting changes, ie one has deleted a line, the
> # other has added a line?
> # Instead, there is no markers, and this change essentially
> # gets lost.
> # Other files that have local modifications don't have the
> # update -j -j ignored.  So I'm not even aware that one file
> # has been skipped.
> cvs update -j 1.1 -j 1.2 temp.txt
> cvs diff temp.txt

Well, it is doing a join_file(temp.txt, 1.2, 1.1, 1.2) on the server and
then shipping the diff (none exists as version 1.2 already has the delta
of 1.1 to 1.2 incorporated in it) across to the client to incorporate
into the already modified file. I think that if the top-of-tree version
were different (say version 1.3), then you might see the kind of
conflict markers you believe should be present.

I could be wrong, but I suspect that this is not really a bug even though
the output might appear surprising. Would you expect

   cvs update -C temp.txt
   touch temp.txt
   cvs update -j 1.1 -j 1.2 temp.txt

to introduce another "ddd" line with or without conflict markers? What
about 

   cvs update -C temp.txt
   (echo "new" ; cat temp.txt) > new.txt
   mv new.txt temp.txt
   cvs update -j 1.1 -j 1.2 temp.txt

should that do something with the "ddd" line?

In my opinion, there is no problem here, or at least I see no way to
change the semantics of cvs to accomodate your request without making
it break other things even more.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/k7Uy3x41pRYZE/gRAn8PAKCUGJpYJcrq1M5yNJLLIvbSEp3AZgCg4RM/
PS7X7VS2iIHm4aRKYJcp39Y=
=lknZ
-----END PGP SIGNATURE-----