[There are 3 messages here. First a bug report from Wilfredo Sanchez. Secondly a bug report and thirdly an update from Jim Meyering. I haven't looked carefully enough to be sure that the two people are discussing the same problem, but it looks that way to me Fix was checked in 4 Dec 1997 -kingdon] To: bug-cvs@prep.ai.mit.edu Subject: Branch problem? Date: Wed, 3 Dec 97 18:17:44 US/Pacific From: Wilfredo Sanchez I'm having an RCS/CVS problem that I don't fully understand... CVS version is 1.9.20. I have this file, PCPointer.m, checked out. There's a main branch, a "Titan" branch, off of main, and a bunch of "PR-XXX" (bug fix) branches off of Titan. The RCS log is attached at the bottom. So I checked out the Titan branch (cvs co -r Titan ...) and I made some changes (actually, merged in changes from PR-2004800) and I try to commit. But CVS craps out: wsanchez% cvs commit -m "Merged in PR-2004800 (umeshv: _KERNEL_BUILD)" PCPointer.m Checking in PCPointer.m; /Net/seaport/projects/mk/osdev/CVSRoot/CoreOS/System/kernel/bsd/dev/i386/PCPointer.m,v <-- PCPointer.m rcs: /Net/seaport/projects/mk/osdev/CVSRoot/CoreOS/System/kernel/bsd/dev/i386/PCPointer.m,v: revision 1.1.1.1.8 too low; must be higher than 1.1.1.1.30 /Net/nextstar/Users/wsanchez/Developer/local/cvs/cvs/src/rcs.c:3664: failed assertion `delta->version != NULL' Abort >From looking at the log, Umesh checked out branch PR-2004800 (1.1.1.1.0.30), modified this file, and committed it. It got revision 1.1.1.1.30.1. So I check out branch Titan (1.1.1.1.0.8), change this file (merged in his changes) and commit, and CVS tries to create 1.1.1.1.8. Things go haywire. What's supposed to happen here? Thanks, -Fred --- [sancwi:bsd/dev/i386] wsanchez% cvs log PCPointer.m RCS file: /Net/seaport/projects/mk/osdev/CVSRoot/CoreOS/System/kernel/bsd/dev/i386/PCPointer.m,v Working file: PCPointer.m head: 1.2 branch: locks: strict access list: symbolic names: debo_kernel_bx_007: 1.1.1.1 Fixed-220379: 1.1.1.1.30.1 PR-2004660-base: 1.1.1.1 PR-2004660: 1.1.1.1.0.36 PR2200415-base: 1.1.1.1 PR2200415: 1.1.1.1.0.34 PR-1685952-base: 1.1.1.1 PR-1685952: 1.1.1.1.0.32 Fixed-2004800: 1.1.1.1 PR-2004800-base: 1.1.1.1 PR-2004800: 1.1.1.1.0.30 russb-PR-2006267A: 1.1.1.1 PR-2006267-base: 1.1.1.1 PR-2006267: 1.1.1.1.0.28 pr-1661667-base: 1.1.1.1 PR-2005395-base: 1.1.1.1 pr-1661667: 1.1.1.1.0.26 PR-2005395: 1.1.1.1.0.24 kernel-82: 1.1.1.1 PR-1670616-base: 1.1.1.1 PR-1670616: 1.1.1.1.0.22 PR-2005190: 1.1.1.1.0.20 PR-2005190-base: 1.1.1.1 PR-1684738-base: 1.1.1.1 PR-1684738: 1.1.1.1.0.18 PR-2003673-base: 1.1.1.1 PR-2003673: 1.1.1.1.0.16 pexpertworkgroup-base: 1.1.1.1 debo_kernel_br_007: 1.1.1.1.0.14 debo_kernel_br_006: 1.1.1.1.0.12 pexpertworkgroup: 1.1.1.1.0.10 Titan-base: 1.1.1.1 Titan: 1.1.1.1.0.8 kernel-81: 1.1.1.1 umeshv-kernel-79: 1.1.1.1 gvdl-kernel-77-1: 1.1.1.1 gvdl-kernel-77: 1.1.1.1.0.6 kernel-78: 1.1.1.1 debo-kernel-102497: 1.1.1.1.0.4 kernel-77: 1.1.1.1 kernel-76-1: 1.1.1.1 kernel-76: 1.1.1.1 umeshv-kernel-75-1: 1.1.1.1.0.2 kernel-75: 1.1.1.1 start: 1.1.1.1 Apple/CoreOS: 1.1.1 keyword substitution: kv total revisions: 4; selected revisions: 4 description: ---------------------------- revision 1.2 date: 1997/12/02 22:53:24; author: umeshv; state: Exp; lines: +1 -1 Cleanup. Fixed incorrect use of _KERNEL_BUILD Radar Bug ID: 2200379 ---------------------------- revision 1.1 date: 1997/09/30 02:42:51; author: wsanchez; state: Exp; branches: 1.1.1; Initial revision ---------------------------- revision 1.1.1.1 date: 1997/09/30 02:42:51; author: wsanchez; state: Exp; lines: +0 -0 branches: 1.1.1.1.30; Import of kernel from umeshv/kernel ---------------------------- revision 1.1.1.1.30.1 date: 1997/12/03 05:23:24; author: umeshv; state: Exp; lines: +1 -1 Fixed the incorrect use of _KERNEL_BUILD. Other cleanup. Radar Bug ID: 2200379 ============================================================================= To: bug-cvs@prep.ai.mit.edu Cc: info-cvs@prep.ai.mit.edu Subject: cvs-1.9.20: commit on non-latest branch that is magic fails; with patch From: Jim Meyering Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: multipart/mixed; boundary="Multipart_Sat_Nov_22_11:48:47_1997-1" Content-Transfer-Encoding: 7bit Date: 22 Nov 1997 11:48:47 -0800 --Multipart_Sat_Nov_22_11:48:47_1997-1 Content-Type: text/plain; charset=US-ASCII >Submitter-Id: net >Originator: Jim Meyering >Organization: net >Confidential: no >Synopsis: commit on non-latest branch that is magic fails >Severity: critical >Priority: high >Category: cvs >Class: sw-bug >Release: cvs-1.9.20 >Environment: System: SunOS meyering-net-28 5.5.1 Generic_103641-06 i86pc i386 i86pc Architecture: i86pc >Description: very imprecisely: the first commit on an old branch gets this assertion failure: rcs: /tmp/cvs-builtin-rcs-26663/repo/cvs-brcs-bug/file.c,v: revision 1.2.2 too low; must be higher than 1.2.4 rcs.c:3664: failed assertion `delta->version != NULL' Abort [Exit 134 (SIGABRT)] >How-To-Repeat: See the script below. Running it produced the above failure. >Fix: * rcs.c (RCS_addbranch): #ifdef-out test to compare revision numbers. I'm not at all sure this is right, but the result doesn't fail any tests in sanity. Then again, there don't seem to be any tests for this particular failure message from rcs.c. --Multipart_Sat_Nov_22_11:48:47_1997-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="rcs.c-patch" Content-Transfer-Encoding: 7bit Index: rcs.c =================================================================== RCS file: /p/x/cvs/src/rcs.c,v retrieving revision 1.3 diff -u -p -r1.3 rcs.c --- rcs.c 1997/11/20 02:56:56 1.3 +++ rcs.c 1997/11/22 19:11:16 @@ -3348,12 +3348,14 @@ RCS_addbranch (rcs, branch) newrevnum = increment_revnum (max); else { +#ifdef DISABLE if (max != NULL && compare_revnums (branch, max) <= 0) { rcserror (rcs->path, "revision %s too low; must be higher than %s", branch, max); return NULL; } +#endif newrevnum = xstrdup (branch); } --Multipart_Sat_Nov_22_11:48:47_1997-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="cvs-bug-builtin-rcs" Content-Transfer-Encoding: 7bit #!/bin/sh : ${CVS=cvs} TMPDIR=/tmp dir=$TMPDIR/cvs-builtin-rcs-$$ module=cvs-brcs-bug repo=$dir/repo file=file.c branch=BR rm -rf $repo mkdir -p $repo cvs -d $repo init cd $dir mkdir .x cd .x echo initial > $file $CVS -d $repo import -m . $module X X-1 cd $dir rm -rf $module $CVS -d $repo co $module cd $module echo trunk-1 > $file $CVS commit -m . $file $CVS tag -b $branch $file $CVS tag -b $branch-2 $file echo trunk-2 > $file $CVS commit -m . $file $CVS update -r $branch-2 $file echo b2-1 > $file $CVS commit -m . $file $CVS update -r $branch $file echo b2 > $file $CVS commit -m . $file --Multipart_Sat_Nov_22_11:48:47_1997-1-- To: CVS developers Subject: cvs-1.9.20 assertion failure: fixed, commit coming From: Jim Meyering Date: 30 Nov 1997 21:43:46 -0800 Just so you know, I have fixed the bug whereby out of order commits of two separate branches from the same point would cause a failed assertion in rcs.c. I've checked in some of the required framework (in hash.c). I'll commit the fix in the next few days, once I've made my test fit the sanity.sh mold.