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

[Tony Hoyle]

Oliver Koltermann wrote:
> Isn't the expansion option of a nonexistent file undefined? When I
> take into account a binary file from HEAD, a binary added file and an
> undefined nonexisting file, it sounds quite logical to me, that the
> result would be binary. Your argument surely is right if i mix in a
> file with explicit text expansion (e.g. from another branch), but this
> was not the example and would count as a wrong useage conflicting with
> the "update -j/commit" concept. It would be like using the repository
> of an interrupted merge for a completely new task.

Anything 'undefined' is taken as default - no expansion == -kkv all through 
the code.  A nonexistant revision is (logically speaking) as empty, deleted, 
text file with default expansion - cvs will normally behave as if this is so.

The fact that it's deleted generally means that the expansion doesn't matter - 
the effect of a checkout of it is to delete the sandbox file (so that up -r 
tag only brings the files which contain the tag).

The -j then puts you in an odd situation - -j applies the delta between two 
revisions to the sandbox (with shortcuts if the sandbox is unmodified, which 
isn't the case here).  The fact that the first revision is deleted then 
doesn't matter

> Sounds logical if the files differ, but here we have two identical
> binary files and one nonexisting file. I add either the first binary
> file or the second (conflict), but if they are identical, it doesn't
> matter. But I know that this is naive speaking - I don't know how it's
> handled internally.

An added file has no revision, and is always modified, and you're trying to 
apply a delta to it - there's no choice in that case but to conflict since a 
nonmergable file can't be processed in such a way as to determine the result 
is identical.

> 1) Throw away his first merge attempt and merge again from the fixed
>    baseline. All conflict solving has to be done a second time.
> 
> 2) Get the small fix into his half-merged sandbox and go on.
> 
3) Merge only the file(s) associated with the fix.  I imagine this is one or 
two files..

4) Prior to merging, lock commits to the tree with an ACL (not a good solution 
generally IMO but in the case of a major merge between two major branches 
could be necessary).

Tony