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