Hello Kaz, Thursday, February 26, 2004, 7:43:25 PM, you wrote:
>> But in more common case, when the trunk was changed too, we can >> overwrite changes in trunk by changes in the branch! Where single -j >> update produces conflict, double -j produces overwrite. Look: KK> That is not by design. If you actually have a test case that reproduces KK> an instance of overwrite, you should discuss that. Well, I really was wrong. I should test it before flame :) Sergei Organov explained me in private where I missed the thing. If somebody confused too, here is the explaination: Pretend we have some file, having line #23 in the sandbox: working_copy at revision 1.2.2.2: version_0 at revision 1.2.2.3: version_1 Than cvs update -j1.2.2.2 -j1.2.2.3 makes diff, which says that "version_0" in line #23 should be changed to "version_1". But sandbox at this place has "working_copy" which is certainly not "version_0". It doesn't matter when and why, but conflict have happend and is detected. KK> Your approach can produce bad merges in a different way. If you use the KK> tip of the branch as the second argument to -j, you have potential race KK> conditions between the merge and other people doing commits on the KK> branch: Indeed. Thanks again. -- Best regards, Iakov _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
