Date: Fri, 4 Jul 1997 11:57:53 PDT From: Bill Fenner <fenner@parc.xerox.com> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: gnu/4033: cvs clears default branch when adding a file to a new branch with "cvs add" Message-ID: <199707041857.LAA08337@fenestro.parc.xerox.com> Resent-Message-ID: <199707041900.MAA04367@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 4033 >Category: gnu >Synopsis: cvs clears default branch when adding a file to a new branch with "cvs add" >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jul 4 12:00:00 PDT 1997 >Last-Modified: >Originator: Bill Fenner >Organization: Xerox >Release: FreeBSD 3.0-CURRENT i386 >Environment: Concurrent Versions System (CVS) 1.9.9 (client/server) Copyright (c) 1993-1994 Brian Berliner Copyright (c) 1993-1994 david d `zoo' zuhn Copyright (c) 1992, Brian Berliner and Jeff Polk Copyright (c) 1989-1992, Brian Berliner CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. >Description: When using "cvs add" in a directory with a sticky tag (e.g. to bring a file onto a branch), "cvs commit" clears out the default branch in the RCS file before choosing the revision number for the new branch, and does not put it back. This causes: a) confusion. Normally a file with a vendor branch cannot have a 1.1.2.x branch. b) bloat. Since HEAD is no longer on the vendor branch, any commits onto the vendor branch have to be merged onto HEAD, even if there have been no local changes. c) inconsistency. Files that were on the vendor branch when the tree was tagged (e.g. when "cvs tag -b RELENG_2_2 happened) will have RELENG_2_2 branches of 1.1.1.1.2, while files that were imported later and then "cvs add"ed will have RELENG_2_2 branches of 1.1.2 . d) In my test case, it caused an extraneous conflict on $Id$ lines when importing a new version onto the vendor branch, but that might just have been a poorly-formed test case. >How-To-Repeat: - "cvs import ttt" into an empty repository - "cvs co ttt" the new module - "cvs tag -b TESTOTRON *.c" some of the files in the module - "cvs release -d ttt" the directory I was working in Right now, the file "tcpdump.1,v" has branch:1.1.1 - "cvs co -rTESTOTRON ttt" - cp (where-I-imported-from)/tcpdump.1 . - "cvs add tcpdump.1" - "cvs commit" The TESTOTRON branch is 1.1.2 in tcpdump.1, where it's 1.1.1.1.2 in *.c . tcpdump.1 has also lost its "branch:" info, so HEAD is now 1.1 instead of 1.1.1.1 . >Fix: This fix needs a more thorough review than I was able to give it, but it at least fixes my test case. cvs diff: Diffing . Index: commit.c =================================================================== RCS file: /home/ncvs/src/contrib/cvs/src/commit.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 commit.c --- commit.c 1997/05/15 22:45:24 1.1.1.2 +++ commit.c 1997/07/01 04:40:27 @@ -1948,6 +1948,8 @@ char *head; char *magicrev; + fixbranch(rcsfile, sbranch); + head = RCS_getversion (rcsfile, NULL, NULL, 0, (int *) NULL); magicrev = RCS_magicrev (rcsfile, head); >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707041857.LAA08337>