Date: Mon, 9 Apr 2001 16:46:07 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/contrib/gcc.295 stupid.c Message-ID: <20010409164607.A36359@sunbay.com> In-Reply-To: <Pine.BSF.4.21.0104092322050.80281-100000@besplex.bde.org>; from bde@zeta.org.au on Mon, Apr 09, 2001 at 11:27:49PM %2B1000 References: <20010409132008.A16393@sunbay.com> <Pine.BSF.4.21.0104092322050.80281-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 09, 2001 at 11:27:49PM +1000, Bruce Evans wrote: > On Mon, 9 Apr 2001, Ruslan Ermilov wrote: > > > On Mon, Apr 09, 2001 at 02:48:51AM -0700, David E. O'Brien wrote: > > > obrien 2001/04/09 02:48:51 PDT > > > > > > Modified files: > > > contrib/gcc.295 stupid.c > > > Log: > > > Well, CVS was being stupid with what it gave me as rev 1.1. Or maybe I > > > was being stupid for thinking stupid CVS would DTRT. Anyway, this stupid > > > file is now back to the correct stupid version. And my stupidness in > > > breaking the build is dealt with. > > > > > > Revision Changes Path > > > 1.4 +271 -59 src/contrib/gcc.295/stupid.c > > > > > Of course, you should have checked out the -rFSF revision. :-) > > 1.1 was only a branch point for the default branch. > > I believe -r1.1.1 always gives the vendor version. It's easier to remember > than the vendor name. > Not always -- share/zoneinfo is one of the exceptions: : wollman 95/08/04 08:53:29 : : Branch: share/zoneinfo 1.1.2 : Log: : Latest timezone data from Arthur David Olson : : Obtained from: Arthur David Olson <ado@elsie.nci.nih.gov> : : Status: : : Vendor Tag: ADO : Release Tags: tzdata95e > > BTW, I have found that deleting a file (that is on vendor branch) > > from the vendor branch works better. First, it does not reset the > > default branch on that file, and this automatically deletes a file > > from the HEAD branch. Second, it makes `cvs co -rVENDOR' checkout > > the consistent set of files. > > > > : RCS file: /home/ru/Work/.cvs/foo/file.c,v > > : Working file: file.c > > : head: 1.1 > > : branch: 1.1.1 > > : locks: strict > > : access list: > > : symbolic names: > > : v_1_0: 1.1.1.1 > > : VENDOR: 1.1.1 > > : keyword substitution: kv > > : total revisions: 3; selected revisions: 3 > > : description: > > : ---------------------------- > > : revision 1.1 > > : date: 2001/04/09 10:12:04; author: ru; state: Exp; > > : branches: 1.1.1; > > : Initial revision > > : ---------------------------- > > : revision 1.1.1.2 > > : date: 2001/04/09 10:13:07; author: ru; state: dead; lines: +0 -0 > > : Remove from default vendor branch. > > : ---------------------------- > > : revision 1.1.1.1 > > : date: 2001/04/09 10:12:04; author: ru; state: Exp; lines: +0 -0 > > : Import. > > : ============================================================================= > > > > I have asked this question before, but no one answered... > > Do we have a policy rule for this? > > How did you do this? Whatever David used to remove stupid.c (just > "cvs remove"?) took stupid.c off the vendor branch. It's still not > actually back to the "correct stupid version", since it is still > off the vendor branch and has a $FreeBSD$. > cvs up -rVENDOR file.c cvs rm -f file.c cvs com -m "Remove from default vendor branch." file.c Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010409164607.A36359>