[cvsnt] Re: Lost keyword expansion setting after multiple merges with added files

[Tony Hoyle]

Oliver Koltermann wrote:
> Hello Glen,
> 
> Glen Starrett <glen.starrett at march-hare.com> writes:
> 
>> I can't repro the behavior with the steps provided.  Can you provide a
>> script to repro the problem?
> 
> I'm not a batch-file expert, but the following "test.bat" - called in
> an existing sandbox directory - reproduced the problem for me:
> 
> -----test.bat START-----
> @echo off
> md mergesticky
> cvs add mergesticky
> cvs update -A mergesticky
> cd mergesticky
> echo binary >BinaryMerge.txt
> cvs add -kb BinaryMerge.txt
> cvs commit -m "Baseline version" BinaryMerge.txt
> cd ..
> cvs update -rsomebranch -jHEAD mergesticky
> cvs status mergesticky/BinaryMerge.txt
> cvs update -rsomebranch -jHEAD mergesticky
> cvs status mergesticky/BinaryMerge.txt
> -----test.bat END-----
> 
> Please note the Sticky Options in the two "cvs status" outputs.
> 
It might seem odd, but cvsnt is actually behaving sensibly in what is a very 
unusual circumstance.

The branch somebranch does not contain the file BinaryMerge.txt, so what 
you're actually saying is:

1. Update to somebranch - delete the existing file
2. Merge with HEAD - add a new file

The second time you're saying something different:

1. Update to somebranch - do nothing (we already have an added file)
2. Merge with HEAD - do a 3 way merge between the repository version of 
somebranch (nonexistant, basically taken as an empty text file), HEAD, and the 
added file in the sandbox.

Since the expansion of a nonexistant revision is different to the expansion of 
HEAD it has to pick one to force the resultant file into, and it picks the 
first (there is no correct answer to this - the delta between two revisions 
with different expansions is not defined).

I've modified it to recognise this and default back to the existing expansion 
- which of course causes a conflict (merge of nonmergable file) which needs to 
be sorted out manually.

I very much doubt anyone would normally see it- the command sequence is 
sufficiently unusual (mixing -j and -r and also repeating it) that it requires 
special handling even to make any sense of it.

Tony