Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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