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

Oliver Koltermann okoltermann_deletethis_ at gmx.de
Mon May 8 14:24:10 BST 2006


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.


Hello Tony,

thanks for the insights.

Tony Hoyle <tony.hoyle at march-hare.com> writes:
> Oliver Koltermann wrote:
> > -----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-----
>
> 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.

I got your point. But I don't quite understand in what form the
expansion option of a nonexistent file matters. And the binary files
are identical bit-by-bit.

> 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).

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.

> 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.

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.

> 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.

I agree that this should not be used as a feature. As I described in
my initial posting I rate it as wrong useage conflicting with the
merge-and-commit rule. But it's a mistake someone can easily make.

The mixing of -r and -j was mainly to keep the example small. The
second call to update doesn't need the -r (copy&paste...) and even the
first could be invoked in a different working copy checked out on
"somebranch" without the -r.

The scenario was mainly something like:

Developer 1: Merges his development branch with the baseline, which
             eventually involves some time-consuming conflict solving

Developer 2: Commits the small fix to the recently broken baseline

Developer 1: Merges again to get the fix, because he can't test his
             merge-result without it

Developer 1 would have had two options:

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.

But of course all this mess could have been prevented through better
communication and organization...


Best regards,
O. Koltermann



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook