From info-cvs-request@prep.ai.mit.edu Mon Apr 17 10:10:48 1995 Date: Mon, 17 Apr 95 10:10:48 CDT From: stevet@oakhill-csic.sps.mot.com (Steve Turner-CAD_Tools) Message-Id: <9504171510.AA11845@apache.sps.mot.com> To: info-cvs@prep.ai.mit.edu, EUWB92A@prodigy.com Subject: Re: binary files and CVS Content-Length: 1509 Status: RO > -- [ From: Stuart Whitman * EMC.Ver #2.10P ] -- > > I am a new user of CVS and find it a great improvement over RCS. When I > found out it could version control binaries (executables and .a files) > I thought that this was a good thing and gave it a try. I got the gnu > diff utilities, recompilied RCS and installed CVS. Now, I'm a bit > confused over what CVS is able to do with binaries. When a binary gets > out of date CVS outputs a message about merging the file, but the file > seems to be corrupt after the merge. Is CVS capable of merging > executables, or am I doing something wrong? I read the FAQ several > weeks ago, so I apologize if I have missed this question in the FAQ or > it has been posted there since I last read it. THANKS IN ADVANCE. > > Stu > Yes, this subject has come up many times, although I don't think the FAQ addresses it directly. In a nutshell: 1. You are correct: CVS (or any SCM tool, for that matter) is not capable of merging binary files. Furthermore, 2. CVS does not allow file locking. Therefore: 3. CVS can't really support binary files. My suggestion is: Don't check binary files (or any file that you can't merge) into CVS. Hope this helps. --Steve ----------------------------------------------------------- Steve Turner KC5LCS Motorola stevet@oakhill-csic.sps.mot.com CSIC MCU Design Automation 512.891.8728 Austin, TX ----------------------------------------------------------- From info-cvs-request@prep.ai.mit.edu Tue Apr 18 15:27:44 1995 Date: Tue, 18 Apr 1995 15:03:15 -0400 From: nilesh@hagar.aspentec.com (Nilesh PatelL/ATHQ) Message-Id: <9504181903.AA20719@hubble.aspentec.com> To: info-cvs@prep.ai.mit.edu Subject: CVS-1.4A2 better for OSF/1?? Why? X-Sun-Charset: US-ASCII Content-Length: 230 Status: RO We are planning to install cvs on an OSF/1 machine. The mini-FAQ for cvs says that, cvs-1.4A2 is better for OSF, although it is not officially released. What are the changes that make cvs-1.4 better for OSF/1 Nilesh From info-cvs-request@prep.ai.mit.edu Tue Apr 18 14:52:04 1995 Message-Id: <9504181841.AA20668@nova.tat.physik.uni-tuebingen.de> From: koenig@tat.physik.uni-tuebingen.de (Harald Koenig) Subject: bug in CVS-1.3 To: dgg@ksr.com, info-cvs@prep.ai.mit.edu Date: Tue, 18 Apr 1995 14:33:51 +0200 (MET DST) Cc: dawes@physics.su.oz.au (David Dawes), koenig@tat.physik.uni-tuebingen.de (Harald Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1458 Status: RO Hi, there is a bug in CVS-1.3 when using ".cvsignore" files in (local) subdirectories. using the following directory structure prog/dir1 prog/dir2/.cvsignore prog/dir3 prog/dir4 where "dir2/.cvsignore" has only one line "*" (so that this directory and all it's subdirectroires are completely ignored), "dir3" and "dir4" are ignored too because the "hold" ignore list isn't reset after ascending from dir2. below is a short hack to reset the ignore list before ascending from subdirectories. Harald *** cvs-1.3/src/import.c.ORIG Tue Mar 31 23:56:11 1992 --- cvs-1.3/src/import.c Tue Apr 18 13:37:31 1995 *************** *** 291,296 **** --- 291,301 ---- } (void) closedir (dirp); } + + /* restore any per-directory ignore lists */ + ign_add_file ("/dev/null", 1); + + if (has_dirs) { if ((dirp = opendir (".")) == NULL) -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ From info-cvs-request@prep.ai.mit.edu Wed Apr 19 18:08:31 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA29753 for ; Wed, 19 Apr 1995 18:08:30 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09932; Wed, 19 Apr 95 15:07:18 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA09936; Wed, 19 Apr 1995 17:10:47 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06336; Wed, 19 Apr 1995 15:50:13 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06330; Wed, 19 Apr 1995 15:50:11 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA07355; Wed, 19 Apr 1995 16:53:42 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA06100; Wed, 19 Apr 95 14:50:04 PDT Received: from hagar.aspentec.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA24605; Wed, 19 Apr 95 17:50:00 EDT Received: from hubble.aspentec.com by hagar.aspentec.com (AIX 3.2/UCB 5.64/4.03) id AA18513; Wed, 19 Apr 1995 17:49:54 -0400 Received: by hubble.aspentec.com (5.x/SMI-SVR4) id AA24399; Wed, 19 Apr 1995 17:49:54 -0400 Date: Wed, 19 Apr 1995 17:49:54 -0400 From: nilesh@hagar.aspentec.com (Nilesh PatelL/ATHQ) Message-Id: <9504192149.AA24399@hubble.aspentec.com> To: info-cvs@prep.ai.mit.edu Subject: CVS: commit: waiting for lock: solved X-Sun-Charset: US-ASCII Content-Length: 392 Status: RO Earlier today, I posted a problem about the cvs commit. The situation was, whenever I tried to commite the module, using the cvs commit, it would keep saying "waiting for user's lock in /cvsroot/modulename" What had happened that, during a checkout, the machine had crashed. That letf a file in /cvsroot/modulename/#cvs.rfl.736. When I removed this file, Things were Ok. Nilesh From info-cvs-request@prep.ai.mit.edu Wed Apr 19 18:08:31 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA29753 for ; Wed, 19 Apr 1995 18:08:30 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09932; Wed, 19 Apr 95 15:07:18 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA09936; Wed, 19 Apr 1995 17:10:47 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06336; Wed, 19 Apr 1995 15:50:13 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06330; Wed, 19 Apr 1995 15:50:11 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA07355; Wed, 19 Apr 1995 16:53:42 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA06100; Wed, 19 Apr 95 14:50:04 PDT Received: from hagar.aspentec.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA24605; Wed, 19 Apr 95 17:50:00 EDT Received: from hubble.aspentec.com by hagar.aspentec.com (AIX 3.2/UCB 5.64/4.03) id AA18513; Wed, 19 Apr 1995 17:49:54 -0400 Received: by hubble.aspentec.com (5.x/SMI-SVR4) id AA24399; Wed, 19 Apr 1995 17:49:54 -0400 Date: Wed, 19 Apr 1995 17:49:54 -0400 From: nilesh@hagar.aspentec.com (Nilesh PatelL/ATHQ) Message-Id: <9504192149.AA24399@hubble.aspentec.com> To: info-cvs@prep.ai.mit.edu Subject: CVS: commit: waiting for lock: solved X-Sun-Charset: US-ASCII Content-Length: 392 Status: RO Earlier today, I posted a problem about the cvs commit. The situation was, whenever I tried to commite the module, using the cvs commit, it would keep saying "waiting for user's lock in /cvsroot/modulename" What had happened that, during a checkout, the machine had crashed. That letf a file in /cvsroot/modulename/#cvs.rfl.736. When I removed this file, Things were Ok. Nilesh From lechner Wed Apr 19 01:04:38 1995 Received: (from lechner@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id BAA24144; Wed, 19 Apr 1995 01:01:51 -0400 From: Bob Lechner Message-Id: <199504190501.BAA24144@jupiter.cs.uml.edu> Subject: bug in CVS-1.3 (fwd) To: oneill, jrichard, mtorpey, jannunzi, abagul, bbarry, mbouchar, ncao, xcao, cychang, chachen, kchen, tchoi, ndesilva, rdias, sfan, tfragala, jhung, sjois, vkankipa, kkelly, rkher, cko, skyatsan, glazar, greg@puck.webo.dg.com, tleong, fliu, smakkapa, mmaliset, amanuja, cmclain, bmehta, kmirchan, rpakala, hcpatel, bphilip, sramacha, asarcar, msrdanov, mas@swl.msd.ray.com, ksomsama, ssundare, rtillson, cwu, chwang, wexu, yzhou, azinzuwa, lechner, cgopal Date: Wed, 19 Apr 1995 01:01:51 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1953 Status: RO Forwarded message: >From info-cvs-request@prep.ai.mit.edu Tue Apr 18 14:52:04 1995 Message-Id: <9504181841.AA20668@nova.tat.physik.uni-tuebingen.de> From: koenig@tat.physik.uni-tuebingen.de (Harald Koenig) Subject: bug in CVS-1.3 To: dgg@ksr.com, info-cvs@prep.ai.mit.edu Date: Tue, 18 Apr 1995 14:33:51 +0200 (MET DST) Cc: dawes@physics.su.oz.au (David Dawes), koenig@tat.physik.uni-tuebingen.de (Harald Koenig) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1458 Hi, there is a bug in CVS-1.3 when using ".cvsignore" files in (local) subdirectories. using the following directory structure prog/dir1 prog/dir2/.cvsignore prog/dir3 prog/dir4 where "dir2/.cvsignore" has only one line "*" (so that this directory and all it's subdirectroires are completely ignored), "dir3" and "dir4" are ignored too because the "hold" ignore list isn't reset after ascending from dir2. below is a short hack to reset the ignore list before ascending from subdirectories. Harald *** cvs-1.3/src/import.c.ORIG Tue Mar 31 23:56:11 1992 --- cvs-1.3/src/import.c Tue Apr 18 13:37:31 1995 *************** *** 291,296 **** --- 291,301 ---- } (void) closedir (dirp); } + + /* restore any per-directory ignore lists */ + ign_add_file ("/dev/null", 1); + + if (has_dirs) { if ((dirp = opendir (".")) == NULL) -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ From info-cvs-request@prep.ai.mit.edu Tue Apr 18 04:06:23 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA29379 for ; Tue, 18 Apr 1995 04:06:04 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03460; Tue, 18 Apr 95 01:05:24 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20982; Tue, 18 Apr 1995 03:08:55 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA11677; Tue, 18 Apr 1995 01:55:50 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA11673; Tue, 18 Apr 1995 01:55:48 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA20663; Tue, 18 Apr 1995 02:59:20 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA02603; Tue, 18 Apr 95 00:55:45 PDT Received: from relay.cs.ruu.nl (infix.cs.ruu.nl) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA10353; Tue, 18 Apr 95 03:55:41 EDT Received: from stego.cs.ruu.nl by relay.cs.ruu.nl with SMTP id AA24308 (5.67a/IDA-1.5 for ); Tue, 18 Apr 1995 09:55:39 +0200 From: Piet van Oostrum Received: (piet@localhost) by stego.cs.ruu.nl (8.6.10/8.6.10/ehk) id JAA12071; Tue, 18 Apr 1995 09:55:38 +0200 Date: Tue, 18 Apr 1995 09:55:38 +0200 Message-Id: <199504180755.JAA12071@stego.cs.ruu.nl> To: mahesh@dalmatian.com Cc: info-cvs@prep.ai.mit.edu Subject: Re: Notifying other members of the team of the commit In-Reply-To: <9504172113.AA07563@aquinas.dalmatian.com> References: <9504172113.AA07563@aquinas.dalmatian.com> Content-Length: 1706 Status: RO >>>>> mahesh@dalmatian.com (B.G. Mahesh) (BGM) writes: BGM> When I commit a file, I want other members of the team to be notified BGM> by email that the file has been checked in. How do I do this? I use this one with loginfo containing: ALL $CVSROOT/CVSROOT/warn_users "%s" (I have another one that mails the actually changed files also). #! /bin/sh # # used by cvs file "logfile": # warn_users dir file [files] # log-message piped trough this command # # change the following line mailto="xyz@abc.com" # mail to these persons tmpfile=/tmp/warn_users$$ trap "rm -f ${tmpfile} ; exit 0" 0 1 2 3 # trap on 'hangup', # 'interrupt', 'quit' and # exit from shell cat > ${tmpfile} mailprog="/usr/lib/sendmail -t" # mail program mailfrom=$USER # where mail originates from # # Specially for MH who did not understand 'normal' date formats.... # set `date` # Thu Feb 16 11:11:47 MET 1989 = Winter time # Mon Apr 10 13:53:24 MET DST 1989 = Summer time case $6 in DST) date="$1, $3 $2 $7 $4 +0200" ;; *) date="$1, $3 $2 $6 $4 +0100" ;; esac # # Mail it: # $mailprog < http://www.cs.ruu.nl/~piet From info-cvs-request@prep.ai.mit.edu Tue Apr 18 04:06:23 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA29379 for ; Tue, 18 Apr 1995 04:06:04 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03460; Tue, 18 Apr 95 01:05:24 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20982; Tue, 18 Apr 1995 03:08:55 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA11677; Tue, 18 Apr 1995 01:55:50 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA11673; Tue, 18 Apr 1995 01:55:48 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA20663; Tue, 18 Apr 1995 02:59:20 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA02603; Tue, 18 Apr 95 00:55:45 PDT Received: from relay.cs.ruu.nl (infix.cs.ruu.nl) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA10353; Tue, 18 Apr 95 03:55:41 EDT Received: from stego.cs.ruu.nl by relay.cs.ruu.nl with SMTP id AA24308 (5.67a/IDA-1.5 for ); Tue, 18 Apr 1995 09:55:39 +0200 From: Piet van Oostrum Received: (piet@localhost) by stego.cs.ruu.nl (8.6.10/8.6.10/ehk) id JAA12071; Tue, 18 Apr 1995 09:55:38 +0200 Date: Tue, 18 Apr 1995 09:55:38 +0200 Message-Id: <199504180755.JAA12071@stego.cs.ruu.nl> To: mahesh@dalmatian.com Cc: info-cvs@prep.ai.mit.edu Subject: Re: Notifying other members of the team of the commit In-Reply-To: <9504172113.AA07563@aquinas.dalmatian.com> References: <9504172113.AA07563@aquinas.dalmatian.com> Content-Length: 1706 Status: RO >>>>> mahesh@dalmatian.com (B.G. Mahesh) (BGM) writes: BGM> When I commit a file, I want other members of the team to be notified BGM> by email that the file has been checked in. How do I do this? I use this one with loginfo containing: ALL $CVSROOT/CVSROOT/warn_users "%s" (I have another one that mails the actually changed files also). #! /bin/sh # # used by cvs file "logfile": # warn_users dir file [files] # log-message piped trough this command # # change the following line mailto="xyz@abc.com" # mail to these persons tmpfile=/tmp/warn_users$$ trap "rm -f ${tmpfile} ; exit 0" 0 1 2 3 # trap on 'hangup', # 'interrupt', 'quit' and # exit from shell cat > ${tmpfile} mailprog="/usr/lib/sendmail -t" # mail program mailfrom=$USER # where mail originates from # # Specially for MH who did not understand 'normal' date formats.... # set `date` # Thu Feb 16 11:11:47 MET 1989 = Winter time # Mon Apr 10 13:53:24 MET DST 1989 = Summer time case $6 in DST) date="$1, $3 $2 $7 $4 +0200" ;; *) date="$1, $3 $2 $6 $4 +0100" ;; esac # # Mail it: # $mailprog < http://www.cs.ruu.nl/~piet From info-cvs-request@prep.ai.mit.edu Tue Apr 18 04:20:58 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA12693 for ; Tue, 18 Apr 1995 04:20:56 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB04787; Tue, 18 Apr 95 01:20:03 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA21173; Tue, 18 Apr 1995 03:23:34 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA11946; Tue, 18 Apr 1995 02:13:32 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA11942; Tue, 18 Apr 1995 02:13:31 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA21058; Tue, 18 Apr 1995 03:17:03 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA04168; Tue, 18 Apr 95 01:13:27 PDT Received: from slsa02t.stgl.netd.alcatel.de by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA10587; Tue, 18 Apr 95 04:13:24 EDT Received: from slbh01t1.bln.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <00263-0@slsa02t.stgl.netd.alcatel.de>; Tue, 18 Apr 1995 10:13:11 +0200 Received: from slbh04 by bln.sel.alcatel.de (4.1/SMI-4.0/DNI-7.0.1/blume_h-1.2) id AA27512; Tue, 18 Apr 95 10:12:36 +0200 From: Uwe.Graichen@bln.sel.alcatel.de (U. Graichen) Received: by slbh04 (4.1) id AA11639; Tue, 18 Apr 95 10:12:32 +0200 Date: Tue, 18 Apr 95 10:12:32 +0200 Message-Id: <9504180812.AA11639@slbh04> To: mahesh@dalmatian.com Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9504172113.AA07563@aquinas.dalmatian.com> (mahesh@dalmatian.com) Subject: Re: Notifying other members of the team of the commit Content-Length: 1128 Status: RO >>>>> "B" == B G Mahesh writes: B> When I commit a file, I want other members of the team to be notified B> by email that the file has been checked in. How do I do this? You can add a post-commit program to a module, directory, file, that sends mail to a dedicated list of guys or girls, or that posts a message to a local news group. See the CVS documentation cvs (5) in particular the info about the loginfo file, or the info about the module options (option -i). You should select the best solution for your needs. B> thanks bye uwe B> -- B> B.G. Mahesh | Email: mahesh@dalmatian.com B> System Analyst | mahesh@mahesh.com B> The Dalmatian Group Inc. | Home page: http://www.fred.net/mahesh/ B> User Interface Specialists | +========= Uwe Graichen / ALCATEL SEL AG Berlin ===================+ Email: graichen@bln.sel.alcatel.de ( Expressed opinions which happen to graichen@contrib.de ) correspond with those of my employer Phone: +49 30 7002 3399 ( are still my own. The others are mine. From info-cvs-request@prep.ai.mit.edu Wed Apr 19 11:53:43 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA13278 for ; Wed, 19 Apr 1995 11:53:41 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA22067; Wed, 19 Apr 95 08:52:30 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20247; Wed, 19 Apr 1995 10:56:01 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA17354; Wed, 19 Apr 1995 09:40:43 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA17350; Wed, 19 Apr 1995 09:40:42 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA18551; Wed, 19 Apr 1995 10:44:14 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA19782; Wed, 19 Apr 95 08:40:36 PDT Received: from cpdsc.com (sun001.cpdsc.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA00545; Wed, 19 Apr 95 11:40:08 EDT Received: from sun004.cpdsc.com by cpdsc.com (4.1/SMI-4.1) id AA00480; Wed, 19 Apr 95 15:39:02 GMT Received: from sun174.CPDSC by sun004.cpdsc.com (4.1/SMI-4.1) id AA03808; Wed, 19 Apr 95 10:39:45 CDT From: dwood@sun004.cpdsc.com (R. H. Wood) Message-Id: <9504191539.AA03808@sun004.cpdsc.com> Subject: Is this a bug - or what? (cvs-1.4A2) To: info-cvs@prep.ai.mit.edu Date: Wed, 19 Apr 1995 10:40:37 -0500 (CDT) Reply-To: dwood@sun004.cpdsc.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2785 Status: RO We have an interesting situation here that, I think, is showing up a bug in (a recursive) cvs update (and cvs checkout over existing tree) operation. The scenario is this: We have had a make file generation tool around that's been enhanced over time. Originally (when our cvs repository was first created), the makefiles required the presence of empty target directories. Since cvs checkout -r TAGNAME prunes empty directories, we were faced with makefiles that wouldn't work. So we created dummy cvs files for each target directory and tagged them with TAGNAME so our makefiles would be happy the next time we checked down a working tree to do a build. Well, as one would expect, our makefile generator tool has gotten smarter, and these empty target directories are no longer required to be present when doing a make. So, one of our developers, in the process of re-generating new makefiles with the new tool, was told to rm -rf all the target directories, (so he could start from a clean slate, I guess). He continued by creating and then running the new makefiles --- which created empty target directories for him (with the same names as the ones originally created in CVS, with the single dummy element). Now on to the prothesized cvs bug: it appears a cvs status command recurses the new working tree without complaint, but a cvs update has difficulties with these newly created empty directories, for which it sees copies in the repository. (The new-and-smarter makefiles we now use also create yet-another-directory now, and CVS update has no problem with them - presumably because there isn't a directory of the same name in the repository for it). So, I decided the "proper" thing to do is to check down a fresh tree using TAGNAME, recursively do a cvs remove on each target directory's dummy file and do a cvs commit. But it seems to me that just creates the same scenario, only differently, where the next developer that checks down using the TAGNAME will end up without any target directories, but the first time a new-style make is run, the directories get created. So the next recursive update will see them and complain that there's no CVS/Entries record, etc. and we're back where we started. So, is the _real_ (tm) solution to change the new make proceduree to use target directories of completely new names: ones guaranteed to be unknown to the repository? Or is there a "safe" solution/fix that could be made to cvs to make the behaviour of cvs update (or checkout) be more or less similar to cvs status ? -dick -- __________________________________________________________________________ R. H. Wood - dwood@cpdsc.com - rhw@woodwrk.lerctr.org +1-214-519-5758 DSC Communications Corporation, MS ATMS1, 1000 Coit Road, Plano,TX 75075 From info-cvs-request@prep.ai.mit.edu Wed Apr 19 19:12:04 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA28333 for ; Wed, 19 Apr 1995 19:12:02 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA07773; Wed, 19 Apr 95 12:29:13 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA18601; Wed, 19 Apr 1995 14:32:40 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28706; Wed, 19 Apr 1995 13:16:53 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28702; Wed, 19 Apr 1995 13:16:51 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA17021; Wed, 19 Apr 1995 14:20:24 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA04062; Wed, 19 Apr 95 12:16:46 PDT Received: from zazu.c3.lanl.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA07830; Wed, 19 Apr 95 13:28:08 EDT Received: (krk@localhost) by zazu.c3.lanl.gov (8.6.10/c93112801) id LAA05764; Wed, 19 Apr 1995 11:27:49 -0600 Date: Wed, 19 Apr 1995 11:27:49 -0600 From: Kenneth R Koch Message-Id: <199504191727.LAA05764@zazu.c3.lanl.gov> To: info-cvs@prep.ai.mit.edu, dwood@sun004.cpdsc.com Subject: Re: Is this a bug - or what? (cvs-1.4A2) Content-Length: 1881 Status: RO R. H. Wood writes: > We have an interesting situation here that, I think, is showing up > a bug in (a recursive) cvs update (and cvs checkout over existing > tree) operation. The scenario is this: > > ... > > Now on to the prothesized cvs bug: it appears a cvs status command > recurses the new working tree without complaint, but a cvs update > has difficulties with these newly created empty directories, for which > it sees copies in the repository. (The new-and-smarter makefiles we > now use also create yet-another-directory now, and CVS update has no > problem with them - presumably because there isn't a directory of the > same name in the repository for it). > > So, I decided the "proper" thing to do is to check down a fresh tree > using TAGNAME, recursively do a cvs remove on each target directory's > dummy file and do a cvs commit. > > But it seems to me that just creates the same scenario, only differently, > where the next developer that checks down using the TAGNAME will end > up without any target directories, but the first time a new-style make > is run, the directories get created. So the next recursive update will > see them and complain that there's no CVS/Entries record, etc. and we're > back where we started. > > So, is the _real_ (tm) solution to change the new make proceduree to > use target directories of completely new names: ones guaranteed to be > unknown to the repository? Or is there a "safe" solution/fix that > could be made to cvs to make the behaviour of cvs update (or checkout) > be more or less similar to cvs status ? A bridge burning non-CVSish way would be to simply blow away the offending CVS repository directories -- assuming there was never any real files in them anyway and you don't expect to need to recreate historical copies of these fake directories using CVS. Ken Koch Los Alamos National Laboratory From info-cvs-request@prep.ai.mit.edu Wed Apr 19 17:06:38 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA18994 for ; Wed, 19 Apr 1995 17:06:24 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27505; Wed, 19 Apr 95 13:54:41 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA29772; Wed, 19 Apr 1995 15:56:08 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02261; Wed, 19 Apr 1995 14:33:41 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02254; Wed, 19 Apr 1995 14:33:38 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA27485; Wed, 19 Apr 1995 15:37:11 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA22944; Wed, 19 Apr 95 13:30:54 PDT Received: from uropax.contrib.de by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA20084; Wed, 19 Apr 95 16:29:06 EDT Received: by uropax.contrib.de (Smail3.1.28.1 #3) id m0s1gMq-0007bKC; Wed, 19 Apr 95 22:28 MET DST Message-Id: From: graichen@contrib.de (Graichen) Subject: show the version tree of a CVS managed file To: info-cvs@prep.ai.mit.edu Date: Wed, 19 Apr 1995 22:28:55 +0200 (MET DST) Reply-To: graichen@bln.sel.alcatel.de X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859 Content-Transfer-Encoding: 8bit Content-Length: 12012 Status: RO Hi, any time ago (or a long time ago?) any guys ask about a program to show the version tree of a file. I posted a dirty perl script written by a student, usefull but dancerous since full of bugs. Remove it, please. This is the re-implementation of the old idea. It is a realy better script to show the version tree of a file. Try and enjoy :)) The option -help provides the usage message. Bye uwe ----------------------------------------------------------------------- Tina & Uwe Graichen #include Phone: +49 30 6569841 E-mail: graichen@contrib.de or graichen@bln.sel.alcatel.de ----------- cut here ------- eval "exec ${PERL:-perl} -S $0 $*" # -*- perl -*- if $running_under_some_shell; #!/usr/bin/perl # This program shows the development of a file out of CVS, # Invoke the program inside a checked out CVS environment. # # $Id: btree,v 1.8 1995/04/19 21:09:11 uwe Exp $ # # uwe graichen # graichen@contrib.de # graichen@bln.sel.alcatel.de # ## #require ( "utl.pl" ); # copied from the local utl.pl library # main script paths ( $Script = $0 ) =~ s#(.*/)##o; $ScriptDir = $1; $Script =~ s#\.pl##o; $\ = "\n"; # abbreviation package required for option processing require ( "abbrev.pl" ); sub abort { local ( $caller ) = " (" . join ( ' ', caller ) . ")" if $'DBG; warn ( "$'Script$caller: $_[0]\n" ); exit 1; } sub get_argument { local ( $what, $type ) = @_; $#ARGV < 0 && &'abort ( "Missing '$what' argument!" ); $_ = shift ( @ARGV ); { print ">> $type = '$_'" if $'DBG > 1; /^-\w/o && &'abort ( "'$what' argument begins with single '-'. " . "Use '--' instead to avoid conflicts with other options!" ); s/^--/-/o; # only '.@#-+%' are accepted as special chars in paths $type eq 'path' && m%^[\w@#-/\.]+$%o && last; $type eq 'abspath' && m%^/[\w@#-/\.]+$%o && last; $type eq 'number' && m%^\d+$%o && last; $type eq 'word' && m%^\w+$%o && last; $type eq 'string' && last; &'abort ( "Argument of type $type exptected for '$what'!" ); } $_; } # get_argument sub set_dbg_level { if ( $'DBG ) { $ENV { "DBG_$'Script" } = @_; } elsif ( $ENV { "DBG_$'Script" } ) { $'DBG = $ENV { "DBG_$'Script" }; } } #end of library copy #------------------------------------------------------------------------- #initialization #------------------------------------------------------------------------- #The tag pattern - print all tags $Tag_pat='.*'; #Tree output $Ptree_out = 1; #Tree depth printed $Depth = 5; #Line length $LL = 80; #initial revision $Revision_s = "1.1" ; $TagSepar = " "; $Vertical = "|"; $Rspace = " "; $BraStart = "\\"; #------------------------------------------------------------------------- # local subroutines #------------------------------------------------------------------------- # #print alphanumeric list #should be changed to use perl format output style # sub print_alpha_output { print $OFH "-----------------------------------------------"; print $OFH "File : ", $ARGV[0]; print $OFH "Position: ", $position; print $OFH "Head : ", $HEAD; print $OFH "-----------------------------------------------"; $Indent = " "; $Vertical = " "; $\= ""; foreach ( sort ( revcmp keys (%REV))) { next if ( $Revision_s && ( &nrevcmp ( $_, $Revision_s ) < 0)); chop ( $TAGS { $_} ); if ( $_ eq $position ) { print $OFH "Revision: [", $_, "]\n"; } else { print $OFH "Revision: ", $_, "\n"; } if ( $REV { $_ } ) { @Branches = split ( / /, $REV { $_ } ); chop ( @Branches ); foreach $br ( @Branches ) { print $OFH " Branch: $br "; &print_tags (0, split (/\*/, $TAGS { $br } )); print $OFH "\n"; } } if ( $TAGS { $_ } ) { print $OFH " Tag(s) : "; &print_tags (0, split (/\*/, $TAGS { $_} )); print $OFH "\n"; } } } # #Print a pseudo graphical tree # sub print_rev { local ( $rev, $ico ) = @_; local ( $icsave ) = $ico; local ( $ic ); local ( $rev_join ) = 0; $Indent = " "; while ( $ico ) { $ic = (($ico)*3)+$ico; while ( $ic ) { $Indent .= $Rspace; $ic--; } $rev_join += 2 + ((($icsave - $ico) * 4)); $Indent =~ s/(.{$rev_join}) /\1\|/; $ico--; } if ( $rev eq $position ) { $Indent =~ s/ $/\[/; print $OFH $Indent, $rev, "]"; $Indent =~ s/\[$/ /; } else { print $OFH $Indent, $rev; } $ic = (2 * $icsave) + 1; while ( $ic ) { $Indent .= $Rspace; $ic--; } } sub print_branch { local ( $ic, $branch ) = @_; local ( @currTags ); local ( $branhIndent ) = $Indent; local ( $brNameExt ) = 0; $ic = (2 * $ic) + 2; $branchIndent .= $Vertical if $ic; while ( $ic ) { # $brNameExt++; $branchIndent .= $Rspace; $ic--; } print $OFH $Indent, $Vertical, $BraStart, "\n"; if ( $TAGS { $branch } ) { @currTags = split ( /\*/, $TAGS { $branch } ); } else { $currTags[0] = "-> No CVS branch"; } # while ( length ($currTags[0]) < $brNameExt ) { # $currTags[0] .= "----"; # $brNameExt--; # } print $OFH $Indent, $Vertical, " ", $branch; &print_tags ( $ic, @currTags ); } sub print_tags { local ( $ic, @tags ) = @_; local ( $tagIndent ) = $Indent; local ( $tag ); local ( $collCount ); $ic = (2 * $ic) + 1; $tagIndent .= $Vertical if $ic; while ( $ic ) { $tagIndent .= $Rspace; $ic--; } $collCount = length ( $tagIndent ); foreach $tag ( @tags ) { $collCount += ( length ($tag) + 1 ); if ($collCount > $LL) { print $OFH "\n", $tagIndent; $collCount = length ($tagIndent) + length ($tag) + 1 ; } print $OFH $TagSepar, $tag; } } sub print_sep_line { print $OFH $Indent, $Vertical, "\n"; } sub print_lower_sep_line { print $OFH $Indent, "\n"; } sub nrevcmp { ($a, $b) = @_; return (&revcmp); } sub revcmp { local (@one) = split (/\./, $a); local (@two) = split (/\./, $b); local ($c); return (0) if ( $a cmp $b ) == 0; local ($l) = scalar (@one) >= scalar (@two) ? scalar (@one) : scalar (@two); for ( $c = 0; $c < $l ; $c++) { next if $one[$c] == $two[$c]; $one[$c] > $two[$c] ? return (1) : return (-1); } scalar (@one) < scalar (@two) ? return (-1) : return (1); } sub print_tree { local ( $bra ) = @_; local ( %lRev ) = %REV; local ( $currRev ); local ( $prevRevB, $currRevB, $brRev ); local ( $lastIc ) = 100; local ( $ic ); local ( $saveInd ); foreach $currRev ( sort ( revcmp keys (%lRev))) { #next if specified revision (-r rev) lower then the current one next if ( $Revision_s && ( &nrevcmp ( $currRev, $Revision_s ) < 0)); #next if another branch $currRev =~ /(.*)\.\d+$/; next if ( &nrevcmp ( $bra, $1 ) != 0 ); # compute indent count local ( $compCurrRev1 ) = $currRev; grep (s/\d+/1/g, $compCurrRev1 ); $ic = int (length ($compCurrRev1) / 4); &print_sep_line if $ic == $lastIc; $lastIc = $ic; &print_rev ( $currRev, $ic ); $xxx = $TAGS { $currRev }; chop ( $xxx ); #remove trailing ';' if ( $xxx ) { @currTags = split ( /\*/, $xxx ); &print_tags ( $ic, @currTags ); } if ( $lRev { $currRev } ) { local ( $curBra ); local (@Branches) = split ( / /, $lRev { $currRev } ); print $OFH "\n"; chop (@Branches); foreach $curBra ( sort (revcmp @Branches)) { &print_branch ( $ic, $curBra); print $OFH "\n"; $saveInd = $Indent; &print_tree ("$curBra"); $Indent = $saveInd; } } else { print $OFH "\n"; } } } #------------------------------------------------------------------------- #lets start the main #------------------------------------------------------------------------- # analysis of the command line, detection of option: $Usage = "$Script [options] file1 options: -o[output] Path -> Tree Output defoult is 'stdout' -r[evision] Rev -> start with revision Rev and print tree -t[ag_pattern] Reg-Exp -> Print tags that match the Reg-Exp only -n[o_tag] -> Don't print tag names -d[epth] No. -> Tree depth default value is 5 (4 Branches) -w[idth] No. -> Page width (printed characters per line) -a[lphanum] -> alphanumeric output -h[elp] -> Print this messages "; &abbrev (*options, '-help', '-DEBUG', '-revision', '-output', '-tag_pattern', '-no_tag', '-alphanum', '-depth', '-width', '-silent' ); while ( $ARGV[0] =~ /^(-|\+)/ ) { $_ = shift; $options { $_ } && ( $_ = $options { $_ } ); $_ eq '-silent' && ( $silent = 1, next); $_ eq '-output' && ( $Output = &get_argument ( $_, 'path' ), next); $_ eq '-revision' && ( $Revision_s = &get_argument ( $_, 'string' ) , next); $_ eq '-tag_pattern' && ( $Tag_pat = &get_argument ( $_, 'string' ) , next); $_ eq '-no_tag' && ( $No_tag = 1, next); $_ eq '-alphanum' && ( $Alpha_out = 1, $Ptree_out = 0, next); $_ eq '-depth' && ( $Depth = &get_argument ($_, 'number' ), next); $_ eq '-width' && ( $LL = &get_argument ($_, 'number' ), next); # debugging: $_ eq '-help' && ( ( print $Usage ), exit 0 ); $_ eq '-DEBUG' && ( $DBG = &get_argument ( $_, 'number' ) , next ); &abort ( "Unsupported or ambiguous option '$_', try '$Script -help'." ); } #even numbers level 1 -> two numbers, level 2 -> four numbers ... $Depth *= 2; &set_dbg_level; # verification that the file is in a CVS structure: &abort ("$Script aborted: '$ARGV[0]' is not in a CVS structure!\n") if (!-d "CVS"); # gets the version number of the checked-out file: $position=(split('/',`cat CVS/Entries | grep /$ARGV[0]/`))[2]; &abort ("$Script aborted: CVS knows nothing about '$ARGV[0]'!\n") if ($position eq ""); &abort ("$Script aborted: '$ARGV[0]' is not present in the CVS archive \t '$ARGV[0]' has been added but not committed yet!\n") if ($position eq "0"); if ( $Output ne "" ) { open ( OF, ">$Output" ) || &abort ("cannot open '$Output'"); $OFH = OF; } else { $OFH = STDOUT; } open (LOGF, "cvs log $ARGV[0] |") || &abort ("Cannot execute cvs log $ARGV[0] "); #analyse the CVS log output #two assoc arrays are build # %TAGS - index is the rev number - contains all tags # magic CVS brances are reduced to branch numbers # %REV - index is the rev number - contains all branches # while ( ) { if ( /^head:\s*(.*)/) { $HEAD = $1; } if ( /^symbolic names:/ ) { while ( ) { last if /^comment leader:/; /\s*([^:]*):\s*(.*)/; $CR = $2; $CT = $1; next if ( $CT !~ /$Tag_pat/o ); if ( $CR =~ /(.*)\.0\.(\d+)$/ ) { #CVS's magic branch mechanism $TAGS {$1 . "\." . $2} .= $CT . "*" ; } $TAGS {$CR} .= $CT . "*" if ( $No_tag != 1 ) ; } } if ( /^revision\s*(.*)$/ ) { $LastRev = $1; next if (length ($LastRev)) > ((2 * $Depth) - 1); $REV { $1 } = ''; } if ( /^branches:\s*(.*)$/ ) { next if (length ($LastRev)) > ((2 * $Depth) - 1); $REV { $LastRev } = $1; $REV { $LastRev } =~ s/ / /g; } } #add (cvs) created but not real commited branches foreach $xbrev ( keys (%TAGS) ) { next unless $xbrev =~ /(.*)\.0\.(\d+)$/; local ( $rcsBranch ) = $1 . "\." . $2; local ($branch) = $1; if ( $REV {$branch} !~ /$rcsBranch/ ) { $REV {$branch} .= " " . $rcsBranch . ";"; $REV {$branch} =~ s/^ //o; # remove leading spaces } delete $TAGS { $xbrev }; } # #print out the arrays #currently two different styles exists currently #you may add any further, e.g. a real pixmap output is a dream :)) # &print_alpha_output if ( $Alpha_out ); if ( $Ptree_out ) { local ($ORS) = $\; $\ = ""; $Revision_s =~ /(.*)\.\d+$/; $RevisionInit = "$1"; # chop ( $RevisionInit ); print $OFH "File : ", $ARGV[0], "\n"; &print_tree ("$RevisionInit"); # &print_tree (""); $\ = $ORS; } if ( $Output ne "" ) { close ($OFH); } exit (0); From info-cvs-request@prep.ai.mit.edu Wed Apr 19 16:33:12 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA01672 for ; Wed, 19 Apr 1995 16:33:11 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21382; Wed, 19 Apr 95 13:21:48 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA25931; Wed, 19 Apr 1995 15:24:52 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01366; Wed, 19 Apr 1995 14:13:06 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01361; Wed, 19 Apr 1995 14:13:05 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA24728; Wed, 19 Apr 1995 15:16:37 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA18963; Wed, 19 Apr 95 13:12:51 PDT Received: from netmail.austin.ibm.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA18613; Wed, 19 Apr 95 16:12:45 EDT Received: from fliegen.austin.ibm.com (fliegen.austin.ibm.com [129.35.128.200]) by netmail.austin.ibm.com (8.6.11/8.6.11) with SMTP id PAA59591 for ; Wed, 19 Apr 1995 15:12:45 -0500 Received: by fliegen.austin.ibm.com (AIX 4.1/UCB 5.64/4.03-client-2.6) for info-cvs@prep.ai.mit.edu at austin.ibm.com; id AA02882; Wed, 19 Apr 1995 15:12:45 -0500 From: knutson@austin.ibm.com (Jim Knutson) Message-Id: <9504192012.AA02882@fliegen.austin.ibm.com> Subject: undoing main branch changes To: info-cvs@prep.ai.mit.edu Date: Wed, 19 Apr 1995 15:12:44 -0500 (CDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 591 Status: RO I can't seem to find a way to "undo" main branch changes which don't need to be merged with the vendor branch anymore. Scenario o Vendor ships release 1 o bug is detected and fixed in local copy, fix sent to vendor o vendor encorporates fix o Vendor ships release 2 o import tries to merge local changes from now on even though no local changes exist (other than the $Revision:$ field). Is there a way to make it ignore the main branch changes now? Is this due to the vendor shipping with $Revision: x.y$ fields so they never match and therefore conflict with each other? Thanks, Jim From info-cvs-request@prep.ai.mit.edu Wed Apr 19 16:41:25 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA20829 for ; Wed, 19 Apr 1995 16:41:20 -0400 Received: from Central.Sun.COM ([129.152.1.1]) by Sun.COM (sun-barr.Sun.COM) id AA22036; Wed, 19 Apr 95 13:25:47 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA26324; Wed, 19 Apr 1995 15:27:49 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01470; Wed, 19 Apr 1995 14:15:37 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01466; Wed, 19 Apr 1995 14:15:34 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA25061; Wed, 19 Apr 1995 15:19:07 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA19169; Wed, 19 Apr 95 13:13:37 PDT Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA16317; Wed, 19 Apr 95 15:36:35 EDT Received: from monad.armadillo.com (monad.armadillo.com [199.199.0.1]) by monad.armadillo.com (8.6.11/8.6.11) with ESMTP id OAA01593; Wed, 19 Apr 1995 14:36:49 -0500 Message-Id: <199504191936.OAA01593@monad.armadillo.com> From: "david d `zoo' zuhn" Organization: armadillo zoo software -- +1 500 DOS BITES (really) To: algeej@ccmail.ncsc.navy.mil Cc: info-cvs@prep.ai.mit.edu, nilesh@hagar.aspentec.com (Nilesh PatelL/ATHQ) Subject: Re: CVS-1.4A2 better for OSF/1?? Why? In-Reply-To: Your message of "Wed, 19 Apr 1995 13:45:40 CDT." <9503197983.AA798324755@CCMAIL.NCSC.NAVY.MIL> X-Punishment: I will not trade pants with others Date: Wed, 19 Apr 1995 14:36:44 -0500 Sender: zoo@armadillo.com Content-Length: 422 Status: RO The reason that the mini-FAQ suggests use of 1.4A2 on OSF/1 machine is that you won't have to spend any time fixing the code to work on OSF/1. That's already been done and incorporated into the new release. The same principle applies to the Irix5 recommendation as well. I don't know of any reason why a version of 1.3 that's been ported won't work on those machines, but it's a lot easier to get started with 1.4A2. From info-cvs-request@prep.ai.mit.edu Wed Apr 19 15:26:56 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA11736 for ; Wed, 19 Apr 1995 15:26:54 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA06699; Wed, 19 Apr 95 12:25:48 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA18133; Wed, 19 Apr 1995 14:29:18 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28688; Wed, 19 Apr 1995 13:16:25 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28683; Wed, 19 Apr 1995 13:16:24 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA16956; Wed, 19 Apr 1995 14:19:57 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA03925; Wed, 19 Apr 95 12:16:19 PDT Received: from telesys.ncsc.navy.mil ([130.109.120.22]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12633; Wed, 19 Apr 95 14:42:43 EDT Received: from CCMAIL.NCSC.NAVY.MIL by telesys.ncsc.navy.mil (4.1/SMI-4.1) id AA22838; Wed, 19 Apr 95 13:24:03 PDT Received: from cc:Mail by CCMAIL.NCSC.NAVY.MIL id AA798324755; Wed, 19 Apr 95 13:45:40 CDT Date: Wed, 19 Apr 95 13:45:40 CDT From: algeej@ccmail.ncsc.navy.mil Encoding: 19 Text Message-Id: <9503197983.AA798324755@CCMAIL.NCSC.NAVY.MIL> To: info-cvs@prep.ai.mit.edu, nilesh@hagar.aspentec.com (Nilesh PatelL/ATHQ) Subject: Re: CVS-1.4A2 better for OSF/1?? Why? Content-Length: 744 Status: RO We have been running cvs v1.3 on our OSF computers since November. In fact, the repository is on this machine. All of our developers interact with this repository (We have developers using SGI, Sun, HP, and Alpha) by setting $CVSROOT to a NFS mounted volume. ______________________________ Reply Separator _________________________________ Subject: CVS-1.4A2 better for OSF/1?? Why? Author: nilesh@hagar.aspentec.com (Nilesh PatelL/ATHQ) at -INTERNET Date: 4/18/95 14:58 We are planning to install cvs on an OSF/1 machine. The mini-FAQ for cvs says that, cvs-1.4A2 is better for OSF, although it is not officially released. What are the changes that make cvs-1.4 better for OSF/1 Nilesh From info-cvs-request@prep.ai.mit.edu Fri Apr 14 10:23:42 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA06445 for ; Fri, 14 Apr 1995 10:23:36 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03247; Fri, 14 Apr 95 07:20:35 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA12582; Fri, 14 Apr 1995 09:23:59 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04601; Fri, 14 Apr 1995 08:15:15 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04597; Fri, 14 Apr 1995 08:15:13 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA12230; Fri, 14 Apr 1995 09:18:40 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA02616; Fri, 14 Apr 95 07:15:07 PDT Received: from access.rrinc.com.blacksburg.va.us by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA03937; Fri, 14 Apr 95 10:15:04 EDT Received: by access.rrinc.com.blacksburg.va.us (5.65/1.35) id AA28743; Fri, 14 Apr 95 10:14:51 -0400 From: eric@access.rrinc.com.blacksburg.va.us (Eric Bloodworth) Message-Id: <9504141414.AA28743@access.rrinc.com.blacksburg.va.us> Subject: Re: Checkout problem To: RFORGEY@ariel.gi.com (Robert Forgey) Date: Fri, 14 Apr 1995 10:14:50 -0400 (EDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <01HPAKK1BW82D6KILK@ARIEL.GI.COM> from "Robert Forgey" at Apr 13, 95 02:20:57 pm Reply-To: eric@access.rrinc.com.blacksburg.va.us X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7090 Status: RO Robert Forgey wrote: > > >>>>> "Eric" == Eric Bloodworth writes: > > Eric> jthayer@dcs.simpact.com wrote: > > Eric> I find this limitation to be the most frustrating limitation of CVS, > Eric> especially when you are attempting to "source" control libraries. > Eric> Ideally, you want to check out every library that a program needs into > Eric> one directory which you tell the linker about. > Eric> The solution I came up with for RRI is less than elegant. > Eric> The ability to check out libraries into the currect directory > Eric> from different repository locations would have been a great help. > > I have to deal with a similar requirement, and this is what I'm > proposing: > > We have an application that we need to link to different versions of a > library. There may be more than one version in development at a time > (that is, we need branching). To make it more specific, I want to be > able to link with foolib_v8 or foolib_v8_profiling. I am planning to > set up the directory like this: > > > | > project > | > ---------+----------------------+--+-----------------+-------- > | | | > libs application foolib > +-----+----+ ----+------ ----+---- > foolibv8 foolibv8_prof | This is where > ----+---- -----+------ bunch o' files foolib source > foolib src foolib src ... resides in the > for version for version CVS repository. > 8 8 with code > for profiling > > > > The source in project/foolib/v8 has been checked out with a FOOLIB_V8 > tag, and the source in project/foolib/v8_profiling has been checked > out with a FOOLIB_V8_PROFILING tag. I can check out the source into > the different directories with: > > cd project > cvs co -d libs/foolibv8 foolib to get the latest version > cvs co -r VERSION_8_PROFILING -d libs/foolibv8_prof foolib > to get the profiling version > > > > When I go to project/application and build bof.hex (it's an embedded > app), the makefile knows to go to ../../libs/foolib* to get the > correct library version. > > This way I can have my libraries under source control, have different > versions immediately available, use branching for the libraries, and > do it the CVS way... > > Has this made any sense? Does it seem reasonable? > > BTW - I'm using CVS1.3 on OS/2 2.1 (at least it's not DOS...:)) > > Thanks > > Bob Forgey voice: 1-619-455-1500 > Senior Software Engineer/Firmware Walla email: rforgey@gi.com > Stellcom Technologies / General Instrument San Diego CA USA > This is essentially what I'm doing except that I'm taking special care to keep the assocation between libraries and their interface headers. I'm also not using branches for different library types. The following is the way I'm doing it. Keep in mind that there's perl scripts that do the grunt cvs work and that our build system is integrated with this architecture. Otherwise, it would be too cumbersome for users: In addition, although it appears to work, this system is still under development. In $CVSROOT I have the following modules: packages - contains special "binding" files library - contains librarys and interface files In each of these directories there is a module for each platform that we develop for. For example, two of the platforms we develop for are Unixware (usl), and Sunos (sparcsun), so the directories look like this: packages usl alibrary sparcsun alibrary library usl libalibrary.a alibrary.h sparcsun libalibrary.a alibrary.h Each binding file records the absolute version of one or more files in library. For example, alibrary might have the following: libalibrary.a 1.3 alibrary.h 1.1 Whenever a library is made available to others (or "published"), a new binding file is created and checked in to the appropriate package module subdirectory. It is also tagged with a version the user specifies. This tag is always "publish" for libraries which are well tested, and something else for intermediate development. The libraries and headers are also checked into the library module in the appropriate platform. (Actually the libraries and headers are checked in first to generate valid version numbers for the binding file). When a makefile (a specialized build tool actually), requests a library for a link, the binding file is checked out and then each library in the binding file is checked out. The same is done for the interface headers before the compile begins. A project directory looks like this: project src1 src2 ... usl build.cfg (for our build system) sparcsun (say I'm building for the sun) build.cfg (part of the sparcsun module, for our build system) library (not part of the sparcsun module libalibrary.a alibrary.h packages (not part of the sparcsun module) By default users only get libraries with the "publish" tag attached so they don't get a library which is in some intermediate state of development. They can also specify a particular library version in the build system. One advantage of the binding files (maybe their only advantage) is that they represent a record of the development of each library. By adding special tags to the binding files we should be able to recover the exact sources that were used to build each library. This is important when we will want to reduce the amount of space used by the library module by outdating old library files. We can delete the oldest libraries while keeping the entire binding files history, and still be able to recreate an old library if needed. I had not thought of using branches for different kinds of library development. The current idea is that different kinds of libraries built from the same sources would be listed in the same binding file, and that the build system would select the right one. Something to look into. I'm not sure how CVS could be modified to provide the equivalent of a binding file, or if you'd even want too. It's essentially one line of the modules file with a revision feature added (and of course, the ability to check out files from different places in the repository). You'd have to allow for module definitions in separate files in order to get history for each definition though. Hmmm, who likes that monolithic modules file anyway? Eric ---- Eric D. Bloodworth || Recognition Research, Inc email: eric@ || Phone: (703) 231-6500 Fax (703) 231-3568 Phone: (703) 231-4577 || Suite 1200, 1872 Pratt Drive E-mail preferred || Blacksburg VA 24060 ---------------------- Web Page: http:// = access.rrinc.com.blacksburg.va.us From info-cvs-request@prep.ai.mit.edu Fri Apr 14 11:53:12 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA14128 for ; Fri, 14 Apr 1995 11:53:10 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA15246; Fri, 14 Apr 95 08:51:11 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA17015; Fri, 14 Apr 1995 10:54:35 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10499; Fri, 14 Apr 1995 09:42:24 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10495; Fri, 14 Apr 1995 09:42:23 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA16496; Fri, 14 Apr 1995 10:45:51 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA13909; Fri, 14 Apr 95 08:42:19 PDT Received: from fionn.lbl.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA08631; Fri, 14 Apr 95 11:42:15 EDT Received: (mike@localhost) by fionn.lbl.gov (8.6.11/8.6.5) id IAA24976; Fri, 14 Apr 1995 08:42:03 -0700 Message-Id: <199504141542.IAA24976@fionn.lbl.gov> From: mike@fionn.lbl.gov (Michael Helm) Date: Fri, 14 Apr 1995 08:42:02 PDT In-Reply-To: eric@access.rrinc.com.blacksburg.va.us (Eric Bloodworth) "Re: Checkout problem" (Apr 14, 10:14am) Reply-To: mike@fionn.lbl.gov X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: eric@access.rrinc.com.blacksburg.va.us Subject: Re: Checkout problem Cc: info-cvs@prep.ai.mit.edu Content-Length: 2035 Status: RO On Apr 14, 10:14am, Eric Bloodworth wrote: > > We have an application that we need to link to different versions of a > > library. There may be more than one version in development at a time > > (that is, we need branching). To make it more specific, I want to be > In $CVSROOT I have the following modules: > > packages - contains special "binding" files > library - contains librarys and interface files > > In each of these directories there is a module for each platform that we > develop for. For example, two of the platforms we develop for are > Unixware (usl), and Sunos (sparcsun), so the directories look like this: > > packages > usl > alibrary > sparcsun > alibrary > > library > usl > libalibrary.a > alibrary.h > sparcsun > libalibrary.a > alibrary.h I'm involved in a project that's turning in this direction. The way cvs is used here, in part influenced by the way the supporting "glue" has been structured, & by management jawboning, cvs branches aren't used. What seems to be happening is that src -(function of time)-> src_arch1 src_arch2 src_arch3 ... where src_arch* are related sequenced versions, dependent on the architecture. The software package as a whole is structured as a bus, so the main problems come when the different packages interact eg basically the interface is in the include files. It's often the case that a particular developer will have no access (& no interest or funded time either) to port a particular module to a particular architecture. It was never the intention to have multiple versions of the source, but that seems to be what's evolved! Does anyone have any thoughts or relevant experience that might help me use cvs to control or rein this in? It scares me a little, as if it puts a little more entropy or generates a little more chaos than I'd like to see. On the other hand it appears that Eric's scheme is the one we're going to converge to. Thanks, ==mwh From info-cvs-request@prep.ai.mit.edu Fri Apr 14 15:54:42 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA12457 for ; Fri, 14 Apr 1995 15:54:39 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA23895; Fri, 14 Apr 95 12:50:27 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA28798; Fri, 14 Apr 1995 14:53:53 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23910; Fri, 14 Apr 1995 13:38:29 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23906; Fri, 14 Apr 1995 13:38:27 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA28413; Fri, 14 Apr 1995 14:41:56 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA22240; Fri, 14 Apr 95 12:38:19 PDT Received: from zazu.c3.lanl.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA22691; Fri, 14 Apr 95 15:37:55 EDT Received: (krk@localhost) by zazu.c3.lanl.gov (8.6.10/c93112801) id NAA02846; Fri, 14 Apr 1995 13:37:39 -0600 Date: Fri, 14 Apr 1995 13:37:39 -0600 From: Kenneth R Koch Message-Id: <199504141937.NAA02846@zazu.c3.lanl.gov> To: info-cvs@prep.ai.mit.edu, hildjj@fuentez.com Subject: Re: Which files are tagged? Content-Length: 288 Status: RO Joe Hildebrand writes: > > If I tag a subset of files from a module, is there an easy way to > determine just which files have that tag, at some later date? > Not a nice CVSish way that I know of. A quick and dirty UNIX backdoor way is: % grep '^:' $CVSROOT//*,v From info-cvs-request@prep.ai.mit.edu Tue Apr 25 19:04:38 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA05756 for ; Tue, 25 Apr 1995 19:04:36 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21623; Tue, 25 Apr 95 15:40:51 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA07126; Tue, 25 Apr 1995 17:39:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA17149; Tue, 25 Apr 1995 16:24:57 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA17145; Tue, 25 Apr 1995 16:24:56 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA06397; Tue, 25 Apr 1995 17:24:53 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA18823; Tue, 25 Apr 95 15:24:36 PDT Received: from zazu.c3.lanl.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA16199; Tue, 25 Apr 95 18:24:25 EDT Received: (krk@localhost) by zazu.c3.lanl.gov (8.6.10/c93112801) id QAA00798; Tue, 25 Apr 1995 16:24:14 -0600 Date: Tue, 25 Apr 1995 16:24:14 -0600 From: Kenneth R Koch Message-Id: <199504252224.QAA00798@zazu.c3.lanl.gov> To: info-cvs@prep.ai.mit.edu, buchholz@noao.edu Subject: Re: troubles in module land Content-Length: 1979 Status: RO Nick C. Buchholz writes: > I have a set of modules defined as follows > > # module definitions in transputer tree > b011 -d b011 dataacq/wfire/tp/b011 > bench -d bench dataacq/wfire/tp/bench > c004 -d c004 dataacq/wfire/tp/c004 > dspw -d dspw dataacq/wfire/tp/dspw > tpcommon -d common dataacq/wfire/tp/common > f008 -d f008 dataacq/wfire/tp/f008 > inst -d inst dataacq/wfire/tp/inst > mt -d mt dataacq/wfire/tp/mt > rom -d rom dataacq/wfire/tp/rom > seq -d seq dataacq/wfire/tp/seq > tputil -d util dataacq/wfire/tp/util > ucode -d ucode dataacq/wfire/tp/ucode > > #tp dataacq/wfire/tp # easy tp module > tp dataacq/wfire/tp Makefile README com.make util.make &b011 \ > &bench &c004 &dspw &tpcommon &f008 &inst \ > &mt &rom &seq &tputil &ucode > > If I checkout module tp with "cvs checkout tp" I get everything except the > last module ucode. I tried swapping ucode and tputil and then tputil doesn't > get checked out. the error message is > > cvs checkout: cannot find module `ucode ' - ignored > > if I do a "cvs checkout ucode" I get the ucode directoryand file checked out > just fine. > > Any hints as to what's going wrong?? > > PS it sure would be nice if RCS had a general -v switch to get its version or > is there one I've missed?? Because all of the included modules in the tp module are retrieved from the same base directory (dataacq/wfire/tp) with directory names specified via -d the same as their repository names, an alternative definition of module tp could be tp dataacq/wfire/tp Makefile README com.make util.make b011 \ bench c004 dspw tpcommon f008 inst \ mt rom seq tputil ucode And then, unless you have some other stuff in dataacq/wfire/tp that you don't want, why not this simple definition tp dataacq/wfire/tp These simplier non-including defs might work better. ;-) Ken Koch Los Alamos National Laboratory From info-cvs-request@prep.ai.mit.edu Tue Apr 25 15:05:05 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA06468 for ; Tue, 25 Apr 1995 15:05:02 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05541; Tue, 25 Apr 95 11:57:40 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA24746; Tue, 25 Apr 1995 13:54:02 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06603; Tue, 25 Apr 1995 12:47:19 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06599; Tue, 25 Apr 1995 12:47:17 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA24417; Tue, 25 Apr 1995 13:47:15 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA03681; Tue, 25 Apr 95 11:47:02 PDT Received: from ncrhub1.ATTGIS.COM (h192-127-251-16.ATTGIS.COM) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA03102; Tue, 25 Apr 95 14:46:40 EDT Received: from ncr-sd by ncrhub1.ATTGIS.COM id ak26707; 25 Apr 95 14:05 EDT Received: by ncr-sd.SanDiegoCA.ATTGIS.COM; 25 Apr 95 10:53:53 PDT Received: by lcpd-sd.SanDiegoCA.NCR.COM; 25 Apr 95 10:53:18 PDT Received: by gsc-smtp with Microsoft Mail id <2F9D37CB@gsc-smtp>; Tue, 25 Apr 95 10:56:27 PDT From: "Simmons, Phoebe" To: Conrad Fernandes , layer Cc: info-cvs Subject: Re: CVS - Intel - Windows NT 3.5? Date: Tue, 25 Apr 95 10:53:00 PDT Message-Id: <2F9D37CB@gsc-smtp> Encoding: 27 TEXT X-Mailer: Microsoft Mail V3.0 Content-Length: 1060 Status: RO I am happy to see the success of CVS for windows NT 3.5. However, is there anyone using CVS in this environment where PowerBuilder is being used. How does/would CVS interact with files within the .pbl file structure of PowerBuilder? Is there any hope? Phoebe Simmons phoebe.simmons@sandiegoCA.attgis.com Phone (619) 485-3269 ---------- I have a working CVS for NT 3.5 (actually, I'm running 3.51 beta, now) on Intel. I took the CVS sources from Erik van Linstee (cvs13p7, I believe) and recently compiled with MSC (8.0, I think). I also had to compile rcs564 and gnu diff 2.5 with the same compiler, to get cvs to work properly. It took me a week to work out the bugs (and I recently fixed a bug in merging). The RCS and GNU diff from which I started came from ftp.cdrom.com:/pub/cica/nt/gr564s.zip ftp.cdrom.com:/pub/cica/nt/gd25s.zip Kevin Layer layer@Franz.COM http://www.franz.com/ Franz Inc., 1995 University Avenue, Suite 275, Berkeley, CA 94704, USA Phone: (510) 548-3600 FAX: (510) 548-8253 From info-cvs-request@prep.ai.mit.edu Tue Apr 25 14:27:18 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA02163 for ; Tue, 25 Apr 1995 14:27:16 -0400 Received: from Sun.COM by ulowell.uml.edu with SMTP id AA12571 (5.67b/IDA-1.5 for ); Tue, 25 Apr 1995 13:58:59 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA22311; Tue, 25 Apr 95 10:54:51 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA21689; Tue, 25 Apr 1995 12:54:41 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03634; Tue, 25 Apr 1995 11:48:51 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03630; Tue, 25 Apr 1995 11:48:49 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA21385; Tue, 25 Apr 1995 12:48:48 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA20797; Tue, 25 Apr 95 10:48:46 PDT Received: from darkstar.bos.locus.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA29277; Tue, 25 Apr 95 13:48:41 EDT To: info-cvs@prep.ai.mit.edu Subject: Miscellaneous questions Date: Tue, 25 Apr 1995 13:48:27 +0000 From: Steve Zimmerman Sender: saz@locus.com Message-Id: <"darkstar.b.210:25.03.95.17.48.40"@locus.com> Content-Length: 1723 Status: RO We're considering installing CVS 1.4A2 on some of our systems, but other systems will still be using CVS 1.3. Are these two versions compatible? Specifically, if I modify the database with 1.4A2, will CVS 1.3 still be able to work properly? We are unable to get multiple branches to work properly. The top of our main trunk is currently revision 1.2; a few days ago, someone created a branch, which is now revision 1.2.0.2. When I tried to create a new branch, also off 1.2, I was expecting to get 1.2.2.2, or something like it, but instead got 1.2.0.4, which looks like it will be conflicting with the recently created branch. I tried various versions of the "tag" and "rtag" commands, and I used versions of the "rtag" command that both did and did not reference a symbolic tag at the top of the main trunk. None of this had any effect. Has anyone seen this problem, and is there a way around it? The problem occurred in CVS 1.3; is this problem known to be fixed in later versions of CVS? After running into the problem described in the last paragraph, I decided to try to work around it by bumping all the files in my module to a higher revision number, and then creating a branch off that new revision. Unfortunately, I couldn't convince CVS to create a higher revision for unmodified files, something I've been able to do with other versions of CVS. I tried commands such as cvs commit -r4 directory cvs commit -r4.0 directory cvs commit -r4.1 directory but nothing worked. How do I establish a new revision level for unmodified files in CVS 1.3? Finally, does anyone know where I can find a copy of CVS 1.3-s2 or CVS 1.3.1? Thanks a lot! Steve Zimmerman Locus Computing Corporation z@locus.com From info-cvs-request@prep.ai.mit.edu Tue Apr 25 10:56:18 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA09436 for ; Tue, 25 Apr 1995 10:56:15 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24689; Tue, 25 Apr 95 05:23:52 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA04170; Tue, 25 Apr 1995 07:23:44 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18797; Tue, 25 Apr 1995 06:19:14 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18793; Tue, 25 Apr 1995 06:19:13 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA04014; Tue, 25 Apr 1995 07:19:11 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA24136; Tue, 25 Apr 95 05:19:10 PDT Received: from ns.fnet.fr by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA10065; Tue, 25 Apr 95 08:18:56 EDT Received: by ns.fnet.fr (5.65c8d/AFUU-4.2.3) via EUnet-France id AA14420; Tue, 25 Apr 1995 14:18:33 +0200 (MET) Date: Tue, 25 Apr 1995 14:18:33 +0200 From: Philippe Bereski Message-Id: <199504251218.AA14420@ns.fnet.fr> To: info-cvs@prep.ai.mit.edu Subject: How to remove a development branch ? Content-Length: 1275 Status: RO Hi, I'm going to implement what Kenneth R. Koch has proposed about the merge of several development branchs. (See Message-Id: <199503241621.JAA01665@zazu.c3.lanl.gov> on March 24th wich is a good solution to FAQ 4C.5) I would like to get ride of a development branches (bp_group) after it has been successfuly merged onto the trunc (or a main development branch). I would like to do something like: cvs admin -o:bp_group module but this is obviously translated for each file of module into cvs admin -o:a.b.c.0.x while I rather would like to get something like cvs admin -o:a.b.c.x.HEAD Is it an other solution than: - Going into cvs sources and add some flag to "cvs admin" - Creating a shell/perl script that gets head of branch for each file and runs cvs admin -o:xxx on each of them ? Thanks to you Philippe. -- +--------------------------------+-------------------------------------+ |Fnet | Voice : (33) 1 6449 1502 | |Philippe Bereski | Fax : (33) 1 6449 1518 | |52, avenue de la Grande Armee | Email : Philippe.Bereski@fnet.fr | |75017 PARIS - FRANCE | | +--------------------------------+-------------------------------------+ From info-cvs-request@prep.ai.mit.edu Mon Apr 24 16:41:46 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA16865 for ; Mon, 24 Apr 1995 16:41:42 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25016; Mon, 24 Apr 95 13:21:04 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA12394; Mon, 24 Apr 1995 15:20:49 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01535; Mon, 24 Apr 1995 14:14:23 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01529; Mon, 24 Apr 1995 14:14:21 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA12053; Mon, 24 Apr 1995 15:14:19 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA23656; Mon, 24 Apr 95 13:14:16 PDT Received: from hyper.Franz.COM by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA04205; Mon, 24 Apr 95 16:14:11 EDT Received: from vapor.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA24356; Mon, 24 Apr 95 13:13:57 PDT Received: from localhost by vapor.Franz.COM (4.1/FI-2.0) id AA05353; Mon, 24 Apr 95 13:14:44 PDT Message-Id: <9504242014.AA05353@vapor.Franz.COM> To: Conrad Fernandes Cc: info-cvs@prep.ai.mit.edu Subject: Re: CVS - Intel - Windows NT 3.5? In-Reply-To: Your message of Mon, 24 Apr 1995 13:32:58. <9504241732.AA02695@mailhost.viewlogic.com> Date: Mon, 24 Apr 1995 13:14:43 -0700 From: Kevin Layer Content-Length: 820 Status: RO I have a working CVS for NT 3.5 (actually, I'm running 3.51 beta, now) on Intel. I took the CVS sources from Erik van Linstee (cvs13p7, I believe) and recently compiled with MSC (8.0, I think). I also had to compile rcs564 and gnu diff 2.5 with the same compiler, to get cvs to work properly. It took me a week to work out the bugs (and I recently fixed a bug in merging). The RCS and GNU diff from which I started came from ftp.cdrom.com:/pub/cica/nt/gr564s.zip ftp.cdrom.com:/pub/cica/nt/gd25s.zip I wouldn't mind zipping up my exe's and putting them somewhere. Does anyone have a suggestion as to where I should put them? Kevin Layer layer@Franz.COM http://www.franz.com/ Franz Inc., 1995 University Avenue, Suite 275, Berkeley, CA 94704, USA Phone: (510) 548-3600 FAX: (510) 548-8253 From info-cvs-request@prep.ai.mit.edu Mon Apr 24 14:43:56 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA18555 for ; Mon, 24 Apr 1995 14:43:46 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29136; Mon, 24 Apr 95 11:22:22 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA05452; Mon, 24 Apr 1995 13:18:29 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24244; Mon, 24 Apr 1995 12:05:25 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24239; Mon, 24 Apr 1995 12:05:23 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA04695; Mon, 24 Apr 1995 13:05:22 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA25184; Mon, 24 Apr 95 11:03:33 PDT Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AB25876; Mon, 24 Apr 95 14:03:13 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA09902; Mon, 24 Apr 1995 14:03:10 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA24055; Mon, 24 Apr 95 14:03:05 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id OAA28151; Mon, 24 Apr 1995 14:03:04 -0400 Date: Mon, 24 Apr 1995 14:03:04 -0400 Message-Id: <199504241803.OAA28151@kayak.odi.com> To: surya@premenos.com Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <199504212236.PAA21369@tortosa.templar.net> (message from Surya Koneru on Fri, 21 Apr 1995 15:36:50 -0700) Subject: Re: Timestamps in CVS... Reply-To: dgg@odi.com Content-Length: 1082 Status: RO > I am using cvs 1.3. When I use 'cvs commit' to checkin sources, > the timestamps are screwed up. Is there any environment variable setting > that I should be using. Any help is appreciated. Does this section of the FAQ apply? ================================================================ 3I.5 Why does "log" tell me a file was committed exactly 5 hours later than I know it was? I can tell by this question that you were working in a time zone that is 5 hours behind GMT (e.g. the U.S. East Coast in winter). RCS file dates are stored in GMT to allow users in different time zones to agree on the meaning of a timestamp. At first glance this doesn't seem necessary, but many companies use distributed file systems, such as NFS or AFS, across multiple timezones. Some standard form must be used. GMT, as the "grid origin", is an obvious candidate. The only other reasonable choice is to put the timezone information in all the time stamps, but that changes the RCS file format incompatibly, a step which has been avoided in the last few RCS releases. From info-cvs-request@prep.ai.mit.edu Mon Apr 24 11:25:35 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA05673 for ; Mon, 24 Apr 1995 11:25:32 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14444; Mon, 24 Apr 95 08:22:50 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA24288; Mon, 24 Apr 1995 10:22:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08934; Mon, 24 Apr 1995 09:14:18 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08929; Mon, 24 Apr 1995 09:14:16 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA23725; Mon, 24 Apr 1995 10:14:14 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA12414; Mon, 24 Apr 95 08:14:12 PDT Received: from trout.sri.MT.net by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA14448; Mon, 24 Apr 95 11:13:56 EDT Received: (from nate@localhost) by trout.sri.MT.net (8.6.11/8.6.11) id JAA04432; Mon, 24 Apr 1995 09:13:08 -0600 Date: Mon, 24 Apr 1995 09:13:08 -0600 From: Nate Williams Message-Id: <199504241513.JAA04432@trout.sri.MT.net> In-Reply-To: joe.gorman@delab.sintef.no "Removing directories" (Apr 24, 10:26am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: joe.gorman@delab.sintef.no, info-cvs@prep.ai.mit.edu Subject: Re: Removing directories Content-Length: 1259 Status: RO > One of the nice things about CVS is that it keep track of which files > belong to which versions of the system. This seems to me rather > important, as adding/deleting files is a typcial operation as systems > evolve. > > However, the same applies to DIRECTORIES: these are also added/removed as > systems evolve. CVS appears to work OK for adding directories, but does > not seem to understand that I might also want to REMOVE directories > sometimes too. CVS does remove directories *IF* they are empty and the '-P' option is given. My question is why isn't the -P option the default? Would anyone be upset if -P became the default, since most folks I know would prefer to see empty directories go away. What we've done for cases where we've needed 'empty' directories is add the file .keep_me in the directory, which makes the directory have at least one file so it's created. > PS: Another, minor related issue: when "cvs add" is used to add new > directories these are not made avaialble to other users by "cvs checkout" > UNLESS they use the "-d" option. Would it not be more sensible and > convenient if "-d" were the default? What say the CVS maintainers? Could '-d' be the default if the developer is working on the main branch? Nate From info-cvs-request@prep.ai.mit.edu Mon Apr 24 11:11:20 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA12217 for ; Mon, 24 Apr 1995 11:11:19 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA11248; Mon, 24 Apr 95 08:07:52 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA23295; Mon, 24 Apr 1995 10:07:40 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08226; Mon, 24 Apr 1995 09:00:53 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08220; Mon, 24 Apr 1995 09:00:51 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA22671; Mon, 24 Apr 1995 10:00:49 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA09459; Mon, 24 Apr 95 08:00:48 PDT Received: from relay3.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13777; Mon, 24 Apr 95 11:00:45 EDT Received: from cygnus.com by relay3.UU.NET with ESMTP id QQymwa14553; Mon, 24 Apr 1995 11:00:44 -0400 Received: from lioth.cygnus.com (lioth.cygnus.com [198.6.99.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id IAA09947 for ; Mon, 24 Apr 1995 08:00:40 -0700 From: Jim Kingdon Received: from localhost (kingdon@localhost) by lioth.cygnus.com (8.6.4/8.6.4) id LAA10376; Mon, 24 Apr 1995 11:00:26 -0400 Date: Mon, 24 Apr 1995 11:00:26 -0400 Message-Id: <199504241500.LAA10376@lioth.cygnus.com> To: info-cvs@prep.ai.mit.edu In-Reply-To: mahesh@fred.net's message of 24 Apr 1995 07:06:21 -0700 Subject: RFD: comp.software.config-mgmt.cvs Content-Length: 1076 Status: RO REQUEST FOR DISCUSSION Until this appears in news.announce.newgroups, there is no "official" discussion. In that light, carefully note the following section of "The Usenet Newsgroup Creation Companion". For the RFD I'm not sure it is a big deal, but for the CFV it must appear in news.announce.newgroups before being sent to info-cvs. Q: How should the CFV be sent to a mailing list? A: First, use the full disclosure tactic. Let the votetaker know which mailing lists the CFV should go to, so he can note them in the CFV as required. Either the votetaker or the proponent can do the actual mailing, but make sure it is done _only_ after the official CFV has appeared in news.announce.newgroups, and that the CFV posted to the mailing list is the one which appears in news.announce.newgroups, or the votes received will be invalid. Q: What's the big deal about mailing lists? A: One of the best ways to get your vote canceled is to send the CFV to a mailing list without following the above procedures. Disclose in advance! From info-cvs-request@prep.ai.mit.edu Sun Apr 23 23:25:33 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA32246 for ; Sun, 23 Apr 1995 23:25:27 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29978; Sun, 23 Apr 95 20:21:41 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA10377; Sun, 23 Apr 1995 22:21:34 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19174; Sun, 23 Apr 1995 21:09:38 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19169; Sun, 23 Apr 1995 21:09:37 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA10242; Sun, 23 Apr 1995 22:09:36 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA29311; Sun, 23 Apr 95 20:09:33 PDT Received: from zazu.c3.lanl.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA22235; Sun, 23 Apr 95 23:09:30 EDT Received: (krk@localhost) by zazu.c3.lanl.gov (8.6.10/c93112801) id VAA00281; Sun, 23 Apr 1995 21:09:22 -0600 Date: Sun, 23 Apr 1995 21:09:22 -0600 From: Kenneth R Koch Message-Id: <199504240309.VAA00281@zazu.c3.lanl.gov> To: edwards@cartel.atmos.colostate.edu, info-cvs@ai.mit.edu Subject: Re: cvs rtag -F trouble Content-Length: 1187 Status: RO Jim Edwards writes: > I am working on a branch tagged rams3a in a repository called rams. > > I added a file on the trunk that I want to use with this branch. > > So my working repository is all taged rams3a except for one Makefile > which has no tags - I want to add the current branch tag to that > Makefile. > > so in the directory the Makefile is in I did > > cvs tag rams3a Makefile > cvs update -r rams3a Makefile > > the tried to commit - this gave me an error that rams3a is not a > branch tag. > > so thinking I could solve this problem easily i did > > cvs rtag -b -F rams3a Makefile rams > > which moved the tag on my entire repository to the latest version on the > trunk - THIS IS NOT WHAT I INTENDED - any ideas on how to get my tag > back to the right place? > > I misread the instructions for rtag, would the following have done > what I expected? > > cvs rtag -b -F rams3a rams/van/Makefile Got a backup? :-( Otherwise I think you will have to manually list/identify all numerical branch ids on all files, then guess which were the rams3a branch via the log text, and then recreate the branch on a file-by-file basis. Ken Koch Los Alamos National Laboratory From listspice@spice.crim.ca Sat Apr 22 14:24:32 1995 Received: from chan.crim.ca (chan.crim.ca [132.218.1.4]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA26086 for ; Sat, 22 Apr 1995 14:24:30 -0400 Received: from spice.crim.ca.crim.ca by chan.crim.ca (4.1/SMI-4.1) id AA08801; Sat, 22 Apr 95 14:18:16 EDT Errors-To: dstpierr@garrison.crim.ca Received: by spice.crim.ca.crim.ca (4.1/SMI-4.1) id AA05286; Sat, 22 Apr 95 14:13:31 EDT Errors-To: dstpierr@crim.ca Received: from chan.crim.ca by spice.crim.ca.crim.ca (4.1/SMI-4.1) id AA05279; Sat, 22 Apr 95 14:12:44 EDT Received: from garrison.crim.ca by chan.crim.ca (4.1/SMI-4.1) id AA08793; Sat, 22 Apr 95 14:15:19 EDT Received: by garrison.crim.ca (4.1/SMI-4.1) id AA28729; Sat, 22 Apr 95 14:15:19 EDT Date: Sat, 22 Apr 95 14:15:19 EDT From: dstpierr@crim.ca (Denis St-Pierre) Message-Id: <9504221815.AA28729@garrison.crim.ca> To: function.point.list@crim.ca Subject: RE: Serge Oligny from Mark Shocklee Approved: dstpierr@crim.ca Precedence: list Errors-To: dstpierr@crim.ca X-Sequence: 21 Status: RO I just joined the mailing list yesterday, and all the literature that I have read suggest that I should observe for a while before posting any comments, however I do have some ideas on some other sources for information beyond Capers-Jones. The Australian Software Metrics Association (ASMA) is compiling productivity (HR/FP) and defect information. An abstract containing summary information ("Software Benchmarking on a Global Basis" by Andrew Burg, Paula Jamieson, and Dr. Michael Schooneveldt) was presented at the last International Function Point Users Group (IFPUG). Their information is updated every six months in June and December. You can contact them at: P. O. Box 1287 Box Hill VIC Australia 3128 Phone: (03) 890-5988 The International Function Point Users Group is scheduled to be producing some benchmarking information this month. A hardcopy of the data will be available to purchase and a the summary of this data will be available on IFPUG Online, their BBS system. You or your organization must be a member of IFPUG and you must obtain access to the BBS. You can contact IFPUG at: Blendonview Office Park 5008-28 Pine Creek Drive Westerville, OH USA 43081-4899 Phone: (614) 895-7130 The "Software Benchmarking on a Global Basis" presentation also mentions an effort by the International Software Benchmarking Standards Group. This group was scheduled to release benchmarking information on February, 1995. That presentation did provide a contact name for this group, but did not give any address or phone number for the group. I hope that this will help. >Hello ! > >I joined this list recently therefore I might be asking a FAQ. >If it is so, please point me to the appropriate archive site. > >Having completed the development of a large application, I am in >the process of assessing the productivity of the development efforts. > >I am specifically looking for industry references on the topic >beyond the obvious "Applied Software Measurements" from C. Jones. > >More specifically I would appreciate references on: > > . average effort per FP, > . average (min..max) costs per FP, > . average number of defects per FP > >References where such informations would be characterized according >to application overall size, technology used, organization general >profile would be prefered. > >This request was posted, a few weeks ago, on newsnet "comp.software-eng" >with not much more than references to the book cited above as an answer. >Although this book is a good starting point, it was published in 1991. >I wish to compare to a more recent basis. > >Your help is appreciated. > >Serge Oligny >(soligny@mais.hydro.qc.ca) From info-cvs-request@prep.ai.mit.edu Sat Apr 22 09:27:02 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA13444 for ; Sat, 22 Apr 1995 09:27:01 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25526; Sat, 22 Apr 95 06:23:45 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA10412; Sat, 22 Apr 1995 08:23:36 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA22051; Sat, 22 Apr 1995 07:13:14 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA22046; Sat, 22 Apr 1995 07:13:12 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA09302; Sat, 22 Apr 1995 08:13:11 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA25143; Sat, 22 Apr 95 06:13:09 PDT Received: from relay2.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA01017; Sat, 22 Apr 95 08:35:37 EDT Received: from cygnus.com by relay2.UU.NET with ESMTP id QQymog16862; Sat, 22 Apr 1995 08:35:36 -0400 Received: from lioth.cygnus.com (lioth.cygnus.com [198.6.99.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id FAA28779; Sat, 22 Apr 1995 05:35:28 -0700 From: Jim Kingdon Received: from localhost (kingdon@localhost) by lioth.cygnus.com (8.6.4/8.6.4) id IAA06277; Sat, 22 Apr 1995 08:35:18 -0400 Date: Sat, 22 Apr 1995 08:35:18 -0400 Message-Id: <199504221235.IAA06277@lioth.cygnus.com> To: info-cvs@prep.ai.mit.edu In-Reply-To: kalpana@mcnc.org's message of 21 Apr 1995 22:13:00 -0700 Subject: adds Content-Length: 235 Status: RO (1) cvs remove x.c (2) cvs commit (3) vi x.c (4) cvs add x.c This is another case which is broken in versions of CVS without the "death support" patches, such as 1.3 and 1.4A2. CCVS has death support and I recommend it. From info-cvs-request@prep.ai.mit.edu Fri Apr 21 04:34:27 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA05346 for ; Fri, 21 Apr 1995 04:34:26 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27895; Fri, 21 Apr 95 01:19:03 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA00235; Fri, 21 Apr 1995 03:18:56 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA11087; Fri, 21 Apr 1995 01:02:18 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA11083; Fri, 21 Apr 1995 01:02:17 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA29375; Fri, 21 Apr 1995 02:02:15 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA21601; Fri, 21 Apr 95 00:02:12 PDT Received: from staff.cs.su.OZ.AU by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA21938; Fri, 21 Apr 95 03:02:06 EDT Received: from gecms.com.au by staff.cs.su.OZ.AU (mail from mxdani for info-cvs@prep.ai.mit.edu) with MHSnet (insertion MHSnet site: sparc2.mecae.gecms.com.au); Fri, 21 Apr 1995 17:02:03 +1000 Received: from smtp-msmail by com.au (4.1/SMI-4.1) id AA11099; Fri, 21 Apr 95 16:54:51 EST Received: by smtp-msmail with Microsoft Mail id <2F98480B@smtp-msmail>; Fri, 21 Apr 95 17:04:27 PDT From: Daniel Matthew * To: Cvs Subject: What Have I done Date: Fri, 21 Apr 95 17:03:00 PDT Message-Id: <2F98480B@smtp-msmail> Encoding: 31 TEXT X-Mailer: Microsoft Mail V3.0 Content-Length: 980 Status: RO Sorry I was just getting assistance of someone and I released that my message was a rambling mess :-( let me try again I Checked out ver1.2 the file had contained Hello World another developer committed there version which then went to 1.3 the file contained Hi World I changed the file to G'Day World then went to do a commit I was informed the file was out of date (which is what I expected) so i did a cvs update file the output was that it did a merge not a conflict!! when I looked at my file it said Hi World There was not another copy of the file with the conflict marked ??? I had lost my changes !! and now had ver 1.3 for my working file I am using CVS 1.3 and RCS 5.6.1 I only have an email. I got the software of a cd that come with a UNIX book I hope this mail makes more sense than the last Thanks Matt.D email mxdani@gecms.com.au :-) From info-cvs-request@prep.ai.mit.edu Sat Apr 22 01:20:04 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id BAA14813 for ; Sat, 22 Apr 1995 01:20:02 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29516; Fri, 21 Apr 95 22:15:33 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20328; Sat, 22 Apr 1995 00:15:26 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10134; Fri, 21 Apr 1995 16:07:57 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10130; Fri, 21 Apr 1995 16:07:55 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA06252; Fri, 21 Apr 1995 17:07:53 -0500 Received: from life.ai.mit.edu ([128.52.32.80]) by Sun.COM (sun-barr.Sun.COM) id AA28379; Fri, 21 Apr 95 15:04:31 PDT Received: from cartel.atmos.colostate.edu by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA04216; Fri, 21 Apr 95 18:02:55 EDT Received: by cartel.atmos.colostate.edu (AIX 3.2/UCB 5.64/4.03.910717) id AA15255; Fri, 21 Apr 1995 16:02:35 -0600 Date: Fri, 21 Apr 1995 16:02:35 -0600 From: edwards@cartel.atmos.colostate.edu (Jim Edwards) Message-Id: <9504212202.AA15255@cartel.atmos.colostate.edu> To: info-cvs@ai.mit.edu Subject: cvs rtag -F trouble Forwarding: Mail from 'MAILER-DAEMON@ai.mit.edu (Mail Delivery Subsystem)' dated: Fri, 21 Apr 95 18:01:31 EDT Content-Length: 904 Status: RO Hello all, I am working on a branch tagged rams3a in a repository called rams. I added a file on the trunk that I want to use with this branch. So my working repository is all taged rams3a except for one Makefile which has no tags - I want to add the current branch tag to that Makefile. so in the directory the Makefile is in I did cvs tag rams3a Makefile cvs update -r rams3a Makefile the tried to commit - this gave me an error that rams3a is not a branch tag. so thinking I could solve this problem easily i did cvs rtag -b -F rams3a Makefile rams which moved the tag on my entire repository to the latest version on the trunk - THIS IS NOT WHAT I INTENDED - any ideas on how to get my tag back to the right place? I misread the instructions for rtag, would the following have done what I expected? cvs rtag -b -F rams3a rams/van/Makefile Jim Edwards edwards@cartel.atmos.colostate.edu From info-cvs-request@prep.ai.mit.edu Sat Apr 22 01:19:55 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id BAA05672 for ; Sat, 22 Apr 1995 01:19:54 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29167; Fri, 21 Apr 95 22:11:05 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA19782; Sat, 22 Apr 1995 00:10:58 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04887; Fri, 21 Apr 1995 14:10:02 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04883; Fri, 21 Apr 1995 14:10:00 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA23737; Fri, 21 Apr 1995 15:09:58 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA07865; Fri, 21 Apr 95 13:09:31 PDT Received: from robin.mcnc.org.mcnc.org by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA27143; Fri, 21 Apr 95 16:09:21 EDT Received: by robin.mcnc.org.mcnc.org (8.6.9/MCNC/8-10-92) id QAA15575; Fri, 21 Apr 1995 16:09:18 -0400 for info-cvs@prep.ai.mit.edu Date: Fri, 21 Apr 1995 16:09:18 -0400 From: Kalpana Krishnaswami Message-Id: <199504212009.QAA15575@robin.mcnc.org.mcnc.org> To: info-cvs@prep.ai.mit.edu Subject: adds Content-Length: 449 Status: RO I am using CVS 1.3 and ran into the following problem while executing the following sequence of commands (1) cvs remove x.c (2) cvs commit (3) vi x.c (4) cvs add x.c when I do a remove followed by a commit it places x.c in the attic. So when I try to add it back it looks in the attic and complains that the file is in the attic. I can only add back it if I manually remove the file from the attic. Any suggestions? From info-cvs-request@prep.ai.mit.edu Thu Apr 20 19:40:22 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA01307 for ; Thu, 20 Apr 1995 19:40:17 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA04051; Thu, 20 Apr 95 16:36:02 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA21802; Thu, 20 Apr 1995 18:35:50 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04645; Thu, 20 Apr 1995 17:29:13 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04641; Thu, 20 Apr 1995 17:29:11 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA21585; Thu, 20 Apr 1995 18:29:09 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA03001; Thu, 20 Apr 95 16:29:08 PDT Received: from staff.cs.su.OZ.AU by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA05087; Thu, 20 Apr 95 19:29:03 EDT Received: from gecms.com.au by staff.cs.su.OZ.AU (mail from mxdani for info-cvs@prep.ai.mit.edu) with MHSnet (insertion MHSnet site: sparc2.mecae.gecms.com.au); Fri, 21 Apr 1995 09:29:00 +1000 Received: from smtp-msmail by com.au (4.1/SMI-4.1) id AA08240; Fri, 21 Apr 95 09:21:17 EST Received: by smtp-msmail with Microsoft Mail id <2F97DD9E@smtp-msmail>; Fri, 21 Apr 95 09:30:22 PDT From: Daniel Matthew * To: Cvs Subject: What Have I Done ! Date: Fri, 21 Apr 95 09:30:00 PDT Message-Id: <2F97DD9E@smtp-msmail> Return-Receipt-To: Encoding: 25 TEXT X-Mailer: Microsoft Mail V3.0 Content-Length: 932 Status: RO I have just installed CVS and was testing it out. I created a couple of files added them to the repository etc.. My problem is that when I do a update (knowing that the repository is different) it will override my working view and say it is merged. Not identify the conflict. I had the "Hello World" scenario the working view I changed to "Hi World" went to do a commit was told that the version I had was out of date (the working view ver 1.3 the repository 1.4) so I did a commit and it told me it merged, not that there was a conflict ?? When I looked at the file it had just over written the working view ! Then I tried a different scenario the file in the repository had an extra line. I added a extra line in the working file. Then did the merge and it did merge the files. the copy in the working view had both new lines added. Totally Confused (no idea what I have done wrong) Matt.D :-) mxdani@gecms.com.au From info-cvs-request@prep.ai.mit.edu Sat Apr 22 01:19:55 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id BAA14826 for ; Sat, 22 Apr 1995 01:19:53 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29333; Fri, 21 Apr 95 22:13:15 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20037; Sat, 22 Apr 1995 00:13:07 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA05714; Fri, 21 Apr 1995 14:24:50 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA05710; Fri, 21 Apr 1995 14:24:45 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA26965; Fri, 21 Apr 1995 15:24:40 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA11148; Fri, 21 Apr 95 13:23:31 PDT Received: from astro.Princeton.EDU by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA09797; Fri, 21 Apr 95 11:45:08 EDT Received: (from rhl@localhost) by astro.Princeton.EDU (8.6.12/8.6.12) id LAA19880; Fri, 21 Apr 1995 11:37:19 -0400 Date: Fri, 21 Apr 1995 11:37:19 -0400 From: Robert Lupton the Good Message-Id: <199504211537.LAA19880@astro.Princeton.EDU> To: info-cvs@prep.ai.mit.edu, nomann@groucho.dbc.bib.dk Subject: Re: The shape of release-tags Content-Length: 745 Status: RO From info-cvs-request@prep.ai.mit.edu Fri Apr 21 10:54 EDT 1995 Date: Fri, 21 Apr 1995 16:30:55 +0200 From: nomann@groucho.dbc.bib.dk (Ole Nomann Thomsen) To: info-cvs@prep.ai.mit.edu Subject: The shape of release-tags * Is it possible to get a keyword expansion (sort of like rcs $Revision$ -> $Revision: 1.4$) but with the expansion inserting a tag? This can nearly, but not quite, be done. The latest version of RCS supports $Name$ to expand to a symbolic name (which is how cvs handles tags). The problem is that it's only expanded if the revision is asked for by symbolic name, and cvs doesn't do this. I filed a bug report on this, and a partial patch, when 1.4 came out, but haven't heard anything back. Robert From info-cvs-request@prep.ai.mit.edu Fri Apr 21 12:09:23 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA27134 for ; Fri, 21 Apr 1995 12:09:22 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA15351; Fri, 21 Apr 95 08:57:56 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA11184; Fri, 21 Apr 1995 10:57:41 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA22941; Fri, 21 Apr 1995 09:39:43 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA22936; Fri, 21 Apr 1995 09:39:41 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA10239; Fri, 21 Apr 1995 10:39:39 -0500 Received: from life.ai.mit.edu ([128.52.32.80]) by Sun.COM (sun-barr.Sun.COM) id AA11135; Fri, 21 Apr 95 08:39:31 PDT Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA09568; Fri, 21 Apr 95 11:37:31 EDT Received: from monad.armadillo.com (monad.armadillo.com [199.199.0.1]) by monad.armadillo.com (8.6.11/8.6.11) with ESMTP id KAA13117; Fri, 21 Apr 1995 10:37:18 -0500 Message-Id: <199504211537.KAA13117@monad.armadillo.com> From: "david d `zoo' zuhn" Organization: armadillo zoo software -- +1 500 DOS BITES (really) To: nomann@groucho.dbc.bib.dk (Ole Nomann Thomsen) Cc: info-cvs@prep.ai.mit.edu Subject: Re: The shape of release-tags In-Reply-To: Your message of "Fri, 21 Apr 1995 16:30:55 +0200." <9504211430.AA36938@groucho.dbc.bib.dk> X-Punishment: I will not sleep through my education Date: Fri, 21 Apr 1995 10:37:08 -0500 Sender: zoo@armadillo.com Content-Length: 664 Status: RO // * Is there a way to tag releases (not revisions) like 1.4, 1.5 ...? // (And if there isn't: How come CVS itself is release 1.4 and not // R1_4? Am i supposed rename manually?) No. You cannot put . into tag names. It's an RCS limitation. And you are supposed to translate manually. I use - instead of ., not _, but it doesn't really matter much. CVS uses dot in release names since it's a natural thing to do. // * Is it possible to get a keyword expansion (sort of like rcs // $Revision$ -> $Revision: 1.4$) but with the expansion inserting a // tag? The latest RCS betas support something like this. but it doesn't yet work with CVS. From info-cvs-request@prep.ai.mit.edu Fri Apr 21 10:55:27 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA21452 for ; Fri, 21 Apr 1995 10:55:22 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00586; Fri, 21 Apr 95 07:42:49 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA06852; Fri, 21 Apr 1995 09:42:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA20148; Fri, 21 Apr 1995 08:27:32 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA20144; Fri, 21 Apr 1995 08:27:30 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA06021; Fri, 21 Apr 1995 09:27:28 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA28836; Fri, 21 Apr 95 07:27:27 PDT Received: from find2.denet.dk by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA05601; Fri, 21 Apr 95 10:27:14 EDT Received: from groucho.dbc.bib.dk (groucho.dbc.bib.dk [130.225.234.4]) by find2.denet.dk (8.6.4/8.6) with SMTP id QAA08140 for ; Fri, 21 Apr 1995 16:27:52 +0200 Received: by groucho.dbc.bib.dk (AIX 3.2/UCB 5.64/4.03) id AA36938; Fri, 21 Apr 1995 16:30:55 +0200 Date: Fri, 21 Apr 1995 16:30:55 +0200 From: nomann@groucho.dbc.bib.dk (Ole Nomann Thomsen) Message-Id: <9504211430.AA36938@groucho.dbc.bib.dk> To: info-cvs@prep.ai.mit.edu Subject: The shape of release-tags Content-Length: 703 Status: RO Hi, I'm new to CVS (feeling slightly out-of-place) and have these questions: I am incorporating my dir of sourcefiles into CVS. These files build a program, that have manually been named as release 1.4, and I would like to keep that release-tag. I can't use "cvs tag" or "cvs rtag" since they impose a syntax on the tags which will only let me use something like R1_4. * Is there a way to tag releases (not revisions) like 1.4, 1.5 ...? (And if there isn't: How come CVS itself is release 1.4 and not R1_4? Am i supposed rename manually?) * Is it possible to get a keyword expansion (sort of like rcs $Revision$ -> $Revision: 1.4$) but with the expansion inserting a tag? - Ole N. Thomsen From info-cvs-request@prep.ai.mit.edu Wed Apr 26 01:20:33 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id BAA19407 for ; Wed, 26 Apr 1995 01:20:31 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12756; Tue, 25 Apr 95 22:13:59 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20121; Wed, 26 Apr 1995 00:13:48 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06369; Tue, 25 Apr 1995 23:01:29 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06365; Tue, 25 Apr 1995 23:01:27 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA18726; Wed, 26 Apr 1995 00:01:25 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA11550; Tue, 25 Apr 95 22:01:16 PDT Received: from cpdsc.com (sun001.cpdsc.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA07601; Fri, 21 Apr 95 11:05:33 EDT Received: from sun004.cpdsc.com by cpdsc.com (4.1/SMI-4.1) id AA09263; Fri, 21 Apr 95 10:04:46 CDT Received: from sun174.CPDSC by sun004.cpdsc.com (4.1/SMI-4.1) id AA00708; Fri, 21 Apr 95 10:05:35 CDT From: dwood@sun004.cpdsc.com (R. H. Wood) Message-Id: <9504211505.AA00708@sun004.cpdsc.com> Subject: Re: What Have I Done ! To: mxdani@gecms.com.au (Daniel Matthew *) Date: Fri, 21 Apr 1995 10:06:27 -0500 (CDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <2F97DD9E@smtp-msmail> from "Daniel Matthew *" at Apr 21, 95 09:30:00 am Reply-To: dwood@sun004.cpdsc.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2204 Status: RO In a recent message from cyberspace, Daniel Matthew * said: > > > I have just installed CVS and was testing it out. It would be helpful if you tell us which version of CVS you installed. My responses here are relative to version CVS-1.4A2, though it's not officially released yet. > I created a couple of files added them to the repository etc.. > My problem is that when I do a update (knowing that the repository is > different) it will override my working view and say it is merged. Not > identify the conflict. Unless you've changed the copy in your local view, it's supposed to overwrite it with the repository version. If you've not changed the local file, then there is no conflict as far as cvs is concerned. It just "synch's up" your local tree with the current revisions in the repository. > > I had the "Hello World" scenario the working view I changed to "Hi World" > went to do a commit was told that the version I had was out of date (the > working view ver 1.3 the repository 1.4) so I did a commit and it told me (you meant to say "update" here, didn't you?.....^^^^^ ?) > it merged, not that there was a conflict ?? It's not supposed to think there's a conflict unless there are differences in the same lines of text between the locally modified working copy and the repository version; it's supposed to just merge the two. This leads to the question: what version of diff (gnu diff?) are you using? > > When I looked at the file it had just over written the working view ! > > Then I tried a different scenario the file in the repository had an extra > line. I added a extra line in the working file. Then did the merge and it > did merge the files. > > the copy in the working view had both new lines added. > > Totally Confused (no idea what I have done wrong) > > Matt.D :-) > > mxdani@gecms.com.au > Sounds like resolving the version of diff you/cvs are/is using may go a long way in resolving your confusion. -dick -- _________________________________________________________________________ R. H. Wood -- dwood@bpd.dsccc.com or rhw@woodwrk.pic.net +1-214-519-5758 DSC Communications Corporation, MS ATMS1, 1000 Coit Road, Plano,TX 75075 From info-cvs-request@prep.ai.mit.edu Fri Apr 21 00:09:57 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id AAA31590 for ; Fri, 21 Apr 1995 00:09:52 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05550; Thu, 20 Apr 95 20:56:49 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA26848; Thu, 20 Apr 1995 22:56:41 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA05461; Thu, 20 Apr 1995 21:42:12 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA05457; Thu, 20 Apr 1995 21:42:11 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA26758; Thu, 20 Apr 1995 22:42:09 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA04464; Thu, 20 Apr 95 20:42:08 PDT Received: from relay3.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA17649; Thu, 20 Apr 95 23:42:00 EDT Received: from cygnus.com by relay3.UU.NET with ESMTP id QQymje03002; Thu, 20 Apr 1995 23:41:55 -0400 Received: from lioth.cygnus.com (lioth.cygnus.com [198.6.99.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id UAA25007; Thu, 20 Apr 1995 20:41:51 -0700 From: Jim Kingdon Received: from localhost (kingdon@localhost) by lioth.cygnus.com (8.6.4/8.6.4) id XAA05896; Thu, 20 Apr 1995 23:41:45 -0400 Date: Thu, 20 Apr 1995 23:41:45 -0400 Message-Id: <199504210341.XAA05896@lioth.cygnus.com> To: info-cvs@prep.ai.mit.edu In-Reply-To: dwood@sun004.cpdsc.com's message of 20 Apr 1995 14:53:04 -0700 Subject: Promoting 'adds' to a branch to the Main Trunk Content-Length: 453 Status: RO I find 1.4A2 now adds files to a branch by placing them in the Attic. Getting proper handling of files which are added on a branch, and other similar cases, are the purpose of the "death support" patches. The latest version of death support, unlike previous versions, does not require patches to RCS. The best way to get a CVS with death support is to get Cyclic CVS--for more information on Cyclic CVS see ftp://ftp.cyclic.com/pub/cvs/mini-FAQ. From info-cvs-request@prep.ai.mit.edu Thu Apr 20 18:07:05 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA01108 for ; Thu, 20 Apr 1995 18:05:02 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14402; Thu, 20 Apr 95 14:57:53 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA12447; Thu, 20 Apr 1995 16:56:09 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27062; Thu, 20 Apr 1995 15:34:26 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27057; Thu, 20 Apr 1995 15:34:25 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA10154; Thu, 20 Apr 1995 16:34:20 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA10416; Thu, 20 Apr 95 14:34:17 PDT Received: from cpdsc.com (sun001.cpdsc.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA28789; Thu, 20 Apr 95 17:33:43 EDT Received: from sun004.cpdsc.com by cpdsc.com (4.1/SMI-4.1) id AA06459; Thu, 20 Apr 95 16:30:40 CDT Received: from sun174.CPDSC by sun004.cpdsc.com (4.1/SMI-4.1) id AA29775; Thu, 20 Apr 95 16:31:21 CDT From: dwood@sun004.cpdsc.com (R. H. Wood) Message-Id: <9504202131.AA29775@sun004.cpdsc.com> Subject: Promoting 'adds' to a branch to the Main Trunk To: info-cvs@prep.ai.mit.edu Date: Thu, 20 Apr 1995 16:32:14 -0500 (CDT) Cc: rhw@woodwrk.pic.net Reply-To: dwood@sun004.cpdsc.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1910 Status: RO I know this has been asked before, but I'm finding references in the FAQ that appear to be stated from a pre-1.4A2 perspective. I find 1.4A2 now adds files to a branch by placing them in the Attic. I want to know how I'm supposed to (within the cvs 'philosophy', that is) later get that new file merged into the main trunk. Is there a new FAQ segment on this that I've just missed? What I've done in the passed is written a kludge script to handle adds like I think they ought to be handled. But reading the faq, I see I don't seem to think the way the CVS designers thought when they put the additions on the attic. My script moves the new candidate addition to the side, temporarily, and creates an empty file of the same name, which gets added to the main trunk. It then puts the real file back in place and does an add of it (queueing it for subsequent commit to the actual branch). This gives the impression the file was on the trunk all along, but it (the trunk copy) remains empty until the branch copy is merged into the main-line trunk (presumably after it's passed verification/testing criteria). What I really want to do is something like cvs co module #get the main trunk cvs update -j module and have those new files be on the main trunk when the merge finishes. But since they're in the attic, CVS 1.4A2 is "Segmentation fault"ing here on my sun platform at work (and also on my NetBSD at home). So, have I missed something? Is this something on somebody's TODO list? Is it fixed in some yet-to-be-released version? Or is this (my scenario, that is) just not supposed to be the way it works in 'CVS'? -dick -- _________________________________________________________________________ R. H. Wood -- dwood@bpd.dsccc.com or rhw@woodwrk.pic.net +1-214-519-5758 DSC Communications Corporation, MS ATMS1, 1000 Coit Road, Plano,TX 75075 From info-cvs-request@prep.ai.mit.edu Thu Apr 20 14:13:11 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA10305 for ; Thu, 20 Apr 1995 14:13:09 -0400 Received: from Sun.COM by ulowell.uml.edu with SMTP id AA07385 (5.67b/IDA-1.5 for ); Thu, 20 Apr 1995 14:13:06 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21885; Thu, 20 Apr 95 10:38:12 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA16656; Thu, 20 Apr 1995 12:37:41 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14648; Thu, 20 Apr 1995 11:27:10 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14643; Thu, 20 Apr 1995 11:27:08 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA15612; Thu, 20 Apr 1995 12:27:06 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA18754; Thu, 20 Apr 95 10:24:56 PDT Received: from blackhole.cae.ca (CAE.CA) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12126; Thu, 20 Apr 95 13:23:39 EDT Received: (from uucp@localhost) by blackhole.cae.ca (8.6.7/8.6.6) id NAA20232 for ; Thu, 20 Apr 1995 13:25:17 -0400 Received: from poster.cae.ca(142.39.20.1) by bhole via smap (V1.3mjr) id sma020199; Thu Apr 20 13:24:16 1995 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA15934; Thu, 20 Apr 1995 13:21:49 -0400 Received: by eagle.cae.ca (931110.SGI/930416.SGI.AUTO) for @poster.cae.ca:info-cvs@prep.ai.mit.edu id AA06461; Thu, 20 Apr 95 13:17:59 -0400 From: "Lim Fung Peng" Message-Id: <9504201317.ZM6459@eagle.cae.ca> Date: Thu, 20 Apr 1995 13:17:54 -0400 In-Reply-To: "david d `zoo' zuhn" "Re: cvs msg:cannot find own username, ???" (Apr 19, 3:37pm) References: <199504192037.PAA02041@monad.armadillo.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: zoo@armadillo.com Subject: Re: cvs msg:cannot find own username, ??? Cc: info-cvs@prep.ai.mit.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 1490 Status: RO On Apr 19, 3:37pm, david d `zoo' zuhn wrote: > Subject: Re: cvs msg:cannot find own username, ??? > // I've done "cvs import" on a couple of our project directories. However > // when I try doing "cvs checkout ", I keep getting this error message... > // > // >cvs checkout: cannot find own username > // > // and then the checkout command goes on until completion without any other > // problems. > // > // Is it because my username is not in the access list? If so, how do I > // tell cvs to put me on the access list? > > This shouldn't be it, unless you put RCS files directly into the repository > instead of using CVS to populate it. > > It's a problem somewhere in the history loggingm, in that it cannot find > your userid in the password file. > > If you don't care about history logging, remove $CVSROOT/CVSROOT/history > and you won't get this message anymore. >-- End of excerpt from david d `zoo' zuhn I've checked the passwd file. You were right. My userid is not there. The reason for this is because we are using "automount" and "yp" on our system. Therefore I do not have an entry on my local machine's passwd file but I have an entry in the ypserver machine's passwd file. Since I'm new to CVS I would like be able to trace my work session using the history log. Therefore removing the history file is not desired. Would it then be possible to redirect CVS to read from a remote passwd file? Has anyone a work-around on a similar problem? Thanks again. From cmclain Thu Apr 20 10:28:55 1995 Received: (from cmclain@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id KAA05610; Thu, 20 Apr 1995 10:28:54 -0400 From: Cynthia McLain Message-Id: <199504201428.KAA05610@jupiter.cs.uml.edu> Subject: Re: case/95s523/95sbde/bde/src release -d To: lechner@cs.uml.edu (Bob Lechner) Date: Thu, 20 Apr 1995 10:28:54 -0400 (EDT) Cc: cmclain@cs.uml.edu, lechner@cs.uml.edu, cgopal@cs.uml.edu In-Reply-To: <199504200411.AAA19094@remus.cs.uml.edu> from "Bob Lechner" at Apr 20, 95 00:11:43 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 784 Status: RO > > Cindy McLain suggested 'cvs release -d bde' > after I used cvs rtag in the public > 95sbde/bde tree node to create the bdelog branchpoint. However, > I feared that cvs will delete all the files at each node, not just > the ones checked out from the repository. The others are aareadme > and testlog and statistics files that I created at various nodes. > > You're right about that. I assumed that you had started from a clean directory tree and not done any editing in those directories. (Hopefully you had the stable version of the files checked out when you made the initial tag.) I think you may be able to do a "cvs co -r bde95sbase bde" at the root of your workspace and get everything updated. You may want to do "cvs status bde | grep Status" first. --Cindy From info-cvs-request@prep.ai.mit.edu Thu Apr 20 08:52:00 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id IAA19081 for ; Thu, 20 Apr 1995 08:51:59 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00542; Thu, 20 Apr 95 05:51:10 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA18714; Thu, 20 Apr 1995 07:51:06 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02295; Thu, 20 Apr 1995 06:47:24 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02291; Thu, 20 Apr 1995 06:47:23 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA18414; Thu, 20 Apr 1995 07:47:20 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA00175; Thu, 20 Apr 95 05:47:17 PDT Received: from slsa02t.stgl.netd.alcatel.de by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA26082; Thu, 20 Apr 95 08:47:11 EDT Received: from slbh01t1.bln.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <18866-0@slsa02t.stgl.netd.alcatel.de>; Thu, 20 Apr 1995 14:28:13 +0200 Received: from slbh04 by bln.sel.alcatel.de (4.1/SMI-4.0/DNI-7.0.1/blume_h-1.2) id AA17690; Thu, 20 Apr 95 14:27:38 +0200 From: Uwe.Graichen@bln.sel.alcatel.de (U. Graichen) Received: by slbh04 (4.1) id AA23774; Thu, 20 Apr 95 14:27:35 +0200 Date: Thu, 20 Apr 95 14:27:35 +0200 Message-Id: <9504201227.AA23774@slbh04> To: info-cvs@prep.ai.mit.edu Subject: version tree script - core dump with perl5 Content-Length: 609 Status: RO Hi, the posted version tree presenting perl script produces a core dump with perl5. I'm not a perl5 hacker and i cannot find the error. Perhaps any other my select the error or the reason of it, please send me a mail. Use perl4 till the error is selected :) or don't use the script :( bye uwe +========= Uwe Graichen / ALCATEL SEL AG Berlin ===================+ Email: graichen@bln.sel.alcatel.de ( Expressed opinions which happen to ) correspond with those of my employer Phone: +49 30 7002 3399 ( are still my own. The others are mine. From info-cvs-request@prep.ai.mit.edu Thu Apr 20 12:55:17 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA24859 for ; Thu, 20 Apr 1995 12:55:08 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA04316; Thu, 20 Apr 95 09:09:25 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA07587; Thu, 20 Apr 1995 11:09:00 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10333; Thu, 20 Apr 1995 10:01:52 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10329; Thu, 20 Apr 1995 10:01:50 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA06683; Thu, 20 Apr 1995 11:01:47 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA02178; Thu, 20 Apr 95 09:01:37 PDT Received: from uu.psi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA07586; Thu, 20 Apr 95 12:01:34 EDT Received: from flash.UUCP by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA03357 for ; Thu, 20 Apr 95 11:47:22 -0400 Received: from hermes by sgc.com (4.1/SMI-4.1) id AA08551; Thu, 20 Apr 95 08:47:59 EDT Received: from aleph_one.sgc.com by hermes (4.1/SMI-4.1) id AA09918; Thu, 20 Apr 95 08:47:52 EDT Date: Thu, 20 Apr 95 08:47:52 EDT From: rsilver@hermes.sgc.com (Russell Silverman) Message-Id: <9504201247.AA09918@hermes> To: info-cvs@prep.ai.mit.edu, graichen@bln.sel.alcatel.de Subject: Re: show the version tree of a CVS managed file Content-Length: 376 Status: RO Why not just use $Header$ in the file instead of $Id$? That will give you absolute path in the file. If this is something more, please specify ? --later, RS -- __o | Russell Adam Silverman | _ o _-\_<, | work - | |<)_/# (*)/'(*) | If you can't change the world, change the channel| TT ; Thu, 20 Apr 1995 10:23:09 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12885; Thu, 20 Apr 95 07:22:32 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA26490; Thu, 20 Apr 1995 09:22:28 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04975; Thu, 20 Apr 1995 08:10:19 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04971; Thu, 20 Apr 1995 08:10:18 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA25242; Thu, 20 Apr 1995 09:10:15 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA11037; Thu, 20 Apr 95 07:10:13 PDT Received: from xenon.daimi.aau.dk by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA29881; Thu, 20 Apr 95 10:10:07 EDT Received: (from lynbech@localhost) by xenon.daimi.aau.dk (8.6.11/8.6.11) id OAA06761; Thu, 20 Apr 1995 14:08:25 GMT Date: Thu, 20 Apr 1995 14:08:25 GMT From: Christian Lynbech Message-Id: <199504201408.OAA06761@xenon.daimi.aau.dk> To: knutson@austin.ibm.com (Jim Knutson) Cc: info-cvs@prep.ai.mit.edu Subject: undoing main branch changes In-Reply-To: <9504192012.AA02882@fliegen.austin.ibm.com> References: <9504192012.AA02882@fliegen.austin.ibm.com> Comments: Hyperbole mail buttons accepted, v3.18.1. Content-Length: 1592 Status: RO >>>>> "Jim" == Jim Knutson writes: Jim> I can't seem to find a way to "undo" main branch changes which don't Jim> need to be merged with the vendor branch anymore. I have seen a couple of suggestions. The first is from the FAQ. The FAQ describes a way to delete a delta by means of `cvs admin'. While it definitely works, I feel uneasy having to do some as destructively and dangerous (as the FAQ points out again and again) on a semiregular basis. Another suggestion is to use the `cvs admin' command to change the default branch of the file in question back to the vendor branch. Unfortunately, I have lost the mail describing the fix, but digging around in the FAQ revealed how it could be done, I think. I have tried it and it seemed to work. If I remember the original mail correctly, recommitting local changes to the file should do the right thing of putting the file back on the main trunk at the next avavilable revision. However, the FAQ states several times that poking around with branches is *very* dangerous, where you risk changing the RCS file in ways that makes it unusable by CVS. Does anybody know to what extent this precise abuse of `cvs admin' is dangerous? ------------------------------------------------------------------------------ Christian Lynbech | Hit the philistines three times over the office: R0.33 (phone: 3217) | head with the Elisp reference manual. email: lynbech@daimi.aau.dk | - petonic@hal.com (Michael A. Petonic) ------------------------------------------------------------------------------ From info-cvs-request@prep.ai.mit.edu Mon Apr 24 20:06:35 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA19323 for ; Mon, 24 Apr 1995 20:06:34 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA08943; Mon, 24 Apr 95 16:50:13 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA23731; Mon, 24 Apr 1995 18:50:06 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18081; Mon, 24 Apr 1995 17:38:15 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18076; Mon, 24 Apr 1995 17:38:13 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA23291; Mon, 24 Apr 1995 18:38:11 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA06481; Mon, 24 Apr 95 16:38:08 PDT Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA16676; Mon, 24 Apr 95 19:38:06 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA12799; Mon, 24 Apr 1995 19:38:02 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA27242; Mon, 24 Apr 95 19:38:01 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id TAA00994; Mon, 24 Apr 1995 19:38:00 -0400 Date: Mon, 24 Apr 1995 19:38:00 -0400 Message-Id: <199504242338.TAA00994@kayak.odi.com> To: kanupan@sag.gmeds.com Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9504242200.AA01805@icad26.Saginaw> (kanupan@sag.gmeds.com) Subject: Re: using sticky_conflict patch under 1.4A2 Reply-To: dgg@odi.com Content-Length: 103 Status: RO > Can one use sticky_conflict patch (from ftp.think.com) > with cvs1.4A2? Isn't it already built in? From info-cvs-request@prep.ai.mit.edu Thu Apr 27 22:26:31 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA10955 for ; Thu, 27 Apr 1995 22:26:28 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10581; Thu, 27 Apr 95 19:24:28 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA11727; Thu, 27 Apr 1995 21:20:50 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08279; Thu, 27 Apr 1995 20:02:42 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08275; Thu, 27 Apr 1995 20:02:40 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA11379; Thu, 27 Apr 1995 21:02:22 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA07645; Thu, 27 Apr 95 19:02:13 PDT Received: from hyper.Franz.COM by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA10239; Thu, 27 Apr 95 22:01:45 EDT Received: from vapor.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA06437; Thu, 27 Apr 95 19:01:19 PDT Received: from localhost by vapor.Franz.COM (4.1/FI-2.0) id AA24622; Thu, 27 Apr 95 19:00:09 PDT Message-Id: <9504280200.AA24622@vapor.Franz.COM> To: info-cvs@prep.ai.mit.edu Subject: CVS 1.3 for NT Date: Thu, 27 Apr 1995 19:00:03 -0700 From: Kevin Layer Content-Length: 1752 Status: RO CVS 1.3 (with RCS 5.6.4 and GNU diff 2.5) "console app" for Windows NT 3.x (tested on 3.5 and 3.51beta) is available for downloading from the following URLs with the names cvs13nt.zip (binary) and cvs13nts.zip (source, requires MSVC++ 2.x): ftp://curly.viewlogic.com/pub/ ftp://ftp.bhs.com/ http://www.bhs.com/application.center/ Below is the `readme.1st' file which appears in each zip file. Kevin Layer layer@Franz.COM http://www.franz.com/ Franz Inc., 1995 University Avenue, Suite 275, Berkeley, CA 94704, USA Phone: (510) 548-3600 FAX: (510) 548-8253 ******************************************************************************* CVS 1.3 RCS 5.6.4 DIFF 2.5 for MS Windows NT 3.5 (Intel) cvs13nt.zip is a binary (console exe's) for NT and cvs13nts.zip contains the sources from which the exe's were built. MSC 8 or 9 can be used, under NT, to build. The CVS sources were derived from previous work by Erik van Linstee. I have made changes to compile with MSC (his version is known to work with Watcom and on OS/2). The RCS and DIFF portions were derived from previous work: ftp.cdrom.com:/pub/cica/nt/gr564s.zip ftp.cdrom.com:/pub/cica/nt/gd25s.zip The binary and source distributions are provided "AS IS" with no WARRANTY whatsoever. To unpack use (in an empty directory is best): pkunzip -d cvs13nt.zip creates bin pkunzip -d cvs13nts.zip creates src To use this version of cvs, you will need to add the following to your environment (Control Panel -> System), where case is unimportant: RCSPATH %d/rcs/%f CVSROOT x:\cvsroot (for example) TZ PST8PDT (for example) and put the `bin' directory mentioned above at the beginning of your PATH. From info-cvs-request@prep.ai.mit.edu Thu Apr 27 20:16:56 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA06003 for ; Thu, 27 Apr 1995 20:16:55 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA23703; Thu, 27 Apr 95 17:14:18 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA08305; Thu, 27 Apr 1995 19:14:09 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA05286; Thu, 27 Apr 1995 18:10:24 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA05282; Thu, 27 Apr 1995 18:10:22 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA08099; Thu, 27 Apr 1995 19:10:20 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA22990; Thu, 27 Apr 95 17:10:18 PDT Received: from acquine.klab.caltech.edu by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA04372; Thu, 27 Apr 95 20:09:52 EDT Received: from (locke.klab.caltech.edu [131.215.31.39]) by acquine.klab.caltech.edu (8.6.10) with SMTP id RAA15984 for ; Thu, 27 Apr 1995 17:09:47 -0700 Received: by (NX5.67e/NX3.0M) id AA02718; Thu, 27 Apr 95 17:09:43 -0700 Date: Thu, 27 Apr 95 17:09:43 -0700 From: "Charles C. Fu" Message-Id: <9504280009.AA02718@> To: info-cvs@prep.ai.mit.edu In-Reply-To: <9504271947.AA01986@senco.com> (message from Robert Seymour on Thu, 27 Apr 95 15:47:34 -0400) Subject: Re: CVS Installation Problems on NEXTSTEP Content-Length: 449 Status: RO > password routines not implemented at > /LocalDeveloper/Source/CVSROOT/log.pl line 77. > The line of log.pl in question is: > $login = getlogin || (getpwuid($<))[0] || "nobody"; That's a problem I've seen with perl executables at some sites. (It is possible this problem is present in the compiled executable available at some archives.) Grabbing the latest executable and compiling it successfully will make the problem go away. -ccwf From info-cvs-request@prep.ai.mit.edu Thu Apr 27 20:06:36 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA22238 for ; Thu, 27 Apr 1995 20:06:32 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21518; Thu, 27 Apr 95 17:04:19 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA07865; Thu, 27 Apr 1995 19:03:40 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04325; Thu, 27 Apr 1995 17:46:56 -0600 Received: from Central.Sun.COM bFrom info-cvs-request@prep.ai.mit.edu Thu Apr 27 22:26:31 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA10955 for ; Thu, 27 Apr 1995 22:26:28 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10581; Thu, 27 Apr 95 19:24:28 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA11727; Thu, 27 Apr 1995 21:20:50 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08279; Thu, 27 Apr 1995 20:02:42 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08275; Thu, 27 Apr 1995 20:02:40 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA11379; Thu, 27 Apr 1995 21:02:22 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA07645; Thu, 27 Apr 95 19:02:13 PDT Received: from hyper.Franz.COM by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA10239; Thu, 27 Apr 95 22:01:45 EDT Received: from vapor.Franz.COM by hyper.Franz.COM (NeXT-1.0 (From Sendmail 5.52)/FI-2.0) id AA06437; Thu, 27 Apr 95 19:01:19 PDT Received: from localhost by vapor.Franz.COM (4.1/FI-2.0) id AA24622; Thu, 27 Apr 95 19:00:09 PDT Message-Id: <9504280200.AA24622@vapor.Franz.COM> To: info-cvs@prep.ai.mit.edu Subject: CVS 1.3 for NT Date: Thu, 27 Apr 1995 19:00:03 -0700 From: Kevin Layer Content-Length: 1752 Status: RO CVS 1.3 (with RCS 5.6.4 and GNU diff 2.5) "console app" for Windows NT 3.x (tested on 3.5 and 3.51beta) is available for downloading from the following URLs with the names cvs13nt.zip (binary) and cvs13nts.zip (source, requires MSVC++ 2.x): ftp://curly.viewlogic.com/pub/ ftp://ftp.bhs.com/ http://www.bhs.com/application.center/ Below is the `readme.1st' file which appears in each zip file. Kevin Layer layer@Franz.COM http://www.franz.com/ Franz Inc., 1995 University Avenue, Suite 275, Berkeley, CA 94704, USA Phone: (510) 548-3600 FAX: (510) 548-8253 ******************************************************************************* CVS 1.3 RCS 5.6.4 DIFF 2.5 for MS Windows NT 3.5 (Intel) cvs13nt.zip is a binary (console exe's) for NT and cvs13nts.zip contains the sources from which the exe's were built. MSC 8 or 9 can be used, under NT, to build. The CVS sources were derived from previous work by Erik van Linstee. I have made changes to compile with MSC (his version is known to work with Watcom and on OS/2). The RCS and DIFF portions were derived from previous work: ftp.cdrom.com:/pub/cica/nt/gr564s.zip ftp.cdrom.com:/pub/cica/nt/gd25s.zip The binary and source distributions are provided "AS IS" with no WARRANTY whatsoever. To unpack use (in an empty directory is best): pkunzip -d cvs13nt.zip creates bin pkunzip -d cvs13nts.zip creates src To use this version of cvs, you will need to add the following to your environment (Control Panel -> System), where case is unimportant: RCSPATH %d/rcs/%f CVSROOT x:\cvsroot (for example) TZ PST8PDT (for example) and put the `bin' directory mentioned above at the beginning of your PATH. From info-cvs-request@prep.ai.mit.edu Fri Apr 28 01:30:28 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id BAA14597 for ; Fri, 28 Apr 1995 01:30:27 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27317; Thu, 27 Apr 95 22:28:54 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA14817; Fri, 28 Apr 1995 00:28:46 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA12856; Thu, 27 Apr 1995 23:15:04 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA12808; Thu, 27 Apr 1995 23:14:46 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA14607; Fri, 28 Apr 1995 00:14:38 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA26281; Thu, 27 Apr 95 22:14:37 PDT Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA17726; Fri, 28 Apr 95 01:14:33 EDT Received: from monad.armadillo.com (monad.armadillo.com [199.199.0.1]) by monad.armadillo.com (8.6.11/8.6.11) with ESMTP id AAA07209; Fri, 28 Apr 1995 00:14:07 -0500 Message-Id: <199504280514.AAA07209@monad.armadillo.com> From: "david d `zoo' zuhn" Organization: armadillo zoo software -- +1 500 DOS BITES (really) To: "Michael E. Allen" Cc: info-cvs@prep.ai.mit.edu Subject: Re: cvs.h:282: conflicting types for `gethostname' on Linux 1.2.1 In-Reply-To: Your message of "Thu, 27 Apr 1995 23:41:20 CDT." <199504280441.XAA00457@allenme.pr.mcs.net> X-Punishment: I will not pledge allegiance to Bart Date: Fri, 28 Apr 1995 00:14:05 -0500 Sender: zoo@armadillo.com Content-Length: 420 Status: RO To anyone trying to compile and/or port CVS on some "new" platform (ie, some operating system released since 1992), please try CVS 1.4A2 instead of 1.3. There has been a lot of work done to make CVS much more portable, and there's not much sense in others duplicating this work. See ftp://ftp.delos.com/pub/cvs/alpha/cvs-1.4A2.tar.gz and http://www.winternet.com/~zoo/cvs/ for more information on 1.4A2. From info-cvs-request@prep.ai.mit.edu Thu Apr 27 06:17:32 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id GAA05876 for ; Thu, 27 Apr 1995 06:17:31 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09742; Thu, 27 Apr 95 03:13:59 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA24344; Thu, 27 Apr 1995 05:13:50 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02252; Thu, 27 Apr 1995 03:58:16 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02248; Thu, 27 Apr 1995 03:58:15 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA23132; Thu, 27 Apr 1995 04:58:14 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AB04980; Thu, 27 Apr 95 02:58:12 PDT Received: from ns.dknet.dk by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA18756; Thu, 27 Apr 95 05:58:01 EDT Received: from dator by ns.dknet.dk with UUCP id AA00487 (5.65c8/IDA-1.4.4j for prep.ai.mit.edu!info-cvs); Thu, 27 Apr 1995 11:57:38 +0200 Date: Thu, 27 Apr 1995 11:57:38 +0200 Received: from cpusrv1 by dator.UUCP id aa00683; 27 Apr 95 11:32 GMT To: info-cvs@prep.ai.mit.edu Subject: CVS 1.4A2 for Windows NT From: mhi@dator.dk Message-Id: <9504271132.aa28647@cpusrv1.dator.dk> X-Charset: ASCII X-Char-Esc: 29 Content-Length: 1174 Status: RO I have received a number of mails from people who seem interested in CVS for Windows NT and with the help of Greg Schueman I have been able to make my CVS port generally available. It can be found at: ftp://ftp.digex.net/pub/access/schueman/cvs/cvsnt14b.zip and ftp://ftp.digex.net/pub/access/schueman/cvs/cvsnt14s.zip b indicates binaries s indicates source Please note that this is sort of a beta release and I can't promise to support this code in any way (but of course I'll see what I can do). If you find - and (hopefully) fix - any bugs, please let me know. Enjoy... /morten /----------------------------------------------------------------------\ | Morten Hindsholm Email : mhi@dator.dk | | SW Engineer Phone : +45 98574400 | | DATOR A/S Fax : +45 98574473 | | Jernbanegade 4 | | DK-9560 Hadsund | | Denmark | \----------------------------------------------------------------------/ From info-cvs-request@prep.ai.mit.edu Thu Apr 27 04:47:20 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA05402 for ; Thu, 27 Apr 1995 04:47:17 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28814; Thu, 27 Apr 95 01:43:57 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA18615; Thu, 27 Apr 1995 03:43:48 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00500; Thu, 27 Apr 1995 02:35:17 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00496; Thu, 27 Apr 1995 02:35:15 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA18080; Thu, 27 Apr 1995 03:35:14 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA28071; Thu, 27 Apr 95 01:35:12 PDT Received: from snex11.senet.abb.se ([138.221.106.11]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA17380; Thu, 27 Apr 95 04:32:48 EDT Received: from localhost by snex11.senet.abb.se; (5.65/1.1.8.2/03Oct94-0154PM) id AA01300; Thu, 27 Apr 1995 10:35:33 +0200 Message-Id: <9504270835.AA01300@snex11.senet.abb.se> To: info-cvs@prep.ai.mit.edu Cc: gtornblo@senet.abb.se Subject: file locking and storage of binary files Date: Thu, 27 Apr 95 10:35:32 +0200 From: gtornblo@senet.abb.se X-Mts: smtp Content-Length: 5280 Status: RO Two major reasons forces us to add functionality to our CVS based s/w development environment. 1) We need to store non-ascii files (documents, bitmaps etc.) these type of files can be stored in RCS but the deltas will be big and the files may become corrupted. 2) Files that cannot be merged (non-ascii files or files where parallel would generate instead of save work). To solve this we have to setup some kind of file storage that is not RCS based but must include version control. Further on, we must make introduce locking in order to serialize work on these and some other files (but parallel develoment should always be the default). Below you will find the outlines of a possible solution. Any comment/remark is welcome. a) The CVS repository is placed under a top directory that contains both CVSTOP and a BINTOP like this: REP /\ / \ / \ BINTOP CVSTOP b) In a central position in the CVS repository ($CVSROOT/CVSROOT) we keep a file ".nocdev" (for no concurrent development). The syntax of this file -- - --- is given in the following example: # ------------------- ----------------- .doc bin cchead ascii and like .cvsignore the file can appear on each cvs directory and if it does it will override the $CVSROOT/CVSROOT version. c) If a file matches a filename pattern in the ".nocvd" file at commit/checkout the following will happen: ascii: checkout/commit with lock using the real CVS (RCS based) repository with the method described in the CVS FAQ section 3C8 point 1-4 bin: commit : ------ if file not found under BINTOP: - Create a [filename].bintop file containing a line "[filename]_1" - Store the file under BINTOP with a filename that includes version number. (NOTE! no RCS storage) e.g. BINTOP/dir/dir/[filename]_1 - commit the [filename].bintop file into the real CVS (RCS based) repository. if file found under BINTOP: - checkout and lock [filename].bintop file. Use the method described un the CVS FAQ, section 3C.8 If it cannot be checked out the reason is that someone else has locked the file as described under checkout below. If your checkout+lock is successful it was either already checked out and locked by you or it was unlocked. In both cases it is OK to continue with the commit operation. - read the BINTOP filename from [filename].bintop e.g. "[filename]_17" - increment the version number and create a new [filename].bintop file containing a line e.g. "[filename}_18" - store the file under BINTOP with a filename that includes version number.(NOTE! no RCS storage) e.g. BINTOP/dir1/dir2/[filename]_18 - commit the [filename].bintop file into the real CVS (RCS based) repository. As a side-effect this commit will also release the lock. checkout: -------- - checkout and lock the latest version of the [filename].bintop file with the method described in the CVS FAQ section 3C8 point 1-4 If it cannot be checked out the reason is that someone else has locked the file and you will have to wait until the lock is released. - read the BINTOP filename from [filename].bintop e.g. "[filename]_17" - Get the file from BINTOP to user working dir. (release handling of 'binary' files can be done by putting a release tag on the [filename].bintop file since the content of this file is pointing out a specific revision of the actual file under BINTOP. Of course we need to invent some kind of postcommit script in order to fetch the real file from BINTOP)) For all files that does not match any filename pattern given in ".nocvd" (appr. 95 % of all our files) we will use the standard CVS commit/checkout model including branches, parallel development and merge. Does this violate the CVS model ? is there a better solution ? did I forget something important ? Send any comment that you have to me directly (gunnar.tornblom@senet.abb.se) or to the CVS list. Thanks Gunnar From info-cvs-request@prep.ai.mit.edu Thu Apr 27 13:09:26 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA01799 for ; Thu, 27 Apr 1995 13:09:23 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05970; Thu, 27 Apr 95 10:06:55 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA28157; Thu, 27 Apr 1995 12:06:04 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA15952; Thu, 27 Apr 1995 10:45:20 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA15944; Thu, 27 Apr 1995 10:45:18 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA25836; Thu, 27 Apr 1995 11:45:09 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA02231; Thu, 27 Apr 95 09:45:07 PDT Received: from relay1.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA06731; Thu, 27 Apr 95 12:44:22 EDT Received: from cygnus.com by relay1.UU.NET with ESMTP id QQynhi10037; Thu, 27 Apr 1995 12:44:20 -0400 Received: from lioth.cygnus.com (lioth.cygnus.com [198.6.99.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id JAA18861; Thu, 27 Apr 1995 09:44:17 -0700 From: Jim Kingdon Received: from localhost (kingdon@localhost) by lioth.cygnus.com (8.6.4/8.6.4) id MAA25156; Thu, 27 Apr 1995 12:43:59 -0400 Date: Thu, 27 Apr 1995 12:43:59 -0400 Message-Id: <199504271643.MAA25156@lioth.cygnus.com> To: info-cvs@prep.ai.mit.edu In-Reply-To: <9504270659.AA02594@ernie.dfv> (petras@ernie) Subject: Re: adds Content-Length: 2562 Status: RO Someone writes in email: >This sounds very well, but please tell me, what is CCVS, is it >compatible to cvs 1.3 and where can I find it? Here is the info: Cyclic CVS Mini-FAQ ftp://ftp.cyclic.com/pub/cvs/mini-FAQ Jim Blandy * What is Cyclic CVS? Cyclic CVS is a branch from version 1.4A2 of the original CVS distribution, with further bug fixes and speedups installed, in addition to the remote repository access features. Cyclic CVS can access repositories on remote machines. This is very helpful when collaborating on a project with someone across a wide-area network. Here are some of Cyclic CVS's features: - It uses reliable transport protocols (TCP/IP) for remote repository access, not NFS. NFS is unusable over long distances (and sometimes over short distances) - It transfers only those files that have changed in the repository or the working directory. To save transmission time, it will transfer patches when appropriate, and can compress data for transmission. - The server never holds CVS locks while waiting for a reply from the client; this makes the system robust when used over flaky networks. * Aren't there other similar CVS hacks out there? There have been several CVS variants designed with similar goals. contrib/pcl-cvs/pcl-cvs.el mentions one or two, for example. However, I've had a hard time finding more information about those implementations, so I can't comment on them. The sense of the info-cvs mailing list seems to be that CCVS is the best extant implementation. * How can I get Cyclic CVS? If you'd like to try this implementation out, it's available via anonymous ftp from ftp.cyclic.com, as /pub/cvs/cvs.tar.gz. The mailing list cyclic-cvs@cyclic.com has been set up to handle bug reports and questions; send mail to cyclic-cvs-request@cyclic.com to subscribe or unsubscribe. Nota bene: - It has not tested or ported much, with all that that entails --- bugs, portability problems, documentation inconsistencies. - I can't promise any support for it for free. If you're interested in a support or development contract, send me mail and we'll work something out. - Nevertheless, please send all bug reports to cyclic-cvs@cyclic.com. Most people on the info-cvs mailing list probably won't be able to fix them (since they don't use the package). * Where are the remote features documented? Check out doc/cvsclient.texi in the Cyclic CVS distribution. Would you like to update the main doc file, cvs.texinfo to describe Cyclic CVS's features? From info-cvs-request@prep.ai.mit.edu Fri Apr 28 19:09:42 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA02765 for ; Fri, 28 Apr 1995 19:09:40 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA19709; Fri, 28 Apr 95 16:06:39 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA21100; Fri, 28 Apr 1995 18:06:14 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24059; Fri, 28 Apr 1995 16:47:26 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24055; Fri, 28 Apr 1995 16:47:24 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA19329; Fri, 28 Apr 1995 17:47:24 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA16223; Fri, 28 Apr 95 15:47:19 PDT Received: from relay3.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA02632; Fri, 28 Apr 95 18:47:15 EDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQynlz14552; Fri, 28 Apr 1995 18:47:16 -0400 Received: from etnibsd.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Fri, 28 Apr 1995 18:47:15 -0400 Received: by etnibsd.UUCP (4.1/SMI-4.1(VSH)) id AA15716; Fri, 28 Apr 95 17:59:08 EDT From: etnibsd!vsh@uunet.uu.net (Steve Harris) Message-Id: <9504282159.AA15716@etnibsd.UUCP> Subject: Re: Vendor Branches To: info-cvs@prep.ai.mit.edu (CVS Info Maillist) Date: Fri, 28 Apr 1995 17:59:07 -0400 (EDT) In-Reply-To: <199504282055.QAA14765@kayak.odi.com> from "David Grubbs" at Apr 28, 95 04:55:06 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 211 Status: RO As I recall, you _can_ specify an alternative branch when you import. I played with this at one time, and it seemed to do what I wanted. -- Steve Harris - Eaton Corp. - Beverly, MA - vsh%etnibsd@uunet.uu.net From info-cvs-request@prep.ai.mit.edu Fri Apr 28 17:56:21 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA31370 for ; Fri, 28 Apr 1995 17:56:17 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA06271; Fri, 28 Apr 95 14:52:45 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA16821; Fri, 28 Apr 1995 16:52:03 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18534; Fri, 28 Apr 1995 15:26:19 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18530; Fri, 28 Apr 1995 15:26:18 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA15636; Fri, 28 Apr 1995 16:26:18 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA01081; Fri, 28 Apr 95 14:26:13 PDT Received: from avalon.dpc.com (dpc.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA28325; Fri, 28 Apr 95 17:26:06 EDT Received: by avalon.dpc.com (5.65/DEC-Ultrix/4.3) id AA11899; Fri, 28 Apr 1995 14:19:26 -0700 Received: from gate.dpc.com(192.215.72.47) by avalon via smap (V1.3mjr) id sma011895; Fri Apr 28 14:18:37 1995 Received: by gate.dpc.com (5.57/Ultrix3.0-C) id AA06487; Fri, 28 Apr 95 14:13:41 -0700 Received: from cog-dpceng(192.215.72.83) by gate via smap (V1.3mjr) id sma006479; Fri Apr 28 14:12:40 1995 Received: from localhost (smap@localhost) by cog-codev.dpc.com (8.6.5/8.6.5) id OAA01037 for ; Fri, 28 Apr 1995 14:14:16 -0700 Received: from yawl.dpc.com(192.168.2.3) by cog-codev.dpc.com via smap (V1.3) id sma001035; Fri Apr 28 14:14:09 1995 Received: by yawl.dpc.com (4.1/SMI-4.1) id AA00749; Fri, 28 Apr 95 14:26:39 PDT Date: Fri, 28 Apr 95 14:26:39 PDT From: gstrock@dpc.com (Greg Strockbine) Message-Id: <9504282126.AA00749@yawl.dpc.com> To: info-cvs@prep.ai.mit.edu Subject: cvs 1.4A2 fails sanity check Content-Length: 205 Status: RO I am running SunOS Release 4.1.3, I built cvs 1.4A2 with gcc, with MY_NDBM defined. It bombs sanity.sh on test 70. Anyone seen this before? thanx, greg strockbine, dataproducts, wood land hills, ca. From info-cvs-request@prep.ai.mit.edu Fri Apr 28 17:08:45 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA28836 for ; Fri, 28 Apr 1995 17:07:30 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27433; Fri, 28 Apr 95 14:05:08 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA14691; Fri, 28 Apr 1995 16:04:32 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA17133; Fri, 28 Apr 1995 14:55:40 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA17129; Fri, 28 Apr 1995 14:55:37 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA14057; Fri, 28 Apr 1995 15:55:30 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA25634; Fri, 28 Apr 95 13:55:25 PDT Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA26638; Fri, 28 Apr 95 16:55:23 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA13612; Fri, 28 Apr 1995 16:55:11 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA01963; Fri, 28 Apr 95 16:55:06 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id QAA14765; Fri, 28 Apr 1995 16:55:06 -0400 Date: Fri, 28 Apr 1995 16:55:06 -0400 Message-Id: <199504282055.QAA14765@kayak.odi.com> To: frank@ns.array.ca Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9504272346.AA17134@ ns.array.ca> (frank@ns.array.ca) Subject: Re: Vendor Branches Reply-To: dgg@odi.com Content-Length: 1481 Status: RO > I've come across the situation where I've imported multiple > vendor releases of a package, but I don't necessarily want the > most recently imported version to be what I get when I do a > plain "checkout". I'd like to be able to choose which release to base > my main branch on. > > It seems that a vendor branch is handled differenty than a regular > branch. If you branch off from revision 1.6, the main branch > is unaffected by what happens on 1.6.2, but each change to a > revision on the vendor branch 1.1.1 seems to cause revision 1.1 > to "point" to the head of 1.1.1 (more or less). Is this > reasonably accurate? > > I didn't seem to find an answer to this question in the FAQ. Is > there a way to do what I want to do? I can't quote the FAQ on this matter because there is too *much* material about this in the FAQ. The one-sentence summary of hundreds of lines scattered throughout the document is this: The Vendor branch (which is stored on an RCS branch off rev 1.1) should be considered, along with the RCS main branch, to be a part of a single, complex data structure that supports the "CVS main branch". Another way of looking at it is that you can't choose what piece of the Vendor branch to include in the "Main line" because the Vendor branch is *part* of the main line. The only control over it you have is not to import a release you don't like. If I were in that position, I'd skip the import, run "diff -r" and take the pieces I wanted. From info-cvs-request@prep.ai.mit.edu Fri Apr 28 15:54:17 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA19432 for ; Fri, 28 Apr 1995 15:54:16 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14036; Fri, 28 Apr 95 12:52:17 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA11087; Fri, 28 Apr 1995 14:51:17 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13727; Fri, 28 Apr 1995 13:40:15 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13719; Fri, 28 Apr 1995 13:40:13 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA10534; Fri, 28 Apr 1995 14:40:12 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA11617; Fri, 28 Apr 95 12:40:07 PDT Received: from totoro.bio.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA21545; Fri, 28 Apr 95 15:40:04 EDT Received: (from jimb@localhost) by totoro.bio.indiana.edu (8.6.9/8.6.9) id OAA25261; Fri, 28 Apr 1995 14:39:56 -0500 Date: Fri, 28 Apr 1995 14:39:56 -0500 From: Jim Blandy Message-Id: <199504281939.OAA25261@totoro.bio.indiana.edu> To: nilesh@hagar.aspentec.com (Nilesh PatelL) Cc: info-cvs@prep.ai.mit.edu Subject: CVS on Network (TCP/IP)? In-Reply-To: <9504281623.AA61443@hagar.aspentec.com> References: <9504281623.AA61443@hagar.aspentec.com> Gnu-Emacs: or perhaps you'd prefer Russian Roulette, after all? Content-Length: 656 Status: RO > I know about Cyclic-CVS. But I do not know the extent to which it >has been tested/debugged. A very close relative of Cyclic CVS is currently in use at Cygnus Support, and the group of people putting together Cyclic Software (to be running in June, BTW) are using CCVS for their current projects. It seems to be pretty reliable for our purposes, but it has not really been subject to serious public review. This means that the features we use work correctly, and the features we don't use, well, your guess is as good as ours. One of the goals of Cyclic Software is to assemble a consortium of CCVS users to support its maintenance and development. From info-cvs-request@prep.ai.mit.edu Tue May 2 13:31:04 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA09411 for ; Tue, 2 May 1995 13:31:02 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA23216; Tue, 2 May 95 10:06:47 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA04234; Tue, 2 May 1995 12:05:41 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA21467; Tue, 2 May 1995 10:49:52 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA21463; Tue, 2 May 1995 10:49:49 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA03037; Tue, 2 May 1995 11:49:47 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA19415; Tue, 2 May 95 09:49:16 PDT Received: from eskinews.eskimo.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA28700; Tue, 2 May 95 12:49:12 EDT Received: from gasv.UUCP by eskinews.eskimo.com (5.65c/1.35) id AA04400; Tue, 2 May 1995 09:49:10 -0700 Received: from lolead.gasboy.com by mirror.gasboy.com id aa23411; Tue, 2 May 95 9:54:00 PDT Received: by lolead.gasboy.com (Smail3.1.29.1 #3) id m0s6LEq-000UGmC; Tue, 2 May 95 09:55 PDT Message-Id: From: dan@gasboy.com (Dan Wilder) Subject: Join problem -- bug? To: info-cvs@prep.ai.mit.edu (CVS List) Date: Tue, 2 May 1995 09:55:56 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4148 Status: RO Synopsis: cvs-1.4A2 fails on join where cvs-1.3 continued. A simplified test case is described first, followed by a more complete description of our application. A simplified test case: multiple files on two branches, two tags on one, thus: . . . x x------* branch B2 x x x---T1---T2 branch B1, tags T1 and T2 x x (trunk) Some file f1.c on B1 has tags T1 and T2 but has been removed during B2. There is no mention of f1.c in any B2 source tree CVS/Entries. With cvs-1.3, in B2 source tree: cvs update -jT1 -jT2 produces the desired result: all files in B2 are updated with respect to tags T1, T2 in B1. When cvs-1.4A2 attempts this, the error message cvs [update aborted]: cannot open f1.c for copying: No such file or directory appears, and cvs aborts. The message originates in a call to error() from copy_file() in subr.c, called from join_file() in update.c. My questions. (1) Is this the intended behavior? If "yes" I'll quit grumbling and quietly institute a local fix or workaround. If "no", question (2) pertains. (2) What is the best fix? Simplest might be another parameter to copy_file, to prevent it from exiting when called in a join and perhaps a merge context, from update.c. A return code would allow cleanup. Copy_file is called from only three places, and the call from checkin.c would presumably need its behavior unaffected. Existing error messages could be used, by passing on the new parameter to the routine "error" calls in copy_file, then recovering on return. Next simplest, the prospective target file could be tested for existence before calling copy_file, at the cost of an additional directory access per file updated. No changes to copy_file would be required, and only a few changes to update.c. Duplicate error messages would be needed. Most complex, recursion processing on join, and perhaps on merge, could be altered to consider only files found in the targeted branch. I'm out of my depth (or maybe the time the boss will let me spend on it) trying this without a few helpful pointers from somebody. Anyway it sounds like this could ripple more than the first two. If a whole lot of responses all said YEAH YEAH DO THAT, including some encouraging words from the more seasoned hands on this list, I'd implement this and post the results. BACKGROUND -- Here is a more detailed description of what we are doing, which renders unwieldy such possible solutions as tagging only files that actually exist in the next branch upward, etc etc. A multi-branched project under cvs-1.3. Branches represent stages in product evolution. A released branch is under bugfix only policy, while four branches are under development: B1 bugfixes only B2 new features, anticipated Q2 '95 release B3 Same as B2 but ported to an ANSI C compiler in place of the relict used for B1 and B2. Function prototypes and all that stuff. Different assembler. Release Q4 '95. B4 Same as B3 but new target hardware. Beta Q3 '95. B5 Same as B4 but new features including redesigned user interface to make use of new target platform. Beta Q1 '96, maybe earlier. At intervals, changes in B1 are joined into B2, thence to B3, B4, and B5. More than a hundred source code files extend over perhaps fifteen directories. Later branches have source code files not found in earlier ones, and files from earlier branches are sometimes retired as of later ones. Join is conducted by shell scripts which maintain join tags, protect certain files by saving before join, restoring afterward, etc etc. After join is verified and committed, the tags are moved for use in the next join. The obvious workaround for our problem (maybe, I have not tested it) would be to make sure B1 has no tagged files such as f1.c, removed as of B2. This however is an additional step not previously necessary, involving the sort of shell scripting CVS was apparently written to get around. We would rather avoid this. -- Dan Wilder From lechner Mon May 1 22:42:09 1995 Received: (from lechner@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id WAA17521; Mon, 1 May 1995 22:15:38 -0400 From: Bob Lechner Message-Id: <199505020215.WAA17521@jupiter.cs.uml.edu> Subject: Re: CVS vs. SparcWorks (fwd)Comments anyone? To: jannunzi, abagul, bbarry, mbouchar, ncao, xcao, cychang, chachen, kchen, tchoi, ndesilva, rdias, sfan, tfragala, jhung, sjois, vkankipa, rkher, cko, skyatsan, glazar, greg@puck.webo.dg.com, tleong, fliu, smakkapa, mmaliset, amanuja, cmclain, bmehta, kmirchan, rpakala, hcpatel, bphilip, sramacha, asarcar, msrdanov, mas@swl.msd.ray.com, ksomsama, ssundare, rtillson, cwu, chwang, wexu, yzhou, azinzuwa, lechner, cgopal Date: Mon, 1 May 1995 22:15:37 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1005 Status: RO Forwarded message: >From info-cvs-request@prep.ai.mit.edu Mon May 1 12:31:05 1995 From: tony bennett Date: Mon, 1 May 1995 08:55:46 -0400 Message-Id: <9505011255.AA23319@uh-oh.divnc.com> To: jimb@totoro.bio.indiana.edu Cc: info-cvs@prep.ai.mit.edu Subject: Re: CVS vs. SparcWorks In-Reply-To: message of Jim Blandy (on Sun, Apr 30/1995) References: <199504301933.OAA13474@totoro.bio.indiana.edu> Content-Length: 566 Jim> Can anyone tell me about the differences between CVS and SparcWorks' Jim> source control facilities? I've checked the comparisons in the CVS Jim> FAQ, and SparcWorks isn't covered there. It is there listed as 'teamware' (1C.4 in my version). The faq seems to imply that the only interface to teamware is via GUI's. This is not the case. Most people use the command interface exclusively. Except for cost, I prefer teamware over CVS. It is *much* easier to use and understand, and has undo capabilities and is generally a professional quality tool. --tony From info-cvs-request@prep.ai.mit.edu Tue May 2 10:40:00 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA06768 for ; Tue, 2 May 1995 10:39:59 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05094; Sun, 30 Apr 95 17:58:48 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20095; Sun, 30 Apr 1995 19:58:42 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01550; Sun, 30 Apr 1995 18:55:00 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01546; Sun, 30 Apr 1995 18:54:59 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA20028; Sun, 30 Apr 1995 19:54:52 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA04800; Sun, 30 Apr 95 17:54:42 PDT Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA24305; Sun, 30 Apr 95 20:54:38 EDT Received: from monad.armadillo.com (monad.armadillo.com [199.199.0.1]) by monad.armadillo.com (8.6.11/8.6.11) with ESMTP id TAA21364; Sun, 30 Apr 1995 19:55:28 -0500 Message-Id: <199505010055.TAA21364@monad.armadillo.com> From: "david d `zoo' zuhn" Organization: armadillo zoo software -- +1 500 DOS BITES (really) To: surya@premenos.com Cc: info-cvs@prep.ai.mit.edu Subject: Re: integrating mail with cvs... In-Reply-To: Your message of "Sun, 30 Apr 1995 17:38:56 PDT." <199505010038.RAA16884@tortosa.templar.net> X-Punishment: I will not sell school property Date: Sun, 30 Apr 1995 19:55:24 -0500 Sender: zoo@armadillo.com Content-Length: 940 Status: RO >From the FAQ, available via the WWW page at http://www.winternet.com/~zoo/cvs/ The FAQ itself is at http://www.winternet.com/~zoo/cvs/FAQ.txt 4D.15 How do I use the "loginfo" files? See 4B.2 and the "commitinfo" question above. The "loginfo" file has the same format as the "commitinfo" file, but its function is different. Where the "commitinfo" information is used before a commit, the "loginfo" file is used after a commit. All the commands in the "loginfo" file should read data from standard input, then either append it to a file or send a message to a mailing list. If you want to make it simple, you can put shell (the shell used by "popen(3)") command lines directly in the "loginfo" (or "commitinfo") file. These seem to work: ^special /usr/ucb/Mail -s %s special-mailing-list ^other /usr/ucb/Mail -s %s other-mailing-list DEFAULT (echo '===='; echo %s; cat) > /path/name/to/log/file From info-cvs-request@prep.ai.mit.edu Mon May 8 21:45:17 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id VAA24000 for ; Mon, 8 May 1995 21:45:14 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25947; Mon, 8 May 95 18:31:46 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA00676; Mon, 8 May 1995 20:31:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA21107; Mon, 8 May 1995 19:14:26 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA21103; Mon, 8 May 1995 19:14:25 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA00372; Mon, 8 May 1995 20:14:23 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA22713; Mon, 8 May 95 18:14:15 PDT Received: from gate-e0 (gate.altair.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA22434; Mon, 8 May 95 16:05:08 EDT Received: from auspex.troy.altair.com (auspex-e2 [192.9.202.1]) by gate-e0 (8.6.9/8.6.9) with ESMTP id QAA24953 for ; Mon, 8 May 1995 16:05:30 -0400 Received: from ind30 (ind30.prog.altair.com [192.9.201.230]) by auspex.troy.altair.com (8.6.9/8.6.9) with SMTP id QAA27799 for ; Mon, 8 May 1995 16:05:28 -0400 Received: by ind30 (931110.SGI/930416.SGI) for info-cvs@prep.ai.mit.edu id AA03603; Mon, 8 May 95 16:05:28 -0400 Date: Mon, 8 May 95 16:05:28 -0400 From: prn@altair.com (Paul Nickels) Message-Id: <9505082005.AA03603@ind30> To: info-cvs@prep.ai.mit.edu Content-Length: 1063 Status: RO While updating, I have the following situation occur. I have checked out two identical source code files, I make different changes to both on the same line and I check one file back in. Then I update the other one expecting the following format <<<<<<< ------- >>>>>>> to appear in the second file. I do receive a message saying the file are different but no changes are made, but the database gets updated with file two. Do you have any suggestions on what I should look for? Thanks Paul Nickels ============================================================================= +------------------------------+--------------------------------------------+ | Paul R. Nickels | | | Altair Engineering, Inc. | Email: prn@altair.com | | 1757 Maplelawn Drive | Phone: (810) 614-2400 ext 246 | | Troy, MI 48084-4004 | Fax : (810) 614-2411 | +------------------------------+--------------------------------------------+ From info-cvs-request@prep.ai.mit.edu Mon May 8 23:58:03 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA00720 for ; Mon, 8 May 1995 23:58:01 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21415; Fri, 5 May 95 15:01:52 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA01727; Fri, 5 May 1995 17:01:30 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06021; Fri, 5 May 1995 15:48:44 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06017; Fri, 5 May 1995 15:48:42 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA00978; Fri, 5 May 1995 16:48:41 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA18930; Fri, 5 May 95 14:48:16 PDT Received: from halcyon.com (chinook.halcyon.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA27395; Fri, 5 May 95 17:48:04 EDT Received: by halcyon.com id AA29752 (5.65c/IDA-1.4.4 for info-cvs@prep.ai.mit.edu); Fri, 5 May 1995 14:48:00 -0700 From: "Michael L. Coburn" Message-Id: <199505052148.AA29752@halcyon.com> Subject: Reasonably Secure cvs To: info-cvs@prep.ai.mit.edu Date: Fri, 5 May 1995 14:48:00 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859 Content-Transfer-Encoding: 8bit Content-Length: 1287 Status: RO I've spent an enjoyable week learning about how suid and sgid actually work (and don't work) on Solaris. The first trick was to get the contrib perl script to work in a protected "admin" area in CVSROOT. Although I've found ways to get rcs and cvs to co-operatively manage a protected repository (safe from file deletion by economists who then say "well, assume the file still exists"), it now occurs to me that others have probably already done this type of thing and could probably give me some good directions. Please note that I'm not trying to protect information from safe crackers or prevent folks from checking files/revisions in and out, but only to prevent inadvertent and/or malicious tampering (eg outdating). At present I've made 4 VERY minor alterations (one to ci.c and 3 to cvs) in order to allow cvs/rcs to work on protected repositories while preserving the real user's name and file ownerships in user space. However, I've had to preclude direct "import" to the repository and at present an unprotected repository is used to "import" and then the rcs files are copied to the protected repository by the administrator. This is viable owing to the minimal use of "import" but its kinda cheesy. If these problems have already been resolved please let me know. From info-cvs-request@prep.ai.mit.edu Tue May 9 14:35:04 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA01827 for ; Tue, 9 May 1995 14:34:53 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA01609; Tue, 9 May 95 11:13:44 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA25455; Tue, 9 May 1995 13:13:36 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA21183; Tue, 9 May 1995 12:00:31 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA21179; Tue, 9 May 1995 12:00:30 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA24608; Tue, 9 May 1995 13:00:28 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA28448; Tue, 9 May 95 11:00:21 PDT Received: from spsgate.sps.mot.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA29354; Tue, 9 May 95 14:00:14 EDT Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA13354 for info-cvs@prep.ai.mit.edu; Tue, 9 May 95 11:00:12 MST Received: from motsps by mogate (4.1/SMI-4.1/Email-2.0) id AA18924; Tue, 9 May 95 11:00:11 MST Received: from risc.sps.mot.com by motsps (4.1/SMI-4.1/Email-2.1) id AA21408 for info-cvs@prep.ai.mit.edu; Tue, 9 May 95 11:00:09 MST Received: from miaow.sps.mot.com by risc.sps.mot.com (4.1/SMI-3.0DEV3) id AA15310; Tue, 9 May 95 13:00:05 CDT Received: by miaow.sps.mot.com (AIX 3.2/UCB 5.64/4.03) id AA13538; Tue, 9 May 1995 13:00:49 -0500 From: dwolfe@risc.sps.mot.com (Dave Wolfe) Message-Id: <9505091800.AA13538@miaow.sps.mot.com> Subject: Re: CVS-FAQ as HTML To: kaehms@humphrey.com (Bob Kaehms) Date: Tue, 9 May 1995 13:00:49 -0500 (CDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: from "Bob Kaehms" at May 9, 95 10:25:08 am Reply-To: David Wolfe X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 672 Status: RO [ Bob Kaehms writes: ] > Has anyone turned David G's FAQ into an html doc set? If so, could they > send me a pointer. If not, would it be worth doing? (How would it be > kept current witht he FAQ if say I volunteered?) I ran it through a Perl script I wrote to set up links between the index and the answers, which is convenient but hardly a full-blown html document. Sorry, but it's behind a firewall. I suppose I could send you the Perl script, but beware that any format changes in the FAQ are almost certain to break the script. -- Dave Wolfe *Not a spokesman for Motorola* (512) 891-3246 Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598 From info-cvs-request@prep.ai.mit.edu Fri May 5 13:34:31 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA24991 for ; Fri, 5 May 1995 13:34:29 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24018; Fri, 5 May 95 10:21:17 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA25843; Fri, 5 May 1995 12:20:17 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA15794; Fri, 5 May 1995 11:09:49 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA15786; Fri, 5 May 1995 11:09:46 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA25232; Fri, 5 May 1995 12:09:42 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA21549; Fri, 5 May 95 10:09:32 PDT Received: from eskinews.eskimo.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA11050; Fri, 5 May 95 13:09:28 EDT Received: from gasv.UUCP by eskinews.eskimo.com (5.65c/1.35) id AA26924; Fri, 5 May 1995 10:09:25 -0700 Received: from lolead.gasboy.com by mirror.gasboy.com id aa10938; Fri, 5 May 95 10:14:15 PDT Received: by lolead.gasboy.com (Smail3.1.29.1 #3) id m0s7R0I-000UGmC; Fri, 5 May 95 10:17 PDT Message-Id: From: dan@gasboy.com (Dan Wilder) Subject: Dead code in cvs.h tries to set PATH_MAX To: info-cvs@prep.ai.mit.edu Date: Fri, 5 May 1995 10:17:26 -0700 (PDT) Cc: bug-cvs@prep.ai.mit.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 679 Status: RO In cvs-1.4A2: PATH_MAX is defined both in lib/system.h and in src/cvs.h. src/cvs.h includes system.h prior to attempting to set PATH_MAX, rendering its attempt dead, conditioned as it is on #ifndef PATH_MAX which is always defined, one way or another, after system.h. The logic of the definition in src/cvs.h is a not-quite-subset of the logic in system.h, reaching slightly more conservative conclusions in some of the same cases, but not covering as many bases. Suggestion: Examine the logic in cvs.h, determine if the more conservative conclusions are warranted, post the conclusions to system.h, delete the PATH_MAX code in cvs.h. -- Dan Wilder From info-cvs-request@prep.ai.mit.edu Sat May 6 04:55:49 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA29874 for ; Sat, 6 May 1995 04:53:47 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12969; Sat, 6 May 95 01:43:47 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA08811; Sat, 6 May 1995 03:43:37 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA12516; Sat, 6 May 1995 02:27:26 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA12512; Sat, 6 May 1995 02:27:24 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA07163; Sat, 6 May 1995 03:27:23 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA16454; Fri, 5 May 95 14:36:05 PDT Received: from ileaf.com (ileaf.prospect.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA27025; Fri, 5 May 95 17:35:59 EDT Received: from leafusa.UUCP by ileaf.com (4.1/SMI-4.1) id AA16147; Fri, 5 May 95 17:36:15 EDT Received: from owl.hq.ileaf.com by HQ.Ileaf.COM (4.1/SMI-4.0-leafusa) for info-cvs@prep.ai.mit.edu id AA23487; Fri, 5 May 95 17:26:09 EDT Received: by owl.hq.ileaf.com (4.1/SMI-4.0-hq) for info-cvs@prep.ai.mit.edu id AA07566; Fri, 5 May 95 17:26:03 EDT Date: Fri, 5 May 95 17:26:03 EDT From: karl@owl.hq.ileaf.com (Karl Berry) Message-Id: <9505052126.AA07566@owl.hq.ileaf.com> To: info-cvs@prep.ai.mit.edu Subject: Re: Dead code in cvs.h tries to set PATH_MAX Content-Length: 279 Status: RO Suggestion: Examine the logic in cvs.h, determine if the more Alternative suggestion: avoid all uses of PATH_MAX by dynamically allocating filename space. On the Hurd, I believe PATH_MAX will be 2**32-1 (or something like that), so arrays of that size won't work too well. From info-cvs-request@prep.ai.mit.edu Fri May 12 12:34:15 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA06708 for ; Fri, 12 May 1995 12:34:13 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29148; Fri, 12 May 95 09:15:45 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA27900; Fri, 12 May 1995 11:15:28 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19496; Fri, 12 May 1995 09:57:42 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19492; Fri, 12 May 1995 09:57:41 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA26622; Fri, 12 May 1995 10:57:39 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA25715; Fri, 12 May 95 08:57:30 PDT Received: from blackhole.cae.ca (CAE.CA) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12214; Fri, 12 May 95 11:56:45 EDT Received: (from uucp@localhost) by blackhole.cae.ca (8.6.7/8.6.6) id LAA03762 for ; Fri, 12 May 1995 11:58:46 -0400 Received: from poster.cae.ca(142.39.20.1) by bhole via smap (V1.3mjr) id sma003754; Fri May 12 11:58:03 1995 Received: from eagle.cae.ca by poster.cae.ca (AIX 3.2/UCB 5.64/4.03) id AA13843; Fri, 12 May 1995 11:52:02 -0400 Received: by eagle.cae.ca (931110.SGI/930416.SGI.AUTO) for @poster.cae.ca:info-cvs@prep.ai.mit.edu id AA25547; Fri, 12 May 95 11:46:17 -0400 From: "Lim Fung Peng" Message-Id: <9505121146.ZM25545@eagle.cae.ca> Date: Fri, 12 May 1995 11:46:12 -0400 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-cvs@prep.ai.mit.edu Subject: Howto co files from other repositories Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Content-Length: 1042 Status: RO Hi cvs users, I am a cvs newbie. I am trying to checkout several files from different directories using only one module name. I have been reading the FAQ but have not been successful. Let me setup the stage ... This is my repository cvs ----inc -- func.h | -- src -- func.c | -- myprog -- func2.c In the modules file, I have ... inc /cvs/inc src /cvs/src myprog /cvs/myprog &inc &src Doing cvs checkout myprog, I get in my home cvs ---- myprog ---- inc -- func.h | -- src -- func.c | -- func2.c Which is not what I intended. What I wanted is ... cvs ---- myprog -- func.h func.c func2.c I have tried different combinations of the various modules on the "myprog" entry line. None worked properly. The only way I got what I wanted was to create soft links in the myprog dir. ln -s /cvs/inc/func.h /cvs/myprog/func.h ln -s /cvs/src/func.c /cvs/myprog/func.c and then in the modules file, simply have ... myprog /cvs/myprog Any advice and suggestion are appreciated. Thanks in advance. From info-cvs-request@prep.ai.mit.edu Thu May 11 12:43:29 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA18677 for ; Thu, 11 May 1995 12:43:25 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00625; Thu, 11 May 95 09:30:58 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA26202; Thu, 11 May 1995 11:30:48 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18317; Thu, 11 May 1995 10:23:03 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18308; Thu, 11 May 1995 10:23:00 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA25332; Thu, 11 May 1995 11:22:57 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA28507; Thu, 11 May 95 09:22:53 PDT Received: from pppl.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA07535; Thu, 11 May 95 12:22:48 EDT Received: from draco.pppl.gov (karney@draco.pppl.gov [198.35.6.44]) by pppl.gov (8.6.12/8.6.10) with ESMTP id MAA13472; Thu, 11 May 1995 12:22:47 -0400 From: Charles Karney Received: (karney@localhost) by draco.pppl.gov (8.6.12/8.6.10) id MAA01074; Thu, 11 May 1995 12:22:44 -0400 Date: Thu, 11 May 1995 12:22:44 -0400 Message-Id: <199505111622.MAA01074@draco.pppl.gov> To: info-cvs@prep.ai.mit.edu Subject: cvs 1.3 on Dec Alpha OSF/1 3.0 Reply-To: karney@princeton.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 2491 Status: RO I encountered the following problems compiling cvs 1.3 on a DEC Alpha OSF/1 3.0 system using gcc 2.6.3. After ./configure, lib/Makefile contains OBJECTS = argmatch.o \ error.o getopt.o getopt1.o \ sighandle.o \ strippath.o stripslash.o yesno.o \ getdate.o \ DISTFILES = Makefile.in getopt.h \ ... DEC's make doesn't like that trailing slash after getdate.o (it runs on into the DISTFILES definition). GNU make doesn't mind. stdio.h and stdlib.h both include lib/getopt.h and this causes duplicate definitions. Fixed by an #if !defined(__getopt_h__)... #endif around getopt.h. lib/getopt.c ends up including lib/getopt.h and this causes duplicate definitions. Fixed by #define __getopt_h__ 1 at top of getopt.h. PATH_MAX ends up defined at (PATH_MAX+1) + 2. The code in src/cvs.h is the culprit, I believe /* At this point we have #define MAXPATHLEN (PATH_MAX+1) #define PATH_MAX 1023 IN THIS ORDER */ #undef PATH_MAX #ifdef MAXPATHLEN #define PATH_MAX MAXPATHLEN+2 #else #define PATH_MAX 1024+2 #endif /* At this point PATH_MAX is (PATH_MAX+1)+2 */ Here are my not-very-elegant patches: *** lib/getopt.h~ Tue Mar 31 16:55:24 1992 --- lib/getopt.h Thu May 11 11:31:25 1995 *************** *** 1,3 **** --- 1,5 ---- + #if !defined(__getopt_h__) + #define __getopt_h__ 1 /* declarations for getopt Copyright (C) 1989, 1990, 1991, 1992 Free Software Foundation, Inc. *************** *** 99,102 **** --- 101,105 ---- int gnu_getopt (); int gnu_getopt_long (); int gnu_getopt_long_only (); + #endif #endif *** lib/getopt.c~ Tue Mar 31 16:55:22 1992 --- lib/getopt.c Thu May 11 11:36:13 1995 *************** *** 1,3 **** --- 1,4 ---- + #define __getopt_h__ 1 /* Getopt for GNU. Copyright (C) 1987-1992 Free Software Foundation, Inc. *** src/cvs.h~ Tue Mar 31 16:55:59 1992 --- src/cvs.h Thu May 11 11:57:53 1995 *************** *** 21,27 **** /* XXX - for now this is static */ #undef PATH_MAX #ifdef MAXPATHLEN ! #define PATH_MAX MAXPATHLEN+2 #else #define PATH_MAX 1024+2 #endif --- 21,28 ---- /* XXX - for now this is static */ #undef PATH_MAX #ifdef MAXPATHLEN ! /* #define PATH_MAX MAXPATHLEN+2 */ ! #define PATH_MAX 1024+2 #else #define PATH_MAX 1024+2 #endif -- Charles Karney Plasma Physics Laboratory E-mail: Karney@Princeton.EDU Princeton University Phone: +1 609 243 2607 Princeton, NJ 08543-0451 FAX: +1 609 243 2662 From info-cvs-request@prep.ai.mit.edu Thu May 11 11:04:13 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA02918 for ; Thu, 11 May 1995 11:04:12 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA11767; Thu, 11 May 95 07:45:25 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA15381; Thu, 11 May 1995 09:45:03 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09273; Thu, 11 May 1995 08:30:29 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09269; Thu, 11 May 1995 08:30:27 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA13824; Thu, 11 May 1995 09:30:26 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA08738; Thu, 11 May 95 07:30:21 PDT Received: from shark.mel.dit.csiro.au by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA00787; Thu, 11 May 95 10:30:15 EDT Received: by shark.mel.dit.csiro.au id AA02936 (5.65c/IDA-1.4.4/DIT-1.3 for info-cvs@prep.ai.mit.edu); Fri, 12 May 1995 00:30:01 +1000 Date: Fri, 12 May 1995 00:30:01 +1000 From: Ian Mathieson Message-Id: <199505111430.AA02936@shark.mel.dit.csiro.au> To: info-cvs@prep.ai.mit.edu Subject: Adding late vendor branches Content-Length: 2014 Status: RO Is there likely to be any problem with adding a vendor branch to a large module in an existing rCVS (1.3) repository? We have two CVS repositories: one (call it R1) within our organisation (where most development goes on - using rCVS); and another outside (call it R2), which has been initialised and updated via imports from R1 (putting exports from R1 on a vendor branch in R2). R1 has development branches, but no vendor branch since nothing has ever been imported (yet). It is now necessary to merge R2 back onto R1 (from time to time). I can see 3 possible solutions: 1. Mutual vendor branches. 2. Use a non-vendor branch in R1 (and perhaps in R2 in future). 3. Ban merges from R2 back to R1. 1. Mutual vendor branches are appealingly symmetric, but are they feasible? Apart from housekeeping issues like keeping track of tag names in 2 places, resolving *minor* collisions, etc, is there likely to be any complication in importing from R2 into R1 at this late stage? Or will there be mass destruction creating (and automatically merging) the 1.1.1 vendor branch? 2. Should I just use a (non-vendor) branch in R1 for merging from R2? The R1toR2 export point is already tagged on R1, so it would be easy to branch from there, overlay the files from an R2 export, commit, tag, and merge back onto the main trunk, etc. However, this is not symmetric with exporting R1 and importing to R2. Maybe I should use this method in both directions, and avoid imports onto R2 in future. 3. Banning merges from R2 back to R1 will slow down development on the R2 platform (and I'll have to do at least one to get them in sync anyway). I presume this problem has been solved before, but a quick scan of the FAQ and the User Guide haven't provided any hints. Many thanks. -- idm. Ian.Mathieson@dit.CSIRO.AU (Dr.) Software Engineer CSIRO Division of Information Technology, Distributed Systems 723 Swanston Street, (TEL) +61-3-9282-2632 Carlton, Victoria 3053, Australia. (FAX) +61-3-9282-2600 From info-cvs-request@prep.ai.mit.edu Sat May 13 21:22:25 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id VAA25043 for ; Sat, 13 May 1995 21:22:19 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24691; Sat, 13 May 95 12:14:25 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA28451; Sat, 13 May 1995 14:14:16 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08111; Sat, 13 May 1995 13:08:07 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA08107; Sat, 13 May 1995 13:08:05 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA27766; Sat, 13 May 1995 14:08:02 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA24374; Sat, 13 May 95 12:08:00 PDT Received: from totoro.bio.indiana.edu by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA25601; Sat, 13 May 95 15:07:35 EDT Received: (from jimb@localhost) by totoro.bio.indiana.edu (8.6.9/8.6.9) id OAA00456; Sat, 13 May 1995 14:07:03 -0500 Date: Sat, 13 May 1995 14:07:03 -0500 From: Jim Blandy Message-Id: <199505131907.OAA00456@totoro.bio.indiana.edu> To: Cyclic CVS Bugs And Info , CVS Info List Cc: Per Cederqvist Subject: ChangeLogs and CVS logs X-Windows: The joke that kills. Content-Length: 11669 Status: RO I've made some changes to pcl-cvs (the Emacs front end for CVS) to make it easier to maintain parallel ChangeLogs and CVS logs. I'd appreciate it if those of you who use pcl-cvs would try it out. I'm interested in bug reports, and especially clumsiness reports --- where does it screw up? Where are there still too many keystrokes involved? How should it behave instead? The only user-visible change is the addition of the following command to CVS mode, bound to the "C" key. cvs-mode-changelog-commit: Check in all marked files, or the current file. Ask the user for a log message in a buffer. This is just like `c', except that it tries to provide appropriate default log messages by looking at the ChangeLogs. To select default log text, we: - find the ChangeLogs for the files to be checked in, - verify that the top entry in the ChangeLog is on the current date and by the current user; if not, we don't provide any default text, - search the ChangeLog entry for paragraphs containing the names of the files we're checking in, and finally - use those paragraphs as the log text. Index: pcl-cvs.el =================================================================== RCS file: /u/src/master/ccvs/contrib/pcl-cvs/pcl-cvs.el,v retrieving revision 1.11 diff -c -r1.11 pcl-cvs.el *** 1.11 1995/05/09 18:56:18 --- pcl-cvs.el 1995/05/09 18:57:48 *************** *** 586,591 **** --- 586,592 ---- \\[cvs-mode-emerge] Run emerge on base revision/backup file. \\[cvs-mode-acknowledge] Delete line from buffer. \\[cvs-mode-ignore] Add file to the .cvsignore file. \\[cvs-mode-log] Run ``cvs log''. \\[cvs-mode-status] Run ``cvs status''. + \\[cvs-mode-changelog-commit] Like \\[cvs-mode-commit], but get default log text from ChangeLog. \\[cvs-mode-undo-local-changes] Revert the last checked in version - discard your changes to the file. Entry to this mode runs cvs-mode-hook. *************** *** 1249,1254 **** --- 1250,1256 ---- (define-key cvs-mode-map "a" 'cvs-mode-add) (define-key cvs-mode-map "b" 'cvs-mode-diff-backup) (define-key cvs-mode-map "c" 'cvs-mode-commit) + (define-key cvs-mode-map "C" 'cvs-mode-changelog-commit) (define-key cvs-mode-map "d" 'cvs-mode-diff-cvs) (define-key cvs-mode-map "e" 'cvs-mode-emerge) (define-key cvs-mode-map "f" 'cvs-mode-find-file) *************** *** 2226,2228 **** --- 2228,2473 ---- (progn (autoload 'pcl-cvs-fontify "pcl-cvs-lucid") (add-hook 'cvs-mode-hook 'pcl-cvs-fontify))) + + + (defvar cvs-changelog-full-paragraphs t + "If non-nil, include full ChangeLog paragraphs in the CVS log. + This may be set in the ``local variables'' section of a ChangeLog, to + indicate the policy for that ChangeLog. + + A ChangeLog paragraph is a bunch of log text containing no blank lines; + a paragraph usually describes a set of changes with a single purpose, + but perhaps spanning several functions in several files. Changes in + different paragraphs are unrelated. + + You could argue that the CVS log entry for a file should contain the + full ChangeLog paragraph mentioning the change to the file, even though + it may mention other files, because that gives you the full context you + need to understand the change. This is the behavior you get when this + variable is set to t. + + On the other hand, you could argue that the CVS log entry for a change + should contain only the text for the changes which occurred in that + file, because the CVS log is per-file. This is the behavior you get + when this variable is set to nil.") + + (defun cvs-changelog-name (directory) + "Return the name of the ChangeLog file that handles DIRECTORY. + This is in DIRECTORY or one of its parents. + Signal an error if we can't find an appropriate ChangeLog file." + (let ((dir (file-name-as-directory directory)) + file) + (while (and dir + (not (file-exists-p + (setq file (expand-file-name "ChangeLog" dir))))) + (let ((last dir)) + (setq dir (file-name-directory (directory-file-name dir))) + (if (equal last dir) + (setq dir nil)))) + (or dir + (error "Can't find ChangeLog for %s" directory)) + file)) + + (defun cvs-narrow-changelog () + "Narrow to the top page of the current buffer, a ChangeLog file. + Actually, the narrowed region doesn't include the date line. + A \"page\" in a ChangeLog file is the area between two dates." + (or (eq major-mode 'change-log-mode) + (error "cvs-narrow-changelog: current buffer isn't a ChangeLog")) + + (goto-char (point-min)) + + ;; Skip date line and subsequent blank lines. + (forward-line 1) + (if (looking-at "[ \t\n]*\n") + (goto-char (match-end 0))) + + (let ((start (point))) + (forward-page 1) + (narrow-to-region start (point)) + (goto-char (point-min)))) + + (defun cvs-changelog-paragraph () + "Return the bounds of the ChangeLog paragraph containing point. + If we are between paragraphs, return the previous paragraph." + (save-excursion + (beginning-of-line) + (if (looking-at "^[ \t]*$") + (skip-chars-backward " \t\n" (point-min))) + (list (progn + (if (re-search-backward "^[ \t]*\n" nil 'or-to-limit) + (goto-char (match-end 0))) + (point)) + (if (re-search-forward "^[ \t\n]*$" nil t) + (match-beginning 0) + (point))))) + + (defun cvs-changelog-subparagraph () + "Return the bounds of the ChangeLog subparagraph containing point. + A subparagraph is a block of non-blank lines beginning with an asterisk. + If we are between subparagraphs, return the previous subparagraph." + (save-excursion + (end-of-line) + (if (search-backward "*" nil t) + (list (progn (beginning-of-line) (point)) + (progn + (forward-line 1) + (if (re-search-forward "^[ \t]*[\n*]" nil t) + (match-beginning 0) + (point-max)))) + (list (point) (point))))) + + (defun cvs-changelog-entry () + "Return the bounds of the ChangeLog entry containing point. + The variable `cvs-changelog-full-paragraphs' decides whether an + \"entry\" is a paragraph or a subparagraph; see its documentation string + for more details." + (if cvs-changelog-full-paragraphs + (cvs-changelog-paragraph) + (cvs-changelog-subparagraph))) + + (defun cvs-changelog-ours-p () + "See if ChangeLog entry at point is for the current user, today. + Return non-nil iff it is." + ;; Code adapted from add-change-log-entry. + (looking-at (concat (regexp-quote (substring (current-time-string) + 0 10)) + ".* " + (regexp-quote (substring (current-time-string) -4)) + "[ \t]+" + (regexp-quote add-log-full-name) + " <" (regexp-quote add-log-mailing-address)))) + + (defun cvs-relative-path (base child) + "Return a directory path relative to BASE for CHILD. + If CHILD doesn't seem to be in a subdirectory of BASE, just return + the full path to CHILD." + (let ((base (file-name-as-directory (expand-file-name base))) + (child (expand-file-name child))) + (or (string= base (substring child 0 (length base))) + (error "cvs-relative-path: %s isn't in %s" child base)) + (substring child (length base)))) + + (defun cvs-changelog-entries (file) + "Return the ChangeLog entries for FILE, and the ChangeLog they came from. + The return value looks like this: + (LOGBUFFER (ENTRYSTART . ENTRYEND) ...) + where LOGBUFFER is the name of the ChangeLog buffer, and each + (ENTRYSTART . ENTRYEND) pair is a buffer region." + (save-excursion + (set-buffer (find-file-noselect + (cvs-changelog-name + (file-name-directory + (expand-file-name file))))) + (goto-char (point-min)) + (if (looking-at "[ \t\n]*\n") + (goto-char (match-end 0))) + (if (not (cvs-changelog-ours-p)) + (list (current-buffer)) + (save-restriction + (cvs-narrow-changelog) + (goto-char (point-min)) + + ;; Search for the name of FILE relative to the ChangeLog. If that + ;; doesn't occur anywhere, they're not using full relative + ;; filenames in the ChangeLog, so just look for FILE; we'll accept + ;; some false positives. + (let ((pattern (cvs-relative-path + (file-name-directory buffer-file-name) file))) + (if (or (string= pattern "") + (not (save-excursion + (search-forward pattern nil t)))) + (setq pattern file)) + + (let (texts) + (while (search-forward pattern nil t) + (let ((entry (cvs-changelog-entry))) + (setq texts (cons entry texts)) + (goto-char (elt entry 1)))) + + (cons (current-buffer) texts))))))) + + (defun cvs-changelog-insert-entries (buffer regions) + "Insert those regions in BUFFER specified in REGIONS. + Sort REGIONS front-to-back first." + (let ((regions (sort regions 'car-less-than-car)) + (last)) + (while regions + (if (and last (< last (car (car regions)))) + (newline)) + (setq last (elt (car regions) 1)) + (apply 'insert-buffer-substring buffer (car regions)) + (setq regions (cdr regions))))) + + (defun cvs-union (set1 set2) + "Return the union of SET1 and SET2, according to `equal'." + (while set2 + (or (member (car set2) set1) + (setq set1 (cons (car set2) set1))) + (setq set2 (cdr set2))) + set1) + + (defun cvs-insert-changelog-entries (files) + "Given a list of files FILES, insert the ChangeLog entries for them." + (let ((buffer-entries nil)) + + ;; Add each buffer to buffer-entries, and associate it with the list + ;; of entries we want from that file. + (while files + (let* ((entries (cvs-changelog-entries (car files))) + (pair (assq (car entries) buffer-entries))) + (if pair + (setcdr pair (cvs-union (cdr pair) (cdr entries))) + (setq buffer-entries (cons entries buffer-entries)))) + (setq files (cdr files))) + + ;; Now map over each buffer in buffer-entries, sort the entries for + ;; each buffer, and extract them as strings. + (while buffer-entries + (cvs-changelog-insert-entries (car (car buffer-entries)) + (cdr (car buffer-entries))) + (if (and (cdr buffer-entries) (cdr (car buffer-entries))) + (newline)) + (setq buffer-entries (cdr buffer-entries))))) + + (defun cvs-edit-delete-common-indentation () + "Unindent the current buffer rigidly until at least one line is flush left." + (save-excursion + (let ((common 100000)) + (goto-char (point-min)) + (while (< (point) (point-max)) + (if (not (looking-at "^[ \t]*$")) + (setq common (min common (current-indentation)))) + (forward-line 1)) + (indent-rigidly (point-min) (point-max) (- common))))) + + (defun cvs-mode-changelog-commit () + + "Check in all marked files, or the current file. + Ask the user for a log message in a buffer. + Try to provide appropriate default log messages from ChangeLogs." + + (interactive) + + (let* ((cvs-buf (current-buffer)) + (marked (cvs-filter (function cvs-committable) + (cvs-get-marked)))) + (if (null marked) + (error "Nothing to commit!") + (pop-to-buffer (get-buffer-create cvs-commit-prompt-buffer)) + (goto-char (point-min)) + + (erase-buffer) + (cvs-insert-changelog-entries + (mapcar (lambda (tin) + (let ((cookie (tin-cookie cvs-cookie-handle tin))) + (expand-file-name + (cvs-fileinfo->file-name cookie) + (cvs-fileinfo->dir cookie)))) + marked)) + (cvs-edit-delete-common-indentation) + + (cvs-edit-mode) + (make-local-variable 'cvs-commit-list) + (setq cvs-commit-list marked) + (message "Press C-c C-c when you are done editing.")))) From info-cvs-request@prep.ai.mit.edu Tue May 16 19:52:31 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA20926 for ; Tue, 16 May 1995 19:52:27 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00473; Tue, 16 May 95 16:46:37 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA12513; Tue, 16 May 1995 18:46:25 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24896; Tue, 16 May 1995 17:32:20 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24892; Tue, 16 May 1995 17:32:18 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA11356; Tue, 16 May 1995 18:32:16 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA28510; Tue, 16 May 95 16:32:12 PDT Received: from nii.ncb.gov.sg ([160.96.6.237]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA20499; Tue, 16 May 95 19:32:08 EDT Received: from bakchang.nii.ncb.gov.sg by nii.ncb.gov.sg (4.1/SMI-4.1) id AA22429; Wed, 17 May 95 07:36:08 SST From: dtayl@nii.ncb.gov.sg (David Taylor) Received: by bakchang.nii.ncb.gov.sg; (5.65/1.1.8.2/17Sep94-0851AM) id AA24101; Wed, 17 May 1995 07:32:19 +0800 Message-Id: <9505162332.AA24101@bakchang.nii.ncb.gov.sg> Subject: Fail to write some RCS files during import (resend) To: info-cvs@prep.ai.mit.edu Date: Wed, 17 May 1995 07:32:19 +0800 (GMT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1546 Status: RO Folks - This is a resend: there were header problems on the previous send, so I'm not sure it reached the list (since I'm not yet on the mailing list - the mail to info-cvs-request probably had header problems also). My apologies if this is duplicated. D.L. Taylor > > Hello CVS fans - > > Problems of a newbie using 1.4A2 on OSF 3.0: > > 1. I import some DOS/Windows files stored on Unix filesystem via > the following command: > > cvs import -m "message" -I! -I\*.exe pc pc tag > > 2. Most files imported OK, but some fail with error: > cvs import: ERROR: cannot write file : Operation > would block. > > >From the CVS source, it looks like the import routine received a file > locked error when it attempted to close the newly written RCS file. > In fact, the RCS file exists and is nonempty. But checkout aborts > with an 'unexpected end of file' error. So it seems the file is indeed > written but not closed. > > But why? There was no other activity at that time and I have exclusive > access. All the aborted files are binaries: DLL, FRM (Visual Basic), etc. > But many of the same type files successfully imported. The problem > continues to occur on imports of other files. > > Does anyone have any clues as to what's going on? I've searched > the FAQ and the info-cvs archive (Oct 94-Mar 95), but no clues. > Any help would be appreciated. Please email dirctly to me - I may mot > be on the mailing list yet. > > thanks, > D.L. Taylor > dtayl@nii.ncb.gov.sg > Singapore National Computer Board > > > > From info-cvs-request@prep.ai.mit.edu Wed May 17 22:52:20 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA11757 for ; Wed, 17 May 1995 22:52:12 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA16931; Wed, 17 May 95 19:48:43 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA23816; Wed, 17 May 1995 21:48:35 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA21407; Wed, 17 May 1995 20:38:54 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA21400; Wed, 17 May 1995 20:38:52 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA15392; Wed, 17 May 1995 19:53:34 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA04286; Wed, 17 May 95 17:53:24 PDT Received: from sartre.minerva.bah.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA25980; Wed, 17 May 95 20:53:21 EDT Received: from whitelabel by sartre.minerva.bah.com (NX5.67d/NX3.0M) id AA01413; Wed, 17 May 95 20:54:49 -0400 Received: by whitelabel.minerva.bah.com.noname (4.1/SMI-4.1) id AA08272; Wed, 17 May 95 20:53:42 EDT Date: Wed, 17 May 1995 20:53:40 -0400 (EDT) From: Jason Haynes To: CVS Info Subject: Alpha (1.4A2) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 417 Status: RO Wow!!! It's beautiful! I just won't tell my boss it's named alpha. Normally I use alpha versions myself, but for my job, I wouldn't have even looked at it. Thanks to your recommendations (everyone who replied said it worked A-OK), I'll be using this much superior version. I don't feel (see) nearly as much a need to run around rewriting things (as perl/shell scripts) anymore, either. Thanks again, Jason From info-cvs-request@prep.ai.mit.edu Thu May 18 01:08:02 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id BAA07512 for ; Thu, 18 May 1995 01:08:01 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27943; Wed, 17 May 95 22:04:10 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA02777; Thu, 18 May 1995 00:04:01 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24605; Wed, 17 May 1995 22:52:43 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24601; Wed, 17 May 1995 22:52:41 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA01846; Wed, 17 May 1995 23:52:40 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA27056; Wed, 17 May 95 21:52:38 PDT Received: from caddy.arnet.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA07581; Thu, 18 May 95 00:52:33 EDT Subject: Binaries with a twist To: info-cvs@prep.ai.mit.edu Date: Wed, 17 May 1995 23:51:34 -0500 (CDT) From: Robert Lipe X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9505172351.aa02907@caddy.arnet.com> Content-Length: 4646 Status: RO Hi. Yes, I'm new on the list. I have dug through the web sites, FAQ, and archives of this list enough to know that the moment I mention the word "binary" and "CVS" in the same sentence that eyes are going to roll. This is a different spin than what I've seen so far, honest. I've spent a little time roaming the alpha versions of 1.4 and 5.6.7, and don't see this being addressed. I've hashed this out with my fellow CVS converts [ really a cool tool - our thanx to the developers! ] and I think we've optimized it down to just a two instances. Imagine the following (real) cases: 1. A project that exists under UNIX but has a handful of (ick) Windows resource files, icons, and the like. These can be manipulated only on the Windows platforms. You have an embedded binary for your DSP code. You need a couple of Xenix binaries in your Unix distribution, but the UNIX you do your main builds on can't generate Xenix binaries. When a cvs update does a merge, diff3 warnings get scribbled in the binaries, substantially trashing your local copy! Diffs/merges on this class of file are impossible. In some cases, the things are generated on another machine, and they may be under CVS control, but that's really of no interest here. It's just a bunch-o-binary-bytes that better be used 100% in order. Version control and rollbacks on this class of files may be interesting and useful. 2. Special files that are generated from files that are reasonable to let CVS control, but require "funny" tools to generate. Examples of this include postscript doco (you want to provide your doco in PS form w/o requiring them to have groff and/or ghostscript to generate/view it), machine generated HTML text, or C array versions of embedded binaries. In this case, you really don't care about history, just being able to always provide the "top" version without concern about rollback versions would be adequate. If you *really* wanted to pull something besides the top level, you could regenerate it using the tools [ which probably only you have ], but the common case (person wants to do a cvs checkout ; make ) is covered without elaborate toolset requirements. Diffs/merges on this class of file are possible, but impractical. It requires a large amount of repository storage. You can run around and do a 'cvs admin -o' every once in a while, which helps some. Updates and collisions are non-interesting, becuase it's handled in the files that generate this class of file. The proposals that have been kicked around include [ don't haggle with the exact symantics yet ] : 1. A flag to 'cvs add'. cvs add --binary. This sets a flag in Entries until the first commit, then as part of the filename after that (?) We'd discussed just making rcsmerge aware of this flag, and letting it always return the newest file. Or we could bypass RCS altogether and just call cp. :-) Collisions with this approach are very bad. He Who Checks In Last gets to keep his work. 2. Modifiers on #1: cvs add --binary --generations 10 file Keep the last 10 versions expendable versions of file in the repository, collapsing/losing the RCS information for all previous generations. Don't do deltas ever. cvs commit --permanent file Commit the file, excluding it from the count above. This way, you could keep released versions as a packagable/taggable entity w/o keeping all the development versions. 3. In a recent discussion with David 'Zoo' Zuhn, he suggested letting a set of makefile rules for each project copy things in/out of a repository, uninvolving CVS/RCS totally. This is not a terrible approach, but probably involves duplicating the logic to insure atomicity for a checkin in each project. We're prepared to open up CVS and/or RCS and make the changes necessary if there isn't already someone working on similar functionality. As good net.citizens, we are interested in the views of the maintainers and users. Hopefully, if we are able to strike a useful combination here, this would be welcomed (ok, we'll settle for "accepted" or even "tolerated" :-) by the maintainers and used by some sites. If we create a Frankenstien version of the tools, we've helped no one but ourselves. Tips, suggestions, pointers to prior art or works in progress and challenges are welcomed. Arguments of why no sane person would ever want to do this are not. Thanx! -- Robert Lipe, Sr. Software Engr, Arnet Corp. robertl@arnet.com From info-cvs-request@prep.ai.mit.edu Fri May 19 18:48:18 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA26288 for ; Fri, 19 May 1995 18:48:17 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18350; Fri, 19 May 95 15:45:36 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA16095; Fri, 19 May 1995 17:45:25 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24721; Fri, 19 May 1995 16:32:42 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24717; Fri, 19 May 1995 16:32:40 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA15753; Fri, 19 May 1995 17:32:39 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA16231; Fri, 19 May 95 15:32:24 PDT Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA24182; Fri, 19 May 95 18:32:18 EDT Received: from monad.armadillo.com (zoo@monad.armadillo.com [199.199.0.1]) by monad.armadillo.com (8.6.12/8.6.12) with ESMTP id RAA23888; Fri, 19 May 1995 17:32:07 -0500 Message-Id: <199505192232.RAA23888@monad.armadillo.com> From: "david d `zoo' zuhn" Organization: armadillo zoo software -- +1 500 DOS BITES (really) To: Robert Lipe Cc: "david d `zoo' zuhn" , awasser@hermes.sgc.com, info-cvs@prep.ai.mit.edu Subject: Re: Binaries with a twist In-Reply-To: Your message of "Fri, 19 May 1995 15:00:23 CDT." <9505191500.aa08062@caddy.arnet.com> X-Punishment: The principal's toupee is not a frisbee. Date: Fri, 19 May 1995 17:32:03 -0500 Sender: zoo@armadillo.com Content-Length: 1177 Status: RO // could we jam this flag into the filename? [ reluctance to do so to // support systems with short/limited filenames noted in advance] This would entail new restrictions on what filenames are acceptable for CVS. I think most people wouldn't like this. It's also a kludge. // Alternately, each directory in the repository could contain a // "control.CVS" file that might have lines that look like [...] You've just described part of the functioning of the rename database. Several pieces of information should be stored in such a database. See http://www.armadillo.com/info-cvs/9410/0031.html (and related articles under http://www.armadillo.com/info-cvs/9410/) for some discussion about the rename database (which I tend to call the PDDB - per directory data base) // Maybe instead of the "K" option described above, just "run external // program on file during checkin/out". This could also be used to solve // the DOS/UNIX fileformat conflicts. You mean the -i and -o options to the modules file? Some of the modules file capabilities are somewhat difficult to use because of the need to edit the modules file as opposed to some programmatic interface. From info-cvs-request@prep.ai.mit.edu Fri May 19 21:33:39 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id VAA20222 for ; Fri, 19 May 1995 21:33:38 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09625; Fri, 19 May 95 18:30:33 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA05128; Fri, 19 May 1995 20:30:24 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00194; Fri, 19 May 1995 19:20:06 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00189; Fri, 19 May 1995 19:20:05 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA03743; Fri, 19 May 1995 20:20:04 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA08596; Fri, 19 May 95 18:19:54 PDT Received: from cs.umb.edu by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA02388; Fri, 19 May 95 21:19:51 EDT Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA28178 (5.65c/IDA-1.4.4 for ); Fri, 19 May 1995 20:55:09 -0400 Message-Id: <199505200055.AA28178@cs.umb.edu> To: info-cvs@prep.ai.mit.edu Subject: Re: Binaries with a twist In-Reply-To: Your message of "Fri, 19 May 1995 17:29:00 EDT." Date: Fri, 19 May 1995 20:54:55 -0400 From: "John P. Rouillard" Content-Length: 2876 Status: RO In message , Greg A. Woods writes: >[ On Fri, May 19, 1995 at 15:00:23 (-0500), Robert Lipe wrote: ] >> Subject: Re: Binaries with a twist >> >> david d `zoo' zuhn writes: couple of months ago. The problem is >> > that there is currently no place to store this information. We >> > could use an RCS extension, but that extension isn't too likely >> > to be accepted into baseline sources. This should go into the >> > rename database, but that doesn't exist either. >> >> Not too likely to be accepted into the baseline sources for RCS or >> those for CVS? > >I'm not so sure the RCS folks wouldn't accept a 'binary' flag. I'm sure >they're facing lots of pressure from various fronts to do so. >> >> If the problem is resistance to change RCS to suit >> this need, could we jam this flag into the filename? [ reluctance to >> do so to support systems with short/limited filenames noted in advance] >> Alternately, each directory in the repository could contain a >> "control.CVS" file that might have lines that look like >> >> B foobar.bin,v >> >> Before cvs invokes rcsmerge, it could look in this file and see that >> "Oh, this is a 'B' file, better not do that". This is also where the >> keep-n-generations info could be kept. > >Yup, this isn't a bad alternative. Lots of things could be done here, >esp. with some extensible file format.... Well don't we really have one built into cvs by overloading a tag or the file description information? If the tag CVSFLAGS_BINARY is assigned to revision 1.1 then cvs treats the file as binary (and should set -ko as the default keyword expansion flag). Alternatively in the file description info (set with rcs -t for example) we could declare that if the last line of the description is: CVSFLAGS_BINARY then we treat the file as binary. Either idea could be expanded to set up merge programs: CVSFLAGS_MERGEUSING_v1~4_foobar_merge where foobar_merge is an appropriate shell script that takes the diff3 style arguments. It will exist on all platforms that can be expected to merge the code. If we use a tag based scheme, the tag can be applied to an actual revision number so we have the ability to change the merge program based on file revision, or attempt to so some sort of serach for a suitable merge program by backtracking the ancestor tree. Quips, comments, evasions, questions or answers? -- John John Rouillard Senior Systems Administrator IDD Information Services rouilj@dstar.iddis.com Waltham, MA (617) 890-7227 x337 (617) 487-3937 (Direct) Senior Systems Consultant (SERL Project) University of Massachusetts at Boston rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480 =============================================================================== My employers don't acknowledge my existence much less my opinions. From info-cvs-request@prep.ai.mit.edu Fri May 19 15:34:33 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA09871 for ; Fri, 19 May 1995 15:34:32 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14390; Fri, 19 May 95 12:31:32 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA06273; Fri, 19 May 1995 14:30:58 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13211; Fri, 19 May 1995 13:19:26 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13207; Fri, 19 May 1995 13:19:25 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA05609; Fri, 19 May 1995 14:19:22 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA12219; Fri, 19 May 95 12:19:20 PDT Received: from bou.shl.com (merlin.bou.shl.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12694; Fri, 19 May 95 15:19:16 EDT Received: from whatnow by bou.shl.com (NX5.67d/NX3.0Ma) id AA05294; Fri, 19 May 95 13:18:38 -0600 Message-Id: <9505191918.AA05294@bou.shl.com> Received: by whatnow.bou.shl.com (NX5.67e/NX3.0X) id AA06076; Fri, 19 May 95 13:18:36 -0600 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Vince Demarco Date: Fri, 19 May 95 13:18:30 -0600 To: info-cvs@prep.ai.mit.edu Subject: wrappers References: <9505191513.AA10905@hermes> Content-Length: 948 Status: RO Andrew Athan, made a bunch of patches to allow directories stored here is the description This package was written to support the NeXTSTEP concept of "wrappers." These are essentially directories that are to be treated as "files." This package allows such wrappers to be "processed" on the way in and out of CVS. The intended use is to wrap up a wrapper into a single tar, such that that tar can be treated as a single binary file in CVS. To solve the problem effectively, it was also necessary to be able to prevent rcsmerge application at appropriate times. I'm going to port this stuff over to CVS 1.4. I'm just sending this out to make sure people aren't duplicating effort. I'll send the patches up here. This method might also be used (maybe) to convert binary files to text before processing (frame files to mif files etc) and unconvert them on the way out. It has lots of other possible uses (IMHO) vince From info-cvs-request@prep.ai.mit.edu Sat May 20 16:47:44 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA08911 for ; Sat, 20 May 1995 16:47:39 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28788; Sat, 20 May 95 13:45:26 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA06360; Sat, 20 May 1995 15:45:16 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA26363; Sat, 20 May 1995 14:34:54 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA26359; Sat, 20 May 1995 14:34:52 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA05172; Sat, 20 May 1995 15:34:51 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA28205; Sat, 20 May 95 13:34:49 PDT Received: from aimnet.com (aimnet.aimnet.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA06894; Sat, 20 May 95 16:34:45 EDT Received: from aplysia.iway.aimnet.com (kevin@dial-sf1-10.iway.aimnet.com [204.118.64.10]) by aimnet.com (8.6.12/8.6.12) with ESMTP id NAA04092; Sat, 20 May 1995 13:32:56 -0700 Received: (from kevin@localhost) by aplysia.iway.aimnet.com (8.6.10/8.6.10) id NAA11542; Sat, 20 May 1995 13:35:07 -0700 Date: Sat, 20 May 1995 13:35:07 -0700 From: Kevin Dalley Message-Id: <199505202035.NAA11542@aplysia.iway.aimnet.com> To: jason@whitelabel.minerva.bah.com, info-cvs@prep.ai.mit.edu In-Reply-To: (message from Jason Haynes on Wed, 17 May 1995 20:53:40 -0400 (EDT)) Subject: Re: Alpha (1.4A2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 1002 Status: RO Unfortunately, rcs-5.6.7.4 is not quite perfect. I have used it slightly, but found a couple of problems when porting it. rcs-5.6.7.4 was not quite ready for an old ISI using BSD which I ported to. It was simple to port it, but the problems suggested that few people have used that port yet. Paul Eggert seems quite willing to incorporate fixes to solve this problem. In addition to this problem, "rcs -o" does not work at all on this platform. Another small change fixed this problem, which was also reported to the proper email address. These problems were enough for me to suggest using rcs-5.6.0.1, rather than rcs-5.6.7.4 for my project. This company is quite conservative, perhaps slow, and was still using rcs-5.5. Some people were very suspicious about change. While many other people have success with rcs-5.6.7.4, be aware that it is a beta product and there may be minor problems. Your platforms may make a difference. Of course, the same is true of rcs-5.6.0.1. kevin dalley From info-cvs-request@prep.ai.mit.edu Sat May 20 04:17:42 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA08462 for ; Sat, 20 May 1995 04:17:36 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02635; Sat, 20 May 95 01:15:11 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA18039; Sat, 20 May 1995 03:15:02 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10224; Sat, 20 May 1995 02:11:58 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10220; Sat, 20 May 1995 02:11:57 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA17746; Sat, 20 May 1995 03:11:56 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA02488; Sat, 20 May 95 01:11:49 PDT Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13080; Sat, 20 May 95 04:11:43 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA06749; Sat, 20 May 95 01:15:34 PDT Date: Sat, 20 May 95 01:15:34 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9505200815.AA06749@sander.sander.cupertino.ca.us> To: awasser@hermes.sgc.com, robertl@arnet.com Subject: Re: Binaries with a twist Cc: info-cvs@prep.ai.mit.edu Content-Length: 2237 Status: RO Robert Lipe wrote: >Adam Wasserman writes: >> > 1. A flag to 'cvs add'. cvs add --binary. This sets a flag in... >> [ lots of other stuff about binaries in cvs ] >> >> Maybe I'm missing something significant, but isn't >> >> cvs add filename >> cvs admin -ko filename >> >> essentially the same as >> >> cvs add --binary filename >No, although my proposed mechanism would probaly do the cvs admin -ko >for you automatically. >All that admin -ko does for you, as I understand it, is to stop RCS >from expanding the keywords when you check in/out. What it does is ensure that when a revision is checked out, it is bit-for-bit identical to what was checked in, even in the presence of RCS keywords. This is indeed a necessary feature to store binary files under CVS, and it has in fact been used to that end reliably under CVS 1.3. Note that the -ko default must be set in the RCS file, not in CVS' sticky state. Since the RCS file header is read during an update, this setting is available to determine if a merge is possible. (It's not a good indicator, because merges may be possible even if the -ko default is set, but it can be taken for granted that a merge is possible if something other than -ko is set.) If -ko is set, another mechanism can be used to decide if a merge is possible, e.g. by asking the user if he desires one. Another possibility is to use an RCS feature that is otherwise unused, like the version state of version 1.1. >My proposal would stop cvs/rcsmerge from doing nasty things to >filename during a cvs update. It may discourage cvs/rcs from >attempting to represent filename as a diff altogether. The idea is >that a file with this attribute should be treated as an atomic chunk. >Taking n bytes from version x and m bytes from version y and folding >them together is probably futile. Diffs can still be a space-saving optimization with binary files. The manner in which RCS stores diffs makes the worst case diff be a matter of tens of bytes larger than storing the revisions in separate files like SCCS does. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Sat May 20 12:33:10 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA01132 for ; Sat, 20 May 1995 12:33:08 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20090; Sat, 20 May 95 09:30:24 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA09394; Sat, 20 May 1995 11:30:16 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19659; Sat, 20 May 1995 10:20:38 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19655; Sat, 20 May 1995 10:20:36 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA08338; Sat, 20 May 1995 11:20:35 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA19740; Sat, 20 May 95 09:20:23 PDT Received: from boulder.Colorado.EDU by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA26163; Sat, 20 May 95 12:20:17 EDT Received: from hemlock. (hemlock.Colorado.EDU [128.138.232.50]) by boulder.Colorado.EDU (8.6.12/8.6.12/UnixOps) with SMTP id KAA06784; Sat, 20 May 1995 10:20:10 -0600 Received: by hemlock. (cu.generic.890828) From: Tom Tromey Received: by cambric id ; Fri, 19 May 95 21:42:05 MDT Date: Fri, 19 May 95 21:42:05 MDT Message-Id: <9505200342.AA01091@cambric> To: "John P. Rouillard" Cc: info-cvs@prep.ai.mit.edu Subject: Re: Binaries with a twist In-Reply-To: <199505200055.AA28178@cs.umb.edu> References: <199505200055.AA28178@cs.umb.edu> X-Zippy: Well, O.K. I'll compromise with my principles because of EXISTENTIAL DESPAIR! X-Attribution: Tom Content-Length: 1820 Status: RO >>>>> "John" == John P Rouillard writes: John> Either idea could be expanded to set up merge programs: John> CVSFLAGS_MERGEUSING_v1~4_foobar_merge John> where foobar_merge is an appropriate shell script that takes the John> diff3 style arguments. It will exist on all platforms that can John> be expected to merge the code. John> If we use a tag based scheme, the tag can be applied to an John> actual revision number so we have the ability to change the John> merge program based on file revision, or attempt to so some sort John> of serach for a suitable merge program by backtracking the John> ancestor tree. John> Quips, comments, evasions, questions or answers? We went through this same discussion in March or so. One idea that came out was to specify file type instead of merge program. Then the CVS client program could decide what merge program to run based on the type. Eventually CVS will be a client/server program. Specifying file type instead of program lets the same modules be used by many different clients. Also, it makes it very easy for each user to specify his own merge program. (Eg I'd want to use emerge in Emacs. But someone else might want to do things the way they are done now, and someone else might want to use Sun's filemerge, or whatever) Tag-based schemes were discussed last time, too, but I don't remember what (if any) conclusions were reached. Anyway, while I think that support for binary files might be useful, I'd much prefer to see a more general solution. Those who have the time to do serious work on CVS might consider doing the "full pull". Tom -- tromey@drip.colorado.edu Member, League for Programming Freedom Let no one tell me that silence gives consent, because whoever is silent dissents. -- Maria Isabel Barreno From info-cvs-request@prep.ai.mit.edu Tue May 23 10:34:32 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA28553 for ; Tue, 23 May 1995 10:34:26 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA01491; Tue, 23 May 95 07:31:07 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA13054; Tue, 23 May 1995 09:30:58 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19527; Tue, 23 May 1995 08:18:56 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19523; Tue, 23 May 1995 08:18:54 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA12430; Tue, 23 May 1995 09:18:52 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA29652; Tue, 23 May 95 07:18:43 PDT Received: from slsa02t.stgl.netd.alcatel.de by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA07269; Tue, 23 May 95 10:18:35 EDT Received: from slbh01t1.bln.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <29297-0@slsa02t.stgl.netd.alcatel.de>; Tue, 23 May 1995 16:18:42 +0200 Received: from slbh04 by bln.sel.alcatel.de (4.1/SMI-4.0/DNI-7.0.1/blume_h-1.2) id AA20002; Tue, 23 May 95 16:18:24 +0200 From: Uwe.Graichen@bln.sel.alcatel.de (U. Graichen) Received: by slbh04 (4.1) id AA26112; Tue, 23 May 95 16:18:22 +0200 Date: Tue, 23 May 95 16:18:22 +0200 Message-Id: <9505231418.AA26112@slbh04> To: info-cvs@prep.ai.mit.edu Subject: core dump during commit (cvs1.3) Content-Length: 827 Status: RO Hi, following command sequence produces a core dump cvs commit dir/file1 dir/file2 dir/file3 1.) the editor is invoked for the commit message for the changed files 2.) the editor is invoked again, but no files are listed (one ore two times) 3.) a core dump is produced (CVS 1.3, rcs 5.6.0.1) CVS seams to come in conflicts with the directories, although 'dir' is allways the same in the test. Is this a known bug, exists a patch anywhere? CVS 1.4 works correctly. Thanks for help and spending time. --uwe +========= Uwe Graichen / ALCATEL SEL AG Berlin ===================+ Email: graichen@bln.sel.alcatel.de ( Expressed opinions which happen to ) correspond with those of my employer Phone: +49 30 7002 3399 ( are still my own. The others are mine. From info-cvs-request@prep.ai.mit.edu Tue May 30 19:01:34 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA32189 for ; Tue, 30 May 1995 19:01:29 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA06799; Tue, 30 May 95 15:47:28 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA12291; Tue, 30 May 1995 17:47:05 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01810; Tue, 30 May 1995 16:31:24 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01803; Tue, 30 May 1995 16:31:22 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA11522; Tue, 30 May 1995 17:31:21 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA03585; Tue, 30 May 95 15:31:18 PDT From: athan@morgan.com Received: from gateway.morgan.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA09238; Tue, 30 May 95 18:31:16 EDT Received: from rs1.fid.morgan.com ([138.20.1.17]) by gateway.morgan.com with SMTP id <41507>; Tue, 30 May 1995 18:31:01 -0400 Received: from sait136.morgan.com by rs1.fid.morgan.com (4.1/MS/FID/Sun-1.3) id AA19729; Tue, 30 May 95 18:27:57 EDT Received: by sait136.morgan.com (NX5.67e/NX3.0S) id AA01841; Tue, 30 May 95 18:23:55 -0400 Date: Tue, 30 May 1995 18:23:55 -0400 Message-Id: <9505302223.AA01841@sait136.morgan.com> To: info-cvs@prep.ai.mit.edu Subject: CVS/RCS enhancements Cc: athan@morgan.com Content-Length: 1975 Status: RO I'm finding myself with a bit of free time these days and am interested in enhancing the CVS package. E.g., I recently released to comp.sys.next.programmer an enhancement that allows for the application of a script to files & directories during the checkin and checkout process. This makes CVS usable with NeXTSTEP projects, which use bundles/wrappers [i.e., directories which should be treated on the whole, as files]. The patches have been submitted for consideration as part of CVS1.4. Forgive me if there are already discussions under way about any of this, but if so, and you have archives, let me know! I know I saw some (all?) of these mentioned in the FAQ. There are a number of features which I think would be worthwhile additions to the standard CVS distribution, including: Speed! Perhaps RCS could be modified to have an interactive mode and/or operate in client/server mode. This would allow CVS to do its tasks without constantly spawning new processes. File management (Configuration management?) Formalize and expand the definition of a CVS module and allow specification of such in an external file. E.g., allow widely scattered files to come from the same "module." In the process, enhance CVS's ability to deal with file deletion, renaming, etc. The module specification file would become a revision controlled file which is part of the module. Remote capabilities The ability to interact with CVS repositories using either a tightly coupled network based client/server model or mail (preferably both). "Adaptorization" Make RCS/CVS slightly less tightly coupled. I.e., make sure CVS uses an API to the back end revision control system (RCS) which is like a black box. Ideally, the API should be as independent of specific RCS features as possible. This would allow for the replacement of RCS with (for example) site-specific tools that use relational databases etc. aca athan@morgan.com From info-cvs-request@prep.ai.mit.edu Mon May 29 15:04:23 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA05750 for ; Mon, 29 May 1995 15:04:22 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA13018; Mon, 29 May 95 00:46:32 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA17968; Mon, 29 May 1995 02:46:26 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18558; Mon, 29 May 1995 01:33:46 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18554; Mon, 29 May 1995 01:33:45 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA17887; Mon, 29 May 1995 02:33:44 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA12059; Mon, 29 May 95 00:33:42 PDT Received: from cs.utexas.edu by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA02942; Mon, 29 May 95 03:33:40 EDT Received: from [128.83.112.159] (slip-31-15.ots.utexas.edu [128.83.112.159]) by cs.utexas.edu (8.6.12/8.6.9) with SMTP id CAA09171 for ; Mon, 29 May 1995 02:33:30 -0500 X-Sender: osiris@mailbox.cs.utexas.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 May 1995 02:33:38 -0500 To: info-cvs@prep.ai.mit.edu From: osiris@cs.utexas.edu (Rob Browning) Subject: Re: Problem making cvs-1.4A2 under MachTen (solved) Content-Length: 420 Status: RO I had some problems building cvs-1.4A2 under MachTen (a BSD unix for the Mac). Paige Niederer suggested the following: >Add the "-DDIRENT" definition on the DEFS line in the makefiles. I had >the same problem compliling on UnixWare. > >That should solve your problem. > >Paige Niederer >niederer@ftc.nrcs.usda.gov This fixed the problem. Actually, only src/Makefile needed the flag. Thanks for the help, --Rob. From info-cvs-request@prep.ai.mit.edu Fri May 26 13:38:03 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA30093 for ; Fri, 26 May 1995 13:37:56 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02138; Fri, 26 May 95 10:16:46 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA28714; Fri, 26 May 1995 12:16:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00876; Fri, 26 May 1995 11:08:18 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00870; Fri, 26 May 1995 11:08:16 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA28315; Fri, 26 May 1995 12:08:14 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA00199; Fri, 26 May 95 10:08:11 PDT Received: from starfleet.nrcs.usda.gov.nrcs.usda.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA23801; Fri, 26 May 95 13:08:07 EDT Received: by starfleet.nrcs.usda.gov.nrcs.usda.gov (8.6.9/SMI-4.1) id RAA03681; Fri, 26 May 1995 17:03:05 GMT Date: Fri, 26 May 1995 11:03:04 -0600 (MDT) From: Paige Niederer To: Rob Browning Cc: info-cvs@prep.ai.mit.edu Subject: Re: Problem making cvs-1.4A2 under MachTen In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 2568 Status: RO *--------------------------------------------------------------------------* |Paige A. Niederer niederer@ftc.nrcs.usda.gov| |USDA - NRCS (970) 282-2462 | |Computer Scientist - Technical Services Team | |2625 Redwing Dr. | |Fort Collins, CO 80526 | *--------------------------------------------------------------------------* On Fri, 26 May 1995, Rob Browning wrote: > I sent this to cvs-bug, but I thought that I'd send it here in case the > people on this list could help. If this is inappropriate, please let me > know. > > > raven:~/cvs-1.4A2] make > making all in lib > making all in src > gcc -I.. -I. -I../lib -DHAVE_CONFIG_H -g -O -c find_names.c > find_names.c: In function `find_rcs': > find_names.c:168: `DIR' undeclared (first use this function) > find_names.c:168: (Each undeclared identifier is reported only once > find_names.c:168: for each function it appears in.) > find_names.c:168: `dirp' undeclared (first use this function) > find_names.c:175: warning: assignment makes pointer from integer without a cast > find_names.c:177: dereferencing pointer to incomplete type > find_names.c:181: dereferencing pointer to incomplete type > find_names.c:185: dereferencing pointer to incomplete type > find_names.c: In function `find_dirs': > find_names.c:208: `DIR' undeclared (first use this function) > find_names.c:208: `dirp' undeclared (first use this function) > find_names.c:215: warning: assignment makes pointer from integer without a cast > find_names.c:217: dereferencing pointer to incomplete type > find_names.c:218: dereferencing pointer to incomplete type > find_names.c:219: dereferencing pointer to incomplete type > find_names.c:220: dereferencing pointer to incomplete type > find_names.c:230: dereferencing pointer to incomplete type > find_names.c:233: dereferencing pointer to incomplete type > find_names.c:259: dereferencing pointer to incomplete type > find_names.c:263: dereferencing pointer to incomplete type > find_names.c:272: dereferencing pointer to incomplete type > *** Exit 1 > Stop. > *** Exit 1 > Stop. > > > Thanks, > > --Rob > ================================================================== > > > Add the "-DDIRENT" definition on the DEFS line in the makefiles. I had the same problem compliling on UnixWare. That should solve your problem. Paige Niederer niederer@ftc.nrcs.usda.gov From info-cvs-request@prep.ai.mit.edu Tue May 23 23:27:28 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA13374 for ; Tue, 23 May 1995 23:27:20 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA11240; Tue, 23 May 95 20:15:44 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA07656; Tue, 23 May 1995 22:15:35 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24622; Tue, 23 May 1995 21:03:18 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24618; Tue, 23 May 1995 21:03:16 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA06326; Tue, 23 May 1995 22:03:09 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA09672; Tue, 23 May 95 20:02:28 PDT Received: from markv.com (hermix.markv.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA27107; Tue, 23 May 95 23:01:32 EDT To: info-cvs@prep.ai.mit.edu In-Reply-To: <199505231452.JAA01814@monad.armadillo.com> (zoo@armadillo.com) Subject: 1.4 "alpha" Reply-To: Don Dwiggins Date: Tue, 23 May 95 19:58:22 PDT From: dwig@markv.com Sender: dwig@markv.com Message-Id: <9505231958.aa25498@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. Content-Length: 588 Status: RO > Yes, this is a known bug. I don't know of any separate patch file for this > bug. Yes, 1.4 has it fixed. I suggest using 1.4A2 for daily use. It's > got a number of other bugs fixed too. When, and under what conditions, will the "alpha" label be removed from 1.4? There are many of us using it successfully to manage the "corporate jewels" on a daily basis with no more trouble than, say, many Microsoft products. Would it be rash to suggest it's ready for Beta? Don Dwiggins, Beta Version 0.8 (Version 1.0 due for release Real Soon Now) SEI Information Technology dwig@markv.com From info-cvs-request@prep.ai.mit.edu Wed May 24 00:27:33 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id AAA29554 for ; Wed, 24 May 1995 00:27:31 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA16472; Tue, 23 May 95 21:15:48 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA14298; Tue, 23 May 1995 23:15:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA26217; Tue, 23 May 1995 22:10:58 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA26213; Tue, 23 May 1995 22:10:56 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA13759; Tue, 23 May 1995 23:10:55 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA16027; Tue, 23 May 95 21:10:44 PDT Received: from Sun.COM by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA03555; Wed, 24 May 95 00:10:26 EDT Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA15996; Tue, 23 May 95 21:10:23 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA13701; Tue, 23 May 1995 23:10:21 -0500 Received: from bilge.Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA26205; Tue, 23 May 1995 22:10:20 -0600 Received: from bilge (localhost) by bilge.Central.Sun.COM (5.x/SMI-SVR4) id AA19593; Tue, 23 May 1995 22:10:19 -0600 Message-Id: <9505240410.AA19593@bilge.Central.Sun.COM> To: Don Dwiggins Cc: info-cvs@prep.ai.mit.edu Subject: Re: 1.4 "alpha" In-Reply-To: dwig@markv.com's message of Tue, 23 May 1995 19:58:22 PDT. Date: Tue, 23 May 1995 22:10:18 MDT From: Brian Berliner Content-Length: 787 Status: RO > On Tue, 23 May 95 19:58:22 PDT, dwig@markv.com said: > When, and under what conditions, will the "alpha" label be removed from > 1.4? There are many of us using it successfully to manage the "corporate > jewels" on a daily basis with no more trouble than, say, many Microsoft > products. Would it be rash to suggest it's ready for Beta? In my "opinion", it won't be Beta until the feature set has been finalized. The current Alpha-2 release is not the end of the feature set for CVS 1.4. I've handed my code off to david d `zoo' zuhn for final productization which may get us real close to a Beta release. So, the next stuff that gets announced might be Beta or it might be Alpha. It kinda depends on whether more features are to be crammed into 1.4 or not. Stay tuned. -Brian From info-cvs-request@prep.ai.mit.edu Wed May 31 09:20:48 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA21937 for ; Wed, 31 May 1995 09:20:45 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA06742; Wed, 31 May 95 06:02:47 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA17032; Wed, 31 May 1995 08:02:36 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04457; Wed, 31 May 1995 06:53:38 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04452; Wed, 31 May 1995 06:53:36 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA15860; Wed, 31 May 1995 07:53:35 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA05422; Wed, 31 May 95 05:53:26 PDT Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA16821; Wed, 31 May 95 08:53:18 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA26068; Wed, 31 May 1995 08:52:42 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA11995; Wed, 31 May 95 08:52:33 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id IAA02249; Wed, 31 May 1995 08:52:32 -0400 Date: Wed, 31 May 1995 08:52:32 -0400 Message-Id: <199505311252.IAA02249@kayak.odi.com> To: ives@sonytel.be Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9505311123.ZM27550@retina.sonytel.be> (ives@retina.sonytel.be) Subject: Re: Growing CVSROOT Reply-To: dgg@odi.com Content-Length: 1291 Status: RO > Hi, > > I've been using cvs 1.3 for a while now and I've noticed > that my CVSROOT/commitlog and CVSROOT/history files are > starting to get *big*. > > What exactly is the information in these files used for, > and can I get them back to a more modest size without > losing too much ? > > Thanks in advance for your help. There is a "cln_hist" command in the contrib area. Understand it before you try it. What it does is: Record type Disposition (i.e. first letter) M odified Keep A dded Keep R emoved Keep T ag You can keep all of them, but it is really only necessary to keep the last tag on the same module. O ut (checkout) F ree (release) Strip out matching pairs. You only need to keep the last 'O'. C onflict You *might* want to keep these records of conflict. W (???) G MerGe W and G indicate transient phenomenon. Unless you are doing something odd, just delete them. U pdate The majority of the lines in *my* history file are "U" records, which indicate that a file was updated. They are useful for a while, if you are trying to track whether people are updating changes into their working directories. Otherwise delete them. Run "cln_hist", then run a "diff". If you want to be save, compress and archive the original file. From info-cvs-request@prep.ai.mit.edu Thu Jun 1 07:38:45 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id HAA07284 for ; Thu, 1 Jun 1995 07:38:45 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24631; Thu, 1 Jun 95 04:33:18 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA07731; Thu, 1 Jun 1995 06:33:01 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10126; Thu, 1 Jun 1995 05:17:13 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10121; Thu, 1 Jun 1995 05:17:12 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA06703; Thu, 1 Jun 1995 06:17:09 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA23308; Thu, 1 Jun 95 04:17:08 PDT Received: from snex11.senet.abb.se by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA00797; Thu, 1 Jun 95 07:17:02 EDT Received: from localhost by snex11.senet.abb.se; (5.65/1.1.8.2/03Oct94-0154PM) id AA08465; Thu, 1 Jun 1995 13:20:40 +0200 Message-Id: <9506011120.AA08465@snex11.senet.abb.se> To: info-cvs@prep.ai.mit.edu Cc: gtornblo@senet.abb.se Subject: cvs release does not accept filename (a resend) Date: Thu, 01 Jun 95 13:20:39 +0200 From: gtornblo@senet.abb.se X-Mts: smtp Content-Length: 1654 Status: RO This was posted to the list by me 30-MAY-1995. Unfortunately the Internet connection broke down short thereafter and has been gone until now. My apologize if this is a repeated message. If you already replied please send a copy of your reply to me directly. My message was: Hi all Im running CVS 1.4a2 an a DEC alpha, OSF1 3.0 and I have the following question: CVS commands commit and checkin accepts filenames. I.e. if the specified argument is not found in the modules file it will accept it as a filename if it can find information about it in the CVS dir of the specified path. Why does not CVS release follow the same rules ? Is there a reason or a patch ? example: snem86> pwd /proj/migt/ville/.spicm snem86> ls a2 b1 d1 jctools ls snem86>ls a2/source CVS a50adf.c a50adf.c~ spicm_cvsini snem86> more a2/source/CVS/Entries /spicm_cvsini/1.1/Mon Apr 17 09:11:10 1995// /a50adf.c/1.1.2.3/Tue May 30 11:51:02 1995//Tlatest_migt snem86>cvs co a2/source/a50adf.c U a2/source/a50adf.c snem86>cvs release a2/source/a50adf.c cvs release: no such directory/module: a2/source/a50adf.c Thanks! /Gunnar P.S. Since I posted this I have found an alternative to "cvs release" that does what I want: cvs co -r [nonexisting tag] [path]/file this command will remove any existing entry for 'file' from CVS/Entries and then give an error message: cvs checkout: [path]/file is no longer in the repository The important thing here, the 'release' function, is that the CVS/Entries is removed and in this case I can throw away the error message But this is probably not an intended way to release a file ... From info-cvs-request@prep.ai.mit.edu Thu Jun 1 10:14:41 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA12000 for ; Thu, 1 Jun 1995 10:14:39 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA11778; Thu, 1 Jun 95 07:08:29 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA19511; Thu, 1 Jun 1995 09:08:12 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14635; Thu, 1 Jun 1995 07:47:02 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14630; Thu, 1 Jun 1995 07:47:00 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA17432; Thu, 1 Jun 1995 08:46:59 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA07531; Thu, 1 Jun 95 06:46:54 PDT Received: from mineshaft.odi.com ([198.3.16.17]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA04269; Thu, 1 Jun 95 09:46:51 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA05663; Thu, 1 Jun 1995 08:52:08 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA05904; Thu, 1 Jun 95 08:52:01 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id IAA13938; Thu, 1 Jun 1995 08:52:01 -0400 Date: Thu, 1 Jun 1995 08:52:01 -0400 Message-Id: <199506011252.IAA13938@kayak.odi.com> To: gtornblo@senet.abb.se Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9506011120.AA08465@snex11.senet.abb.se> (gtornblo@senet.abb.se) Subject: Re: cvs release does not accept filename (a resend) Reply-To: dgg@odi.com Content-Length: 647 Status: RO > CVS commands commit and checkin accepts filenames. I.e. if the specified > argument is not found in the modules file it will accept it as a > filename if it can find information about it in the CVS dir of the > specified path. Did you read the FAQ? > Why does not CVS release follow the same rules? cvs release doesn't follow the same logic as "commit" and "checkin" because it was intended to be the reverse of "checkout", which takes a module name. (It sprouted the ability to take a pathname after release was written.) > Is there a reason The release command was written a long time ago and has never been revised. > or a patch? No. From info-cvs-request@prep.ai.mit.edu Thu Jun 1 10:11:21 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA11875 for ; Thu, 1 Jun 1995 10:11:19 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10757; Thu, 1 Jun 95 07:03:18 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA18935; Thu, 1 Jun 1995 09:03:05 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14665; Thu, 1 Jun 1995 07:49:27 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14660; Thu, 1 Jun 1995 07:49:26 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA17643; Thu, 1 Jun 1995 08:49:24 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA07878; Thu, 1 Jun 95 06:49:22 PDT Received: from snex11.senet.abb.se by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA04528; Thu, 1 Jun 95 09:49:14 EDT Received: from localhost by snex11.senet.abb.se; (5.65/1.1.8.2/03Oct94-0154PM) id AA08630; Thu, 1 Jun 1995 15:16:36 +0200 Message-Id: <9506011316.AA08630@snex11.senet.abb.se> To: info-cvs@prep.ai.mit.edu Subject: Re: cvs release does not accept filename Date: Thu, 01 Jun 95 15:16:35 +0200 From: gtornblo@senet.abb.se X-Mts: smtp Content-Length: 825 Status: RO In a mail 1-JUN-1995 14:53:40.85 dgg@odi.com writes: >Did you read the FAQ? Yes I did, what part are you thinking of ? Let me guess: 3C.6 . . This type of question occurs only among groups of people who decide not to use "modules". The answer is to use "modules" but "modules" is to static to be used in the CVS based development env. that we have for our software. I have done some efforts to automate the creation of modules from build information (makefiles), dir structure etc. and we are using it to some extent, but still there are situations where we must work on a 'single file basis. Since CVS supports this to some extent I would have found it nice if also "CVS release" did so. >The release command was written a long time ago and has never been revised. Maybe something for CVS 1.4(next) ? Gunnar From info-cvs-request@prep.ai.mit.edu Thu Jun 1 15:15:17 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA25873 for ; Thu, 1 Jun 1995 15:15:07 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA16742; Thu, 1 Jun 95 12:04:17 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA22076; Thu, 1 Jun 1995 14:03:28 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09598; Thu, 1 Jun 1995 12:53:27 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09589; Thu, 1 Jun 1995 12:53:24 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA20920; Thu, 1 Jun 1995 13:52:58 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA14011; Thu, 1 Jun 95 11:52:54 PDT From: athan@morgan.com Received: from gateway.morgan.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA16546; Thu, 1 Jun 95 14:52:46 EDT Received: from rs1.fid.morgan.com ([138.20.1.17]) by gateway.morgan.com with SMTP id <41499>; Thu, 1 Jun 1995 14:52:38 -0400 Received: from sait136.morgan.com by rs1.fid.morgan.com (4.1/MS/FID/Sun-1.3) id AA12257; Thu, 1 Jun 95 14:52:18 EDT Received: by sait136.morgan.com (NX5.67e/NX3.0S) id AA03152; Thu, 1 Jun 95 14:47:51 -0400 Date: Thu, 1 Jun 1995 14:47:51 -0400 Message-Id: <9506011847.AA03152@sait136.morgan.com> To: info-cvs@prep.ai.mit.edu Subject: Renaming vs. modules Cc: athan@morgan.com Content-Length: 1946 Status: RO I'd like to come up with a specific design for CVS's next version of file handling. From what I can tell, the discussions have been centered around separate notions of modules and rename databases. As a starting point, I'm quoting a small piece of a private email from David Zoo (I hope you don't mind!), and am including my reply. ----- zoo> The modules specification and a rename databse are two independent zoo> projects. Once can already have a module consisting of many widely zoo> scattered files. Better editing and control of the modules file is zoo> highly desirable. The ability to use a tagged version of the zoo> modules file is also very useful. My understanding of CVS modules is that they allow you to group files in a given repository directory, and other repository directories together. The files come out as is, as far as their relative paths are concerned. The reason I see the rename database and the module stuff as similar is this: Imaging that a CVS module specified how a set of delta repositories (i.e., files in $CVSROOT) mapped to a set of source files. Well, a rename of a file in the source world is really just a change in this map (/foo/bar/bat.c,v is now being extracted as /foo/cow.h). The revisions of this map track these changes. The delta repository's name and location does not necessarily have to move. The important thing is what you get OUT of the system. ----- ... in other words, though this is probably sub-optimal, one *could* view the CVS side of things as one big heap of tmpnam'ed RCS files. A map tells CVS how to go from this big glob to what the user really cares about: the source tree. Another reason that removing the equivalence of delta repository relative path to source file relative path is a good thing is: The delta repository name can now be any key ... you can then support non-file-system based storage of revisions/etc aca athan@morgan.com From info-cvs-request@prep.ai.mit.edu Fri Jun 2 17:09:38 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA20518 for ; Fri, 2 Jun 1995 17:09:33 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27369; Fri, 2 Jun 95 14:02:13 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA28899; Fri, 2 Jun 1995 16:01:57 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03688; Fri, 2 Jun 1995 14:48:39 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03683; Fri, 2 Jun 1995 14:48:37 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA27938; Fri, 2 Jun 1995 15:48:30 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA05310; Fri, 2 Jun 1995 13:48:27 -0700 Received: from gateway.morgan.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA04135; Fri, 2 Jun 95 16:48:24 EDT Received: from rs1.fid.morgan.com ([138.20.1.17]) by gateway.morgan.com with SMTP id <41871>; Fri, 2 Jun 1995 16:48:14 -0400 Received: from sait136.morgan.com by rs1.fid.morgan.com (4.1/MS/FID/Sun-1.3) id AA08905; Fri, 2 Jun 95 16:48:05 EDT Received: by sait136.morgan.com (NX5.67e/NX3.0S) id AA00400; Fri, 2 Jun 95 16:44:55 -0400 Message-Id: <9506022044.AA00400@sait136.morgan.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: Andrew C Athan Date: Fri, 2 Jun 1995 16:44:54 -0400 To: woods@most.weird.com (Greg A. Woods) Subject: Re: Renaming vs. modules Cc: paul@sander.cupertino.ca.us (Paul Sander), info-cvs@prep.ai.mit.edu, athan@morgan.com References: <9506020816.AA24418@sander.sander.cupertino.ca.us> Content-Length: 4190 Status: RO Paul> When this map comes into play, the map must be locked for Paul> everyone if it is centralized, becoming a performance Paul> bottleneck. If parts of the map can be locked (i.e. it is Paul> distributed), then it becomes less of an issue, but there is Paul> usually some global handle somewhere that still needs Paul> exclusive access. Typically this handle has something to do Paul> with indexing or otherwise finding the lock database. Greg> It's not just this problem that leads me to think that such Greg> a map is not really all that good of an idea. Greg> [GREG'S NEXT PARAGRAPH WAS MOVED BELOW, IN THIS EMAIL] As I said in a previous email, the map can be designed in such a way as to have exactly the same locking constrains as currently exist when commiting files. Intuitively, I don't think this is such a huge problem... you have to remember that the only time anything would need to be locked is when a file is being removed, added or renamed (i.e., not every time you commit). Greg> What's missing is some way to track directory name changes. Greg> Because CVS currently treats directories differently Greg> (i.e. it recurses into them!), it has been difficult, if not Greg> impossible to treat them as managed objects. This is true, and is an example of an ad-hoc solution coming back to bite you. [] indicates my paraphrase (see originial message for lengthier description. Greg> [Put a file in each dir (e.g., one called CVS,v) which is Greg> tagged/revised/etc. with each commit. Use this to know when Greg> to recurse into a directory, include its contents, etc. Greg> E.g., if the directory tag file does not contain the tag you Greg> are currently attempting to check out, then the directory Greg> was not part of that tag release] Greg> ... What you are describing here does one useful thing: It deals with the removal of directories in a similar way as the Attic deals with the removal of files. It does not allow you to effectively deal any of the things that occur all the time in most development efforts I've been a part of. One example is something you mentioned yourself: directories that are renamed. Also the "locking" concerns of this CVS,v file are similar to those involved with locking a map (e.g., you would not want someone to be checking in additional revisions while someone else is specifying that this dir is no longer part of this development project). Greg> Perhaps there's a similar way to track objects such that the Greg> name can be resurrected, but either with, or without, the Greg> previous contents and history. (I.e. an object exists for Greg> several releases, disappears for a time, then a new object Greg> is created with the same name, and/or the old object simply Greg> re-appears, complete with its deltas and change log.) IMHO you're back to talking about a database that tells CVS what is part of a module at a given time, and where that thing came/comes from and/or goes to (which tense of the verb you use depends on what you chose as the reference time for the data stored in the map). If you added rename tracking to the CVS,v file mentioned above, that file becomes a "map." [THIS PARAGRAPH ORGINIALLY OCCURED ABOVE] Greg> Just what is wrong with mirroring the source directory Greg> structure in the repository? It does mean that the Greg> underlying filesystem can do much of the management for CVS. Greg> Use the right tool for the right job, and all of that.... Nothing is wrong with mirroring in the repository the current version of the structure of the project. In fact, the current version of the map should probably be a "null" map. That is, files that "exist" as far as the user is concerned should whenever possible have a one-to-one correspondence in terms of relative paths with the repository. Put another way, the reference point, Time Zero, should be "now." In fact, that's what CVS currently does. What is wrong with the current situation is that there is no way to remember or extract the old structure of the project. aca athan@morgan.com From info-cvs-request@prep.ai.mit.edu Thu Jun 1 19:24:07 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA08183 for ; Thu, 1 Jun 1995 19:24:05 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA01517; Thu, 1 Jun 95 16:16:48 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA18687; Thu, 1 Jun 1995 18:16:39 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00645; Thu, 1 Jun 1995 17:08:37 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00640; Thu, 1 Jun 1995 17:08:35 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA17929; Thu, 1 Jun 1995 18:08:34 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA00410; Thu, 1 Jun 95 16:08:28 PDT Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA01839; Thu, 1 Jun 95 19:08:23 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA23608; Thu, 1 Jun 95 16:12:25 PDT Date: Thu, 1 Jun 95 16:12:25 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506012312.AA23608@sander.sander.cupertino.ca.us> To: athan@morgan.com, info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules Content-Length: 2079 Status: RO athan@morgan.com wrote: > zoo> The modules specification and a rename databse are two independent > zoo> projects. Once can already have a module consisting of many widely > zoo> scattered files. Better editing and control of the modules file is > zoo> highly desirable. The ability to use a tagged version of the > zoo> modules file is also very useful. Not just useful, but essential. When a module definition is changed (specifically, when something is removed), you lose the capability of checking out the old configuration, violating one of the most basic requirements of configuration management. Developers like to rearrange their source files from time to time (which is treated as removal from one place and adding in another), so tags in combination with modules become useless in the current implementation for many projects spanning multiple directories (indeed, nearly every project I've ever worked on). >My understanding of CVS modules is that they allow you to group files in a >given repository directory, and other repository directories together. The >files come out as is, as far as their relative paths are concerned. The >reason I see the rename database and the module stuff as similar is this: >Imaging that a CVS module specified how a set of delta repositories (i.e., >files in $CVSROOT) mapped to a set of source files. Well, a rename of a file >in the source world is really just a change in this map (/foo/bar/bat.c,v is >now being extracted as /foo/cow.h). The revisions of this map track these >changes. The delta repository's name and location does not necessarily have >to move. The important thing is what you get OUT of the system. I agree completely with this statement. The problem is that the map of revision file to working copy becomes a bottleneck and locking a configuration for atomic update becomes a nightmare, assuming the map is centralized. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Thu Jun 1 19:39:36 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA03589 for ; Thu, 1 Jun 1995 19:39:35 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA04091; Thu, 1 Jun 95 16:31:20 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA19969; Thu, 1 Jun 1995 18:31:10 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02811; Thu, 1 Jun 1995 17:18:21 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02806; Thu, 1 Jun 1995 17:18:19 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA18852; Thu, 1 Jun 1995 18:18:18 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA01726; Thu, 1 Jun 95 16:18:06 PDT Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA03492; Thu, 1 Jun 95 19:18:01 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA23646; Thu, 1 Jun 95 16:22:09 PDT Date: Thu, 1 Jun 95 16:22:09 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506012322.AA23646@sander.sander.cupertino.ca.us> To: athan@morgan.com, tromey@hemlock.colorado.edu Subject: Re: Renaming vs. modules Cc: info-cvs@prep.ai.mit.edu Content-Length: 778 Status: RO Tom Tromey wrote: >But storing all the RCS files (assuming RCS is the underlying engine) >in one huge flat directory will be a real performance lose, I think. There's no need to store all of the RCS files in a single directory, as long as the map points to the right one. Commercial systems build repositories arbitrarily, and I see no reason why CVS can't as well. In fact, I think that when such a map becomes available, there will be an implication that the initial version of the map contains the structure of the existing repository, since backward compatibility will be an issue. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Fri Jun 2 05:49:34 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id FAA27156 for ; Fri, 2 Jun 1995 05:49:33 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA17068; Fri, 2 Jun 95 02:45:30 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA00634; Fri, 2 Jun 1995 04:45:20 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29185; Fri, 2 Jun 1995 03:28:14 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29180; Fri, 2 Jun 1995 03:28:12 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA00460; Fri, 2 Jun 1995 04:28:11 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AB16404; Fri, 2 Jun 95 02:28:08 PDT Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA01680; Fri, 2 Jun 95 05:27:58 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Fri, 2 Jun 95 02:50 EDT Message-Id: Date: Fri, 2 Jun 95 02:50 EDT From: woods@most.weird.com (Greg A. Woods) To: bmb@world.std.com (Brian Bartholomew) Cc: info-cvs@prep.ai.mit.edu Subject: Re: owner, group, modes added to cvs? In-Reply-To: Brian Bartholomew's message of "Tue, May 30, 1995 12:40:11 -0400" regarding "owner, group, modes added to cvs?" id <199505301640.AA24014@world.std.com> References: <199505301640.AA24014@world.std.com> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Content-Length: 2013 Status: RO [ On Tue, May 30, 1995 at 12:40:11 (-0400), Brian Bartholomew wrote: ] > Subject: owner, group, modes added to cvs? > > Note: I am NOT on the info-cvs mailing list. I will summarize replies > I receive. My apologies if this is a FAQ or a sore spot. > > I want to use cvs to check in entire U*IX operating systems. How > difficult would it be to add owner, group, and mode properties to each > revision-number-chunk of an RCS file, so that a checkout by root would > restore those properties and a checkin by root would examine those > properties and record the differences? Why not use something akin to the SCO xenix/unix perms database, or tripwire, etc., and call an interface to this scheme for each checkout? I currently use a simple (but large) makefile, and CVS, to manage all changes to my set of local hosts. I simply check in the original file (onto a vendor branch), and then hack away. I even do this for patched binaries, though only locally hacked stuff gets tracked. A simple readme for each host, thats included in the module, lists other changes, such as software installations, etc. For my machines at home I even manage /etc/passwd with a tiny shell and awk script pair that make calls through vipw. The neat thing about doing this is, so long as everyone involved is well disciplined, it's trivial to re-create the host configuration on a bare OS re-install. Just restore the CVS archive, check out the appropriate module, and type "make". Instantly you've built a machine where absolutely every static file has a known origin. (It's slightly more complex for a networked client host, as what I currently do is use NFS to mount the working directory.) My next step in improving this scheme is to enhance the configuration tools (make + ???) to help reduce the complexity and overhead of duplicating identical changes for multiple hosts. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Fri Jun 2 04:36:57 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA26419 for ; Fri, 2 Jun 1995 04:36:56 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA13402; Fri, 2 Jun 95 01:30:32 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA29811; Fri, 2 Jun 1995 03:30:26 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA26666; Fri, 2 Jun 1995 02:13:15 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA26660; Fri, 2 Jun 1995 02:13:13 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA29615; Fri, 2 Jun 1995 03:13:12 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA12535; Fri, 2 Jun 95 01:13:10 PDT Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA00907; Fri, 2 Jun 95 04:12:59 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA24418; Fri, 2 Jun 95 01:16:56 PDT Date: Fri, 2 Jun 95 01:16:56 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506020816.AA24418@sander.sander.cupertino.ca.us> To: athan@morgan.com, paul@sander.cupertino.ca.us Subject: Re: Renaming vs. modules Cc: info-cvs@prep.ai.mit.edu Content-Length: 1330 Status: RO Andrew C Athan wrote: > Paul> I agree completely with this statement. The problem is that the > Paul> map of revision file to working copy becomes a bottleneck and > Paul> locking a configuration for atomic update becomes a nightmare, > Paul> assuming the map is centralized. >I bet the right design can aleviate this problem. Even now, one cannot >commit the module (dir?) that someone else is currently commiting. Pretty >much the same bottle neck (assuming there isn't one BIG map for the entire >CVSROOT). That is true, but the present implementation distributes locks across the repository. Someone committing in one part of the repository does not interfere with someone else committing in another part of the same repository. When this map comes into play, the map must be locked for everyone if it is centralized, becoming a performance bottleneck. If parts of the map can be locked (i.e. it is distributed), then it becomes less of an issue, but there is usually some global handle somewhere that still needs exclusive access. Typically this handle has something to do with indexing or otherwise finding the lock database. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Fri Jun 2 10:10:02 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA15364 for ; Fri, 2 Jun 1995 10:09:57 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA04289; Fri, 2 Jun 95 07:00:56 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA04732; Fri, 2 Jun 1995 09:00:27 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA07128; Fri, 2 Jun 1995 07:50:59 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA07123; Fri, 2 Jun 1995 07:50:57 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA04319; Fri, 2 Jun 1995 08:50:50 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id GAA15123; Fri, 2 Jun 1995 06:50:34 -0700 Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA09294; Fri, 2 Jun 95 09:50:21 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Fri, 2 Jun 95 09:49 EDT Message-Id: Date: Fri, 2 Jun 95 09:49 EDT From: woods@most.weird.com (Greg A. Woods) To: paul@sander.cupertino.ca.us (Paul Sander) Cc: athan@morgan.com, info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules In-Reply-To: Paul Sander's message of "Fri, June 2, 1995 01:16:56 PDT" regarding "Re: Renaming vs. modules" id <9506020816.AA24418@sander.sander.cupertino.ca.us> References: <9506020816.AA24418@sander.sander.cupertino.ca.us> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Content-Length: 4253 Status: RO [ On Fri, June 2, 1995 at 01:16:56 (PDT), Paul Sander wrote: ] > Subject: Re: Renaming vs. modules > > When this map comes into play, the map must be locked for everyone if it is > centralized, becoming a performance bottleneck. If parts of the map can be > locked (i.e. it is distributed), then it becomes less of an issue, but there > is usually some global handle somewhere that still needs exclusive access. > Typically this handle has something to do with indexing or otherwise finding > the lock database. It's not just this problem that leads me to think that such a map is not really all that good of an idea. Just what is wrong with mirroring the source directory structure in the repository? It does mean that the underlying filesystem can do much of the management for CVS. Use the right tool for the right job, and all of that.... What's missing is some way to track directory name changes. Because CVS currently treats directories differently (i.e. it recurses into them!), it has been difficult, if not impossible to treat them as managed objects. Off the top of my head (because I think this is a hot issue, and don't want to see CVS bogged down by unnecessary baggage before its time!) I'd say there must be a much easier way to label directories in the repository, and simultaneously use them to store structure. Perhaps a file with the name "CVS" (i.e. CVS,v!) in the repository can be used as a sort of automated "readme" to describe the state of the directory it is in with respect to the current configuration. I.e. this file would simply contain empty delta's (or perhaps owner and mode information for the directory, or even the entire set of files in the directory, in each delta) and could thus be tagged and logged as necessary. Then doing such things as saying that if "dirname/CVS,v" doesn't contain the tag being checked out, "dirname" is not recursed into. Or even better, if it is found as "dirname/Attic/CVS,v", then only recurse into it if we're checking out by tag or date and that tag or date appears in there.... It might take a wee custom tool to populate existing repositories with CVS,v files, but for anyone who needs to represent the state of their directory structure w.r.t. a given configuration release, this should be well worth the effort. Holy cow! If I wasn't expecting to be so busy over the next few days I'd have this implemented by Wednesday! (Or at least in a couple of weeks ;-) IMHO, it seems quite trivial, but very elegant! I can't believe it came off the top of my head! Perhaps my unconsious has been planning this out all along! Perhaps there's a similar way to track objects such that the name can be resurrected, but either with, or without, the previous contents and history. (I.e. an object exists for several releases, disappears for a time, then a new object is created with the same name, and/or the old object simply re-appears, complete with its deltas and change log.) Now if only I had such clear thoughts on how to implement a strict modules database. One thought that comes to me now is that so long as there's no explicit two-way relationship between a module and the modules database, the latter must not be able to mention anything but directories. I.e. this must be considered bad: ls Unix/bin Makefile ls.c The reason I say this is that there's no simple way to say that for tag of the "ls" module, use version 1.342 of the modules database. Even if there were such a mapping, I'm not sure it could be made very elegant to use. It seems to me the only way to do it would be to include as part of the modules database (i.e. in $CVSROOT/CVSROOT) a ,v file for every module (and an Attic directory for deleted modules), and force CVS to insert a null delta and tag that file every time the module was tagged. Which reminds me. I still want to implement logging for "cvs tag", as well as some form of module level control, such as "tagprog". I find it very frustrating that only "cvs rtag" is logged, since I rarely, if ever, use rtag for anything but creating branch tags on existing release tags. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Fri Jun 2 14:54:41 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA29070 for ; Fri, 2 Jun 1995 14:54:33 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10481; Fri, 2 Jun 95 11:46:52 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20138; Fri, 2 Jun 1995 13:46:41 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24021; Fri, 2 Jun 1995 12:40:14 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24015; Fri, 2 Jun 1995 12:40:12 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA19625; Fri, 2 Jun 1995 13:40:00 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id LAA19685; Fri, 2 Jun 1995 11:39:49 -0700 Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA27011; Fri, 2 Jun 95 14:39:38 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA24891; Fri, 2 Jun 95 11:43:38 PDT Date: Fri, 2 Jun 95 11:43:38 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506021843.AA24891@sander.sander.cupertino.ca.us> To: woods@most.weird.com Subject: Re: Renaming vs. modules Cc: athan@morgan.com, info-cvs@prep.ai.mit.edu Content-Length: 5204 Status: RO woods@most.weird.com (Greg A. Woods) wrote: >Just what is wrong with mirroring the source directory structure in the >repository? It does mean that the underlying filesystem can do much of >the management for CVS. Use the right tool for the right job, and all >of that.... Changing the parent directory of any file or directory causes the directory structures repository and source tree to deviate, either in the current revision or one in the past. This problem compounds over time. The right tool for tracking this is a versioned filesystem, but Unix doesn't have one so a workaround is needed. >Off the top of my head (because I think this is a hot issue, and don't >want to see CVS bogged down by unnecessary baggage before its time!) I'd >say there must be a much easier way to label directories in the >repository, and simultaneously use them to store structure. Perhaps a >file with the name "CVS" (i.e. CVS,v!) in the repository can be used as >a sort of automated "readme" to describe the state of the directory it >is in with respect to the current configuration. I.e. this file would >simply contain empty delta's (or perhaps owner and mode information for >the directory, or even the entire set of files in the directory, in each >delta) and could thus be tagged and logged as necessary. Then doing >such things as saying that if "dirname/CVS,v" doesn't contain the tag >being checked out, "dirname" is not recursed into. Or even better, if >it is found as "dirname/Attic/CVS,v", then only recurse into it if we're >checking out by tag or date and that tag or date appears in there.... >It might take a wee custom tool to populate existing repositories with >CVS,v files, but for anyone who needs to represent the state of their >directory structure w.r.t. a given configuration release, this should be >well worth the effort. This assumes that directories never change names or parents, hence it is little more than an improved -p option for checkouts. The minimal data needed to implement a simple rename capability within a directory is for the CVS,v file's revisions to map revision file names to source file names, and to map source directory names to repository directory paths. Of course, this all assumes that files never change parent directories, which is an enormous simplification of the problem. File names should actually map to a path to a version file within the repository. But after many reorganizations, we'll find that files contained within a single source directory map to version files scattered about the repository, so locking becomes a bottleneck. Note that revision files can't be moved, because old revisions of the map become corrupt. >Perhaps there's a similar way to track objects such that the name can be >resurrected, but either with, or without, the previous contents and >history. (I.e. an object exists for several releases, disappears for a >time, then a new object is created with the same name, and/or the old >object simply re-appears, complete with its deltas and change log.) This again requires a versioned map of source files to revision files, like I describe above. If a source file is removed from a configuration, it can be re-added by adding it back to the map. If a source file is removed and replaced by a new one of the same name, then a new revision file is created with some arbitrary name and mapped to the correct source file. (A detail here is that RCS keyword expansion gets messed up; if it's important to have filenames be the real name of the file, then a new directory within the repository must be created for the new RCS file.) >Now if only I had such clear thoughts on how to implement a strict >modules database. One thought that comes to me now is that so long as >there's no explicit two-way relationship between a module and the >modules database, the latter must not be able to mention anything but >directories. I.e. this must be considered bad: > ls Unix/bin Makefile ls.c >The reason I say this is that there's no simple way to say that for tag > of the "ls" module, use version 1.342 of the modules database. >Even if there were such a mapping, I'm not sure it could be made very >elegant to use. It seems to me the only way to do it would be to >include as part of the modules database (i.e. in $CVSROOT/CVSROOT) a ,v >file for every module (and an Attic directory for deleted modules), and >force CVS to insert a null delta and tag that file every time the module >was tagged. This is not an adequate solution for those of use who must mix and match source files from multiple repository directories within a single source directory. However, a different approach would be to replace the modules database with branches within the CVS,v files and a list of pointers to the CVS,v files that form the root of the project. Checking out a module then becomes a matter of finding the root CVS,v files, checking out the latest revision on the appropriate branch from those files, then checking out whatever is listed there. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Mon Jun 5 13:23:34 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA01552 for ; Mon, 5 Jun 1995 13:23:33 -0400 Received: from Sun.COM by ulowell.uml.edu with SMTP id AA14896 (5.67b/IDA-1.5 for ); Mon, 5 Jun 1995 11:40:07 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29092; Mon, 5 Jun 95 08:32:45 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA14188; Mon, 5 Jun 1995 10:32:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18285; Mon, 5 Jun 1995 09:19:59 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18278; Mon, 5 Jun 1995 09:19:58 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA13363; Mon, 5 Jun 1995 10:19:54 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id IAA02277; Mon, 5 Jun 1995 08:19:52 -0700 Received: from netcom23.netcom.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA19514; Mon, 5 Jun 95 11:19:48 EDT Received: by netcom23.netcom.com (8.6.12/Netcom) id IAA09034; Mon, 5 Jun 1995 08:18:47 -0700 Date: Mon, 5 Jun 1995 08:18:47 -0700 From: rlm@netcom.com (Robert McMillin) Message-Id: <199506051518.IAA09034@netcom23.netcom.com> To: info-cvs@prep.ai.mit.edu Subject: porting CVS to OSF/1 Status: RO I just ported CVS to OSF/1 under release 3.0 of that operating system. The (minimal) patches necessary follow. Here's some comments: - Why is "struct option" declared in lib/getopt.c when it's already declared in lib/getopt.h? - lib/getopt.h somehow gets multiply included in some files. I added a guard #ifdef to prevent this from being a problem. - The OSF/1 version of make doesn't like a trailing backslash if there's nothing on the following line. I added a new macro in Makedef.in that can be null so make won't get upset. - The System V installer is not in /etc, so the steps configure takes to prevent its use are of no avail. I instead added a test for the BSD installer, /bin/installbsd, which is what you really want. - MAXPATHLEN and PATH_MAX are dependent on one another in a way that causes the preprocessor code in cvs.h to lose. I fixed this by adding an OSF1 macro to config.h. When enabled, it #undef's MAXPATHLEN. I'll be sending these to the DEC archives at ftp.dec.com as well. Happy hacking! *** ./lib/getopt.c.~1~ Tue Mar 31 13:55:22 1992 --- ./lib/getopt.c Mon Jun 05 06:54:17 1995 *************** *** 155,160 **** --- 155,162 ---- The field `has_arg' is 1 if the option takes an argument, 2 if it takes an optional argument. */ + #if 0 + /* Why is this here? It's already defined in getopt.h! */ struct option { char *name; *************** *** 162,167 **** --- 164,170 ---- int *flag; int val; }; + #endif const struct option *_getopt_long_options; *** ./lib/getopt.h.~1~ Tue Mar 31 13:55:24 1992 --- ./lib/getopt.h Sun Jun 04 19:25:18 1995 *************** *** 17,22 **** --- 17,25 ---- /* @(#)getopt.h 1.6 92/03/31 */ + #ifndef _GETOPT_H + #define _GETOPT_H + /* For communication from `getopt' to the caller. When `getopt' finds an option that takes an argument, the argument value is returned here. *************** *** 99,102 **** --- 102,107 ---- int gnu_getopt (); int gnu_getopt_long (); int gnu_getopt_long_only (); + #endif + #endif *** ./lib/Makefile.in.~1~ Tue Mar 31 13:55:16 1992 --- ./lib/Makefile.in Sun Jun 04 20:25:08 1995 *************** *** 31,42 **** hostname.c fnmatch.c ftruncate.c mkdir.c rename.c regex.c \ strdup.c getwd.c alloca.c OBJECTS = argmatch.o \ error.o getopt.o getopt1.o \ sighandle.o \ strippath.o stripslash.o yesno.o \ getdate.o \ ! @LIBOBJS@ DISTFILES = Makefile.in getopt.h \ fnmatch.h regex.h system.h wait.h $(SOURCES) --- 31,44 ---- hostname.c fnmatch.c ftruncate.c mkdir.c rename.c regex.c \ strdup.c getwd.c alloca.c + LIBOBJS=@LIBOBJS@ + OBJECTS = argmatch.o \ error.o getopt.o getopt1.o \ sighandle.o \ strippath.o stripslash.o yesno.o \ getdate.o \ ! $(LIBOBJS) DISTFILES = Makefile.in getopt.h \ fnmatch.h regex.h system.h wait.h $(SOURCES) *** ./src/config.h.~1~ Tue Mar 31 13:55:56 1992 --- ./src/config.h Mon Jun 05 06:51:20 1995 *************** *** 214,217 **** --- 214,226 ---- #endif #ifndef S_IWOTH #define S_IWOTH 0000002 /* write permission, other */ + #endif + + /* + * OSF/1 has an unusual relationship between MAXPATHLEN and PATH_MAX that + * causes some preprocessing in cvs.h to lose. If you're running OSF/1, + * define this. + */ + #ifndef OSF1 + #define OSF1 #endif *** ./src/cvs.h.~1~ Tue Mar 31 13:55:59 1992 --- ./src/cvs.h Mon Jun 05 06:51:34 1995 *************** *** 18,23 **** --- 18,43 ---- #include #endif /* !MY_NDBM */ + #ifdef OSF1 + /* + * 10/28/94 rlm -- OSF/1 has MAXPATHLEN as a dependent of PATH_MAX, but in + * a way causing the stuff below to fail: + * + * #define PATH_MAX 1023 + * #define MAXPATHLEN (PATH_MAX+1) + * + * Obviously, this sucks if we want to use define(MAXPATHLEN) as a razor + * to detect whether we should set PATH_MAX manually or not. For OSF/1, + * #undef MAXPATHLEN, too. + * + * ALL of the above are IMHO bogus under anything claiming POSIX.1 + * compliance. The max length of any file name in POSIX should come + * from pathconf(), since path lengths are a function of the filesystem, + * not kernel configuration. + */ + #undef MAXPATHLEN + #endif + /* XXX - for now this is static */ #undef PATH_MAX #ifdef MAXPATHLEN *** ./configure.~1~ Thu Apr 09 20:03:50 1992 --- ./configure Mon Jun 05 08:03:51 1995 *************** *** 129,135 **** fi echo checking for install ! if test -z "$INSTALL" && test -n "`install 2>&1`"; then INSTALL="install -c" INSTALLDATA="install -c -m 644" fi --- 129,138 ---- fi echo checking for install ! if test -z /bin/installbsd ; then ! INSTALL="installbsd -c" ! INSTALLDATA="installbsd -c -m 664" ! elif test -z "$INSTALL" && test -n "`install 2>&1`"; then INSTALL="install -c" INSTALLDATA="install -c -m 644" fi From info-cvs-request@prep.ai.mit.edu Sat Jun 3 02:18:51 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id CAA04487 for ; Sat, 3 Jun 1995 02:18:50 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18761; Fri, 2 Jun 95 23:15:45 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA24808; Sat, 3 Jun 1995 01:15:36 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06665; Sat, 3 Jun 1995 00:04:38 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06660; Sat, 3 Jun 1995 00:04:37 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA23543; Sat, 3 Jun 1995 01:04:35 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id XAA16737; Fri, 2 Jun 1995 23:04:32 -0700 Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA01256; Sat, 3 Jun 95 02:04:25 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA25805; Fri, 2 Jun 95 23:08:39 PDT Date: Fri, 2 Jun 95 23:08:39 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506030608.AA25805@sander.sander.cupertino.ca.us> To: info-cvs@prep.ai.mit.edu, jgaither@rockdal.aud.alcatel.com Subject: Re: Compression Content-Length: 2639 Status: RO jgaither wrote: > Is there a way, for CVS to compression in the repository storage? Or >can I commit and checkout gzip'ed files with out any negative impact? There is code to support compressed version files in RCS 5.6 and CVS 1.3. It's alpha quality, located on and . The cover file follows: This directory contains my work in-progress for adding support for LZW compression to RCS and CVS. The cvs-lzw.tar.Z file is a compressed tar file containing an alpha version of a "compress"-compatible library with an interface similar to stdio, extensible implementations of printf and scanf, a patch to RCS version 5.6 to add support for compressed files, and a patch to CVS version 1.3 to add support for compressed files. In the compression library, the only functions that have been tested to any extent are the ones used by RCS and CVS. Others are known to contain bugs. The printf implementation is known to have problems when errors occur while disposing of output characters, and its custom conversion registrar also lacks robustness. The scanf implementation is untested. Documentation and regression test suites are incomplete. The patch to RCS adds a "-Z" command line option to many commands. Its format is "-Z[b]n" where "b" specifies "blocked compression" (which is the default for the "compress" program -- its use is highly recommended), and "n" is equivalent to the "compress" program's "-b" option. This number should between 12 and 16, inclusive. (9-11 are supported by the "compress" program but have not been tested here.) The new "-Z" option may also be set in the RCSINIT environment variable. The patch to CVS adds support to read compressed version files, but adds no other new functionality. The LZW compression library is derived from the public-domain source code for the de-facto standard "compress" program available on many Unix systems, and is itself in the public domain. The printf implementation is copyright D. R. Hipp, and is freely redistributable under a license agreement that appears in its source code and accompanying documentation. The scanf implementation was lifted from the BSD sources and is freely redistributable under a license agreement that appears in its source code and accompanying documentation. The Software ChipSet build mechanism was developed by Paul Sander and is in the public domain. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Sun Jun 4 14:07:45 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA23433 for ; Sun, 4 Jun 1995 14:07:40 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18416; Sun, 4 Jun 95 11:01:04 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA20883; Sun, 4 Jun 1995 13:00:56 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09888; Sun, 4 Jun 1995 11:45:57 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09883; Sun, 4 Jun 1995 11:45:56 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA19895; Sun, 4 Jun 1995 12:45:49 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id KAA05924; Sun, 4 Jun 1995 10:45:42 -0700 Received: from sander.sander.cupertino.ca.u ([192.148.188.3]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA05771; Sun, 4 Jun 95 13:45:37 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA27651; Sun, 4 Jun 95 10:49:46 PDT Date: Sun, 4 Jun 95 10:49:46 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506041749.AA27651@sander.sander.cupertino.ca.us> To: info-cvs@prep.ai.mit.edu, karl@owl.hq.ileaf.com Subject: Re: Renaming vs. modules Content-Length: 1254 Status: RO karl@owl.hq.ileaf.com (Karl Berry) wrote: > The right tool for tracking this is a versioned filesystem, > but Unix doesn't have one so a workaround is needed. >Or one needs to be implemented. That's what ClearCase does, as I'm sure >many people on this list know. Admittedly having a new filesystem type >has its drawbacks, but it does mean that you get to track renames reliably. ClearCASE and CASEware both provide servers that implement the NFS protocol, but change the contents of the mounted filesystem based on some configuration data. What appears in the filesystem depends on the contents of the repository plus selection data given by the user at runtime or stored in the user's profile. It used to be that ClearCASE really did implement a new kind of filesystem, but the users didn't want to build new kernels, and they wanted to be able to access files via NFS on systems that weren't supported by the tools. Another approach is that of ShapeTools, which provides programmatic and command line interfaces to a library that makes a Unix filesystem look like it's versioned. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Sun Jun 4 17:07:16 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA02086 for ; Sun, 4 Jun 1995 17:07:05 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20051; Sun, 4 Jun 95 14:01:43 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA03886; Sun, 4 Jun 1995 16:01:31 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA15476; Sun, 4 Jun 1995 14:53:24 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA15471; Sun, 4 Jun 1995 14:53:22 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA02125; Sun, 4 Jun 1995 15:53:11 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA10922; Sun, 4 Jun 1995 13:53:04 -0700 Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13062; Sun, 4 Jun 95 16:52:54 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Sun, 4 Jun 95 16:52 EDT Message-Id: Date: Sun, 4 Jun 95 16:52 EDT From: woods@most.weird.com (Greg A. Woods) To: Andrew C Athan Cc: paul@sander.cupertino.ca.us (Paul Sander), info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules In-Reply-To: Andrew C. Athan's message of "Fri, June 2, 1995 16:44:54 -0400" regarding "Re: Renaming vs. modules" id <9506022044.AA00400@sait136.morgan.com> References: <9506020816.AA24418@sander.sander.cupertino.ca.us> <9506022044.AA00400@sait136.morgan.com> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Content-Length: 4848 Status: RO [ On Fri, June 2, 1995 at 16:44:54 (-0400), Andrew C. Athan wrote: ] > Subject: Re: Renaming vs. modules > > As I said in a previous email, the map can be designed in such a way > as to have exactly the same locking constrains as currently exist when > commiting files. Intuitively, I don't think this is such a huge > problem... you have to remember that the only time anything would need > to be locked is when a file is being removed, added or renamed (i.e., > not every time you commit). And perhaps every time the permission bits of the file change... > What you are describing here does one useful thing: It deals with the > removal of directories in a similar way as the Attic deals with the > removal of files. It does not allow you to effectively deal any of > the things that occur all the time in most development efforts I've > been a part of. One example is something you mentioned yourself: > directories that are renamed. Also the "locking" concerns of this > CVS,v file are similar to those involved with locking a map (e.g., you > would not want someone to be checking in additional revisions while > someone else is specifying that this dir is no longer part of this > development project). Ah, but remember "renaming" is simply an extra step added to the "add, delete" sequence -- namely the copying of old history to the "new" file. > IMHO you're back to talking about a database that tells CVS what is > part of a module at a given time, and where that thing came/comes from > and/or goes to (which tense of the verb you use depends on what you > chose as the reference time for the data stored in the map). If you > added rename tracking to the CVS,v file mentioned above, that file > becomes a "map." But the "Attic" concept does this already, and all I'm proposing is to add something like what I've called the "CVS,v" file to enable tracking of directories too (and perhaps further the tracking of directory and inode information not already tracked by RCS, such as permission bits). > be "now." In fact, that's what CVS currently does. What is wrong > with the current situation is that there is no way to remember or > extract the old structure of the project. And this is exactly what the "CVS,v" file would enable. So, just to describe it a bit more formally: Cvs adds to each directory in the repository an RCS file with the name "CVS,v" (chosen to hide behind the name of the CVS administrative directory used in each working directory). This file could be checked out into the "CVS/Directory" file in the working directories. A simple table of filenames and permission bits for each ",v" file in the same directory is checked into this file (if different from the previous list). This appropriate delta in this file is tagged each time all of the other files in the directory are similarly tagged. If the directory is removed, this file is moved into the Attic directory in the repository. Cvs checkout without any version selection options only creates working directories if a "CVS,v" file appears in the corresponding directory in the repository. Cvs checkout with version selection options examines the "Attic/CVS,v" file for relevance and only creates the working directory if a matching version is found. If the working directory is created, then other files in the Attic are also examined for relevant versions. I think these last two features will eliminate the need for the "-P" option to prune empty directories, and will make the person who was complaining of the implict "-P" on cvs export much happier! Finally, as further feature could be added, a "cvs rename" command that will "cvs add" the new file/directory as a copy of the old file/directory (i.e. by copying the relevant ",v" file inside the repository, then "cvs remove" the old file/directory. In the case of directories it might do normal recursion, i.e. the operation would first be performed for each file or directory enclosed by the renamed directory thus making it possible to rename entire hierarchies. Now I have a hunch that there's a simple way to store information in the Attic files (esp. now there's a "CVS,v" history too), such that files and/or directories can be resurrected and/or reused from the Attic. Perhaps the analog of a sub-basement could be used.... BTW, I've never seen a reason for the source control system to track things like symlinks or hard links. In the few cases where these objects are necessary in the build environment, the build and configuration tool(s) are a more than adequate tool to create them as necessary. By virtue of tracking changes to the build and configuration tool control files, links and such will also be tracked. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Sun Jun 4 17:36:59 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA18596 for ; Sun, 4 Jun 1995 17:36:57 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20382; Sun, 4 Jun 95 14:30:33 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA04512; Sun, 4 Jun 1995 16:30:27 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA16321; Sun, 4 Jun 1995 15:17:18 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA16316; Sun, 4 Jun 1995 15:17:16 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA04328; Sun, 4 Jun 1995 16:17:15 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id OAA11664; Sun, 4 Jun 1995 14:17:13 -0700 Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA14187; Sun, 4 Jun 95 17:17:07 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Sun, 4 Jun 95 17:16 EDT Message-Id: Date: Sun, 4 Jun 95 17:16 EDT From: woods@most.weird.com (Greg A. Woods) To: mike@twinpeaks.prc.com (Mike Ladwig) Cc: paul@sander.cupertino.ca.us (Paul Sander), info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules In-Reply-To: Mike Ladwig's message of "Sun, June 4, 1995 14:13:04 -0400" regarding "Re: Renaming vs. modules" id References: Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Content-Length: 920 Status: RO [ On Sun, June 4, 1995 at 14:13:04 (-0400), Mike Ladwig wrote: ] > Subject: Re: Renaming vs. modules > > Its been many years, but I was at a USENIX conference (Baltimore, maybe?) > where papers on multi-dimensional file systems were presented. Has > someone considered perverting an existing solution like this to solve our > problem? Yup, there's lots of literature in this vein. The proceedings you mention (USENIX Summer 1989, Baltimore) talk about AT&T Bell Labs 3D filesystem. One of the most complete working systems is Vesta from DEC-SRC. I've mentioned it before on this list, but haven't the references handy. I think they're still available on ftp.dec.com:/pub/DEC/SRC/research-reports/. Bell Labs has done other work in this area, as has HP, and I think NCR. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Sun Jun 4 17:38:27 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA08260 for ; Sun, 4 Jun 1995 17:38:26 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20470; Sun, 4 Jun 95 14:32:45 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA04578; Sun, 4 Jun 1995 16:32:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA16111; Sun, 4 Jun 1995 15:13:45 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA16104; Sun, 4 Jun 1995 15:13:42 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA04253; Sun, 4 Jun 1995 16:13:38 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id OAA11538; Sun, 4 Jun 1995 14:13:36 -0700 Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA14122; Sun, 4 Jun 95 17:13:25 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Sun, 4 Jun 95 16:59 EDT Message-Id: Date: Sun, 4 Jun 95 16:59 EDT From: woods@most.weird.com (Greg A. Woods) To: paul@sander.cupertino.ca.us (Paul Sander) Cc: athan@morgan.com, info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules In-Reply-To: Paul Sander's message of "Fri, June 2, 1995 11:43:38 PDT" regarding "Re: Renaming vs. modules" id <9506021843.AA24891@sander.sander.cupertino.ca.us> References: <9506021843.AA24891@sander.sander.cupertino.ca.us> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Content-Length: 1699 Status: RO [ On Fri, June 2, 1995 at 11:43:38 (PDT), Paul Sander wrote: ] > Subject: Re: Renaming vs. modules > > Changing the parent directory of any file or directory causes the > directory structures repository and source tree to deviate, either > in the current revision or one in the past. This problem compounds > over time. The right tool for tracking this is a versioned filesystem, > but Unix doesn't have one so a workaround is needed. >[....] Not necessarily -- see my reply to Andrew Athan. > This is not an adequate solution for those of use who must mix and match > source files from multiple repository directories within a single source > directory. However, a different approach would be to replace the modules > database with branches within the CVS,v files and a list of pointers to > the CVS,v files that form the root of the project. Checking out a module > then becomes a matter of finding the root CVS,v files, checking out the > latest revision on the appropriate branch from those files, then checking > out whatever is listed there. Hmmm.... Watch for flying opinions.... I'd say anyone with a complex enough environment where they wish to mix and match source files from multiple repository sub-directories into a single working directory should: a) re-organize the build environment to avoid this situation; b) use a relational database to store their code, not a filesystem. CVS, and tools like it, are not meant for this. There are many adequate ways to avoid this situation through good modularization, use of libraries, etc. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Mon Jun 5 04:38:32 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA19183 for ; Mon, 5 Jun 1995 04:38:26 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA06819; Mon, 5 Jun 95 01:32:25 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA03477; Mon, 5 Jun 1995 03:32:18 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06047; Mon, 5 Jun 1995 02:24:41 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06043; Mon, 5 Jun 1995 02:24:39 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA03379; Mon, 5 Jun 1995 03:24:35 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id BAA06367; Mon, 5 Jun 1995 01:24:35 -0700 Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA04954; Mon, 5 Jun 95 04:24:25 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA28876; Mon, 5 Jun 95 01:28:34 PDT Date: Mon, 5 Jun 95 01:28:34 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506050828.AA28876@sander.sander.cupertino.ca.us> To: woods@most.weird.com Subject: Re: Renaming vs. modules Cc: info-cvs@prep.ai.mit.edu Status: RO woods@most.weird.com (Greg A. Woods) wrote: >[ On Fri, June 2, 1995 at 16:44:54 (-0400), Andrew C. Athan wrote: ] >> What you are describing here does one useful thing: It deals with the >> removal of directories in a similar way as the Attic deals with the >> removal of files. It does not allow you to effectively deal any of >> the things that occur all the time in most development efforts I've >> been a part of. One example is something you mentioned yourself: >> directories that are renamed. Also the "locking" concerns of this >> CVS,v file are similar to those involved with locking a map (e.g., you >> would not want someone to be checking in additional revisions while >> someone else is specifying that this dir is no longer part of this >> development project). >Ah, but remember "renaming" is simply an extra step added to the "add, >delete" sequence -- namely the copying of old history to the "new" file. Nope, a rename involves changing the map between a source file and its version file. An add and delete sequence are inadequate for the following reasons: - Multiple copies of the same RCS file are kept, and they each contain incomplete histories. - Depending on the implementation, history may be lost during a rename. - Renames are not reversible; or if they are, merging histories is a nightmare. - Renames double the amount of space used by a given file in the repository. - A new file cannot be added to replace a file that has been renamed away. I have implemented a file rename capability in CVS 1.3 that was based on copying an RCS file from source to destination directory, and moving the original into the source directory's Attic. It suffered from all of these problems. I implemented a directory rename capability that invoked the file rename feature for everything in a directory, with optional recursive descent. The resulting jumble in the repository was awful after just a few reorgs, and an enormous amount of space was wasted. >> IMHO you're back to talking about a database that tells CVS what is >> part of a module at a given time, and where that thing came/comes from >> and/or goes to (which tense of the verb you use depends on what you >> chose as the reference time for the data stored in the map). If you >> added rename tracking to the CVS,v file mentioned above, that file >> becomes a "map." >But the "Attic" concept does this already, and all I'm proposing is to >add something like what I've called the "CVS,v" file to enable tracking >of directories too (and perhaps further the tracking of directory and >inode information not already tracked by RCS, such as permission bits). There are many possible notions of what is part of a module at a given time, depending on what branch you live on. The Attic implementation does not solve this problem adequately, as we see by the number of problems reported to this list in this area. Because maps are subject to the same versioning and branching as files, they work much better at tracking strange things that might happen on branches and can be used to implement much more reasonable behavior when merges are done than is possible with an Attic implementation. >> be "now." In fact, that's what CVS currently does. What is wrong >> with the current situation is that there is no way to remember or >> extract the old structure of the project. >And this is exactly what the "CVS,v" file would enable. >So, just to describe it a bit more formally: >Cvs adds to each directory in the repository an RCS file with the name >"CVS,v" (chosen to hide behind the name of the CVS administrative >directory used in each working directory). This file could be checked >out into the "CVS/Directory" file in the working directories. This is fine. >A simple table of filenames and permission bits for each ",v" file in >the same directory is checked into this file (if different from the >previous list). This is fine, assuming renames copies an RCS file. Keeping one RCS file and mapping between the source file and the RCS file is a better implementation for reasons discussed above and elsewhere. >This appropriate delta in this file is tagged each time all of the other >files in the directory are similarly tagged. This is true of any map. >If the directory is removed, this file is moved into the Attic directory >in the repository. What if the directory exists on some branches, but not on others? A better approach would be to include the directory in its parent's map, or not, depending on its existence. In this implementation, the CVS/Directory file describes its contents, including child directories, and can also be extended to include symlinks. >Cvs checkout without any version selection options only creates working >directories if a "CVS,v" file appears in the corresponding directory in >the repository. This is fine. >Cvs checkout with version selection options examines the "Attic/CVS,v" >file for relevance and only creates the working directory if a matching >version is found. If the working directory is created, then other files >in the Attic are also examined for relevant versions. Actually, the CVS/Directory map can be consulted to determine which files should be scanned. It's a more efficient implementation unless the CVS/Directory file was lost. Actually, this is an incomplete solution, given the following schenario: - File A is created in directory D, on the trunk. - Branch B is created in directory D and all of its contents. - File A is revised and tagged on branch B. - File A is removed from branch B. - Somebody checks out the latest revision of branch B. Given the simple CVS/Directory file described above, is file A checked out or not? It should not be, yet it contains the branch tag for B so in reality it does get checked out. Using a map, it becomes obvious that A does not belong in the latest revision of branch B because the file is not listed. >I think these last two features will eliminate the need for the "-P" >option to prune empty directories, and will make the person who was >complaining of the implict "-P" on cvs export much happier! >Finally, as further feature could be added, a "cvs rename" command that >will "cvs add" the new file/directory as a copy of the old >file/directory (i.e. by copying the relevant ",v" file inside the >repository, then "cvs remove" the old file/directory. In the case of >directories it might do normal recursion, i.e. the operation would first >be performed for each file or directory enclosed by the renamed >directory thus making it possible to rename entire hierarchies. Like I said above, I've already implemented this. It is a partial solution to a sticky problem, which introduces many new problems. I very strongly recommend against this type of implementation. >Now I have a hunch that there's a simple way to store information in the >Attic files (esp. now there's a "CVS,v" history too), such that files >and/or directories can be resurrected and/or reused from the Attic. >Perhaps the analog of a sub-basement could be used.... Re-adding a file to a configuration is certainly a useful feature. This is accomplished by re-adding a file to a map. Adding a new file to replace an old one is also a useful feature, which is implemented by creating anew revision file and adding it to the map. Note that adding the new revision file is important if we introduce the notion of a file type, which has been discussed at length in this list. >BTW, I've never seen a reason for the source control system to track >things like symlinks or hard links. In the few cases where these >objects are necessary in the build environment, the build and >configuration tool(s) are a more than adequate tool to create them as >necessary. By virtue of tracking changes to the build and configuration >tool control files, links and such will also be tracked. It might be useful to track special files as well as symlinks. This capability can be provided by the build tools, but providing these capabilities is easy with a map. Hard links are harder, and I don't see a robust way to support them outside of the build environment. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Mon Jun 5 04:52:56 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA06056 for ; Mon, 5 Jun 1995 04:52:55 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA07232; Mon, 5 Jun 95 01:47:23 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA03632; Mon, 5 Jun 1995 03:47:16 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06358; Mon, 5 Jun 1995 02:31:24 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06354; Mon, 5 Jun 1995 02:31:23 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA03433; Mon, 5 Jun 1995 03:31:19 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id BAA06696; Mon, 5 Jun 1995 01:31:20 -0700 Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA05074; Mon, 5 Jun 95 04:31:14 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA28891; Mon, 5 Jun 95 01:35:21 PDT Date: Mon, 5 Jun 95 01:35:21 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506050835.AA28891@sander.sander.cupertino.ca.us> To: woods@most.weird.com Subject: Re: Renaming vs. modules Cc: athan@morgan.com, info-cvs@prep.ai.mit.edu Status: RO woods@most.weird.com (Greg A. Woods) wrote: >[ On Fri, June 2, 1995 at 11:43:38 (PDT), Paul Sander wrote: ] >> This is not an adequate solution for those of use who must mix and match >> source files from multiple repository directories within a single source >> directory. However, a different approach would be to replace the modules >> database with branches within the CVS,v files and a list of pointers to >> the CVS,v files that form the root of the project. Checking out a module >> then becomes a matter of finding the root CVS,v files, checking out the >> latest revision on the appropriate branch from those files, then checking >> out whatever is listed there. >I'd say anyone with a complex enough environment where they wish to mix >and match source files from multiple repository sub-directories into a >single working directory should: a) re-organize the build environment >to avoid this situation; b) use a relational database to store their >code, not a filesystem. CVS, and tools like it, are not meant for this. >There are many adequate ways to avoid this situation through good >modularization, use of libraries, etc. Many shops license source code from other vendors, and must live with how those vendors reorganize their code. In this event, a robust mapping mechanism is needed. Under such agreements, it is typical for the licensee to return their modifications back to the owner, who is unlikely to accept such fundamental changes their architecture. Also, commercial tools with which CVS tries to compete, and some of the free ones as well, do indeed use relational (or at least entity-relationship) databases to track their artifacts. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Mon Jun 5 13:26:11 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA03308 for ; Mon, 5 Jun 1995 13:26:11 -0400 Received: from Sun.COM by ulowell.uml.edu with SMTP id AA03647 (5.67b/IDA-1.5 for ); Mon, 5 Jun 1995 09:39:40 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20056; Mon, 5 Jun 95 06:32:37 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA07864; Mon, 5 Jun 1995 08:32:30 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13067; Mon, 5 Jun 1995 07:25:45 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13063; Mon, 5 Jun 1995 07:25:43 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA07559; Mon, 5 Jun 1995 08:25:27 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id GAA21217; Mon, 5 Jun 1995 06:25:26 -0700 Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12864; Mon, 5 Jun 95 09:25:19 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Mon, 5 Jun 95 09:24 EDT Message-Id: Date: Mon, 5 Jun 95 09:24 EDT From: woods@most.weird.com (Greg A. Woods) To: paul@sander.cupertino.ca.us (Paul Sander) Cc: athan@morgan.com, info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules In-Reply-To: Paul Sander's message of "Mon, June 5, 1995 01:35:21 PDT" regarding "Re: Renaming vs. modules" id <9506050835.AA28891@sander.sander.cupertino.ca.us> References: <9506050835.AA28891@sander.sander.cupertino.ca.us> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Status: RO [ On Mon, June 5, 1995 at 01:35:21 (PDT), Paul Sander wrote: ] > Subject: Re: Renaming vs. modules > > Many shops license source code from other vendors, and must live with > how those vendors reorganize their code. In this event, a robust mapping > mechanism is needed. Under such agreements, it is typical for the > licensee to return their modifications back to the owner, who is unlikely > to accept such fundamental changes their architecture. Good luck! > Also, commercial tools with which CVS tries to compete, and some of the > free ones as well, do indeed use relational (or at least entity-relationship) > databases to track their artifacts. And the literature is full of descriptions of how to make this work. The trouble with moving in this direction is that any such implementation will require re-implementation of all of the functionality of RCS to work in such an environment. CVS, being a "simple" wrapper for RCS, must live with the restrictions of a filesystem based repository. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Mon Jun 5 16:22:06 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA16094 for ; Mon, 5 Jun 1995 16:22:03 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA26796; Mon, 5 Jun 95 13:18:06 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA03402; Mon, 5 Jun 1995 15:17:59 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04003; Mon, 5 Jun 1995 14:01:42 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03999; Mon, 5 Jun 1995 14:01:40 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA02212; Mon, 5 Jun 1995 15:01:21 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA13425; Mon, 5 Jun 1995 13:01:18 -0700 Received: from arbi.informatik.uni-oldenburg.de by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA07640; Mon, 5 Jun 95 15:59:48 EDT Received: by arbi.informatik.uni-oldenburg.de (smail3.1.18 + xalias); Mon, 5 Jun 95 21:59 CES Received: by proximus (5.65c/IDA-1.4.4/proximus-0.9) for uniol id AA22665; Mon, 5 Jun 1995 16:34:16 +0200 Message-Id: <199506051434.AA22665@proximus> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Gerhard Moller Date: Mon, 5 Jun 95 16:34:12 +0200 To: info-cvs@prep.ai.mit.edu Subject: cvs 1.4a2 cvs enters infinite loops (4 chars lost?) Reply-To: gemoe@proximus.north.de (Gerhard Moeller) Status: RO Hi, I just compiled and tested cvs 1.4a2 (including the loginfo patch and the wrappers patch), but had some problems. I made a new test-repository with cvsinit. Everything seemed ok. I then did in /tmp a "cvs co loginfo" just to see if it works. Seemed ok. I did a cvs status loginfo inside the new /tmp/loginfo dir. Seemed ok. I made a "cvs status -l loginfo" in /tmp. Seemed ok. I made a "cvs status loginfo" in /tmp. --> I entered an infinite loop! cvs status: Examining loginfo [...] cvs status: Examining loginfo/ [...] cvs status: Examining loginfo// [...] cvs status: Examining loginfo/// [...] and so on... Not nice. Even worse is "cvs release -d loginfo" in /tmp. --> ? ? ? ? nfo ? ? ? ? nfo [...] Again, an infinite loop! How about a "cvs co CVSROOT"? --> cvs checkout: Updating CVSROOT cvs checkout: nothing known about CVSROOT/info cvs checkout: nothing known about CVSROOT/itinfo cvs checkout: nothing known about CVSROOT/les cvs checkout: nothing known about CVSROOT/nfo ? CVSROOT/ ? CVSROOT/ ? CVSROOT/ cvs checkout: Updating CVSROOT/ cvs checkout: nothing known about CVSROOT//info cvs checkout: nothing known about CVSROOT//itinfo cvs checkout: nothing known about CVSROOT//les cvs checkout: nothing known about CVSROOT//nfo ? CVSROOT// ? CVSROOT// ? CVSROOT// cvs checkout: Updating CVSROOT// [...] Hm. Looking at the names "info", "les", "nfo" and "itinfo", it appears to me as if cvs swallows the first four chars of the files! Another check with a new source might show the problem: mkdirs /tmp/test/subdir1; cd /tmp/test; cvs import -m "Imported test" testdir gemoe start --> N testdir/ir1 cvs [import aborted]: cannot open ir1: No such file or directory Obviously again, the first four chars are missing! So the question remains: Where are the four characters swallowed? System Information: NEXTSTEP 3.3 (3.2 Dev), black h/w diffutils 2.7 rcs 5.6.7.4 Any help is more than appreciated, I already tried 2 days... Gerhard. -- N < principiis obsta! >------------------< PGP Key available on request > N e Gerhard Moeller, Amselweg 16, 26122 Oldenburg (FRG) [*: 02/21/1968] e X Private: gemoe@proximus.north.de Phone (voice): +49-441-507856 X T Uni: Gerhard.Moeller@Informatik.Uni-Oldenburg.DE NeXTmail & MIME T NoGeNUG - Northern German NeXT User Group: NoGeNUG@proximus.north.DE From info-cvs-request@prep.ai.mit.edu Mon Jun 5 13:24:57 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA02686 for ; Mon, 5 Jun 1995 13:24:57 -0400 Received: from Sun.COM by ulowell.uml.edu with SMTP id AA10023 (5.67b/IDA-1.5 for ); Mon, 5 Jun 1995 10:56:10 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24998; Mon, 5 Jun 95 07:47:41 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA11272; Mon, 5 Jun 1995 09:47:34 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA15760; Mon, 5 Jun 1995 08:36:17 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA15755; Mon, 5 Jun 1995 08:36:15 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA10627; Mon, 5 Jun 1995 09:35:59 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id HAA27596; Mon, 5 Jun 1995 07:35:53 -0700 Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA16481; Mon, 5 Jun 95 10:35:37 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Mon, 5 Jun 95 10:35 EDT Message-Id: Date: Mon, 5 Jun 95 10:35 EDT From: woods@most.weird.com (Greg A. Woods) To: paul@sander.cupertino.ca.us (Paul Sander) Cc: info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules In-Reply-To: Paul Sander's message of "Mon, June 5, 1995 01:28:34 PDT" regarding "Re: Renaming vs. modules" id <9506050828.AA28876@sander.sander.cupertino.ca.us> References: <9506050828.AA28876@sander.sander.cupertino.ca.us> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Status: RO [ On Mon, June 5, 1995 at 01:28:34 (PDT), Paul Sander wrote: ] > Subject: Re: Renaming vs. modules > > >Ah, but remember "renaming" is simply an extra step added to the "add, > >delete" sequence -- namely the copying of old history to the "new" file. > > Nope, a rename involves changing the map between a source file and its > version file. I agree that a map would be an elegant solution. Any solution involving pointers is no doubt more efficient in some ways than keeping multiple copies of data, and moving large quantities of data about. However, complexity is also a factor, and the need for a perfect solution must be weighed against the cost of providing it. I would like to suggest that complex renaming of files and directories (i.e. when they move about on the directory tree, and don't just change their labels), is a relatively rare occurance in a development environment, and with a little bit of planning on the part of the developers contemplating such moves, simple extensions to the current facilities will be more than adequate to serve their needs. So, in this discussion I've been thinking primarily of renames that move files from one directory to another, and how to deal with this given the recursive nature of CVS -- i.e. how to keep enough information in each directory such that some central shared database is not required. For the case of simply changing labels within the same container directory, a map of some sort, that could be stored in each repository directory, should be quite simple to implement and would provide a good deal of efficiency. I'd be very curious to see a detailed specification of the data structures and operations necessary to build a distributed map (i.e. one that lives in each sub-directory and doesn't require some central semaphore for modifications), esp. one that can work given the current recursive operation of CVS. I cannot even begin to picture such a creature if it is required to support all of the possible types of renaming that have been proposed. > An add and delete sequence are inadequate for the following > reasons: > - Multiple copies of the same RCS file are kept, and they each contain > incomplete histories. > - Depending on the implementation, history may be lost during a rename. Both of these problems would be simple implementation deficiencies that can easily be corrected, and in fact our later conversation indicates how they would be corrected. > - Renames are not reversible; or if they are, merging histories is a > nightmare. Huh? You've got two ,v files. One is a historical archive used only for restoring old versions. Another is the new working file. Reversing the rename means simply copying the new working file back to the directory it was once in, and moving the now old working file into the Attic in the intermediate directory. We need to do one further trick that CVS currently doesn't support. We need to know that a specified range of delta's is off limits for the renamed file. We can get the hint this is necessary because there's both an Attic file, and a current file with the same name. If this is a reversed rename, where the current file also contains the same initial deltas as the Attic copy, discovering the off-limit set of deltas is easy, unless the entire rename/reverse process is repeated, in which case this optimisation fails. I suppose we can optimise space utilisation if we know it is the same file being replaced by deleting the Attic copy. A list of off-limit deltas for this directory is still required though. If another old file with competing deltas and tags is renamed into conflict with an Attic file, a list of off-limit deltas should still suffice. Perhaps the easiest way to build this list is to keep it updated all the time (i.e. pay a small price incrementally). I.e. every time a delta is created, append it to the list of valid deltas kept for the filename while it resides in a given directory and always keep this list as a part of the directory. > - Renames double the amount of space used by a given file in the > repository. It's is simply a space/time tradeoff, though I agree the ratio may not be one-to-one, unless you also factor in complexity with the goal of keeping the implementation data structures and algorithms as simple as possible. > - A new file cannot be added to replace a file that has been renamed > away. Why not? This is the easy case. CVS need only recognize the conflict with the Attic file and deal with it appropriately. Only if there's been a mistake will a version of the Attic file and a version of the new file both be checked out on a date/tag based checkout/export. I'm not even sure CVS doesn't implicitly support this already! > I have implemented a file rename capability in CVS 1.3 that was based > on copying an RCS file from source to destination directory, and moving > the original into the source directory's Attic. It suffered from all > of these problems. I implemented a directory rename capability that > invoked the file rename feature for everything in a directory, with > optional recursive descent. The resulting jumble in the repository was > awful after just a few reorgs, and an enormous amount of space was wasted. We have to remember that space is cheap for most folks now, even those folks such as one of our clients who are contemplating use of CVS and who have about 250 Mb of source code (and who would have well over a Gb or two of ,v files if they had been keeping versions from day one). Remember that extra space represents at least one way of restoring old configurations. If you don't think you'll ever need them, delete them! > There are many possible notions of what is part of a module at a given > time, depending on what branch you live on. The Attic implementation > does not solve this problem adequately, as we see by the number of problems > reported to this list in this area. > > Because maps are subject to the same versioning and branching as files, > they work much better at tracking strange things that might happen on > branches and can be used to implement much more reasonable behavior when > merges are done than is possible with an Attic implementation. Ah, branches. What wonderful structures they are! Of course I've been assuming that complex renames are not possible on branches for the same reason that files cannot be added or deleted only on a branch. I think this is a fair assumption to make, especially given the apparent goals of a tool that's a "simple" wrapper on a file-by-file source code tool. > Like I said above, I've already implemented this. It is a partial > solution to a sticky problem, which introduces many new problems. I very > strongly recommend against this type of implementation. Well, for your goals, this indeed might be true. However, for all of the situations I've encountered while using CVS, this level of solution is more than adequate. I should note one other assumption I've made, but not stated. I assume that when tracking third party sources, if a significant re-organization is made to the product source tree, a new module will be created. Once the local changes have been extracted from the old module, it can be kept, or can be replaced by the new one, depending on the requirements for supporting the old version locally. In conclusion I would say that what I've proposed extends CVS sufficiently that it can provide a more than adequate set of facilities to manage the requirements of most small software shops, and many large shops willing to provide the management overhead necessary to work around the "deficiencies" of CVS. CVS already provides a nice blend of the features necessary for supporting both original developement and third party source maintenance. If anyone wants to think about a complex task, how about devising some way to guess at structural changes between third party releases. I'd love to have "cvs import" be able to say something like "It appears that over 50% of the lines in the new file a/b/c/foo.t are the same as those in the old file d/e/f/bar.g. Should I rename it?". It should also handle the simple case of deleting old files, after it has determined that none of them were renamed. And perhaps it could also manage the now more complex job of generating local patches to re-apply to a new local version. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Mon Jun 5 13:20:49 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA00992 for ; Mon, 5 Jun 1995 13:20:49 -0400 Received: from Sun.COM by ulowell.uml.edu with SMTP id AA19052 (5.67b/IDA-1.5 for ); Mon, 5 Jun 1995 13:15:23 -0400 Received: from Central.Sun.COM (centralmail1.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA08064; Mon, 5 Jun 95 10:08:13 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA20990; Mon, 5 Jun 1995 12:07:15 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23819; Mon, 5 Jun 1995 10:48:01 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23814; Mon, 5 Jun 1995 10:47:59 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA19402; Mon, 5 Jun 1995 11:47:55 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id JAA13770; Mon, 5 Jun 1995 09:47:55 -0700 Received: from relay3.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA25622; Mon, 5 Jun 95 12:47:51 EDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQysvj19631; Mon, 5 Jun 1995 12:48:06 -0400 Received: from etnibsd.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Mon, 5 Jun 1995 12:47:52 -0400 Received: by etnibsd.UUCP (4.1/SMI-4.1(VSH)) id AA06967; Mon, 5 Jun 95 12:08:20 EDT From: etnibsd!vsh@uunet.uu.net (Steve Harris) Message-Id: <9506051608.AA06967@etnibsd.UUCP> Subject: Re: Renaming vs. modules To: info-cvs@prep.ai.mit.edu (CVS Info Maillist) Date: Mon, 5 Jun 1995 12:08:20 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO One would have to be a little bit crazy to plunge into the raging torrent of this discussion at this point, but then I was never known for being especially sane. :-) I'm interested that David "zoo" Zuhn has not commented -- much of the discussion has related to the mechanism for mapping source file names to version files, isn't this what his PDDB (per-directory data base) is meant to accomplish? As I imagine the PDDB (and I do mean "imagine" -- I have no real knowledge of what Dave has designed), it will look something like: Every object in the repository will be tracked in the PDDB. The contents of (a given version of) the PDDB will look like an extended 'ls -lg'. Extended in that a working file (or directory) "foo" may map to a version file "bar.v" in some other directory of the repository. Files and directories in the repository will _never_ move -- once created, the path to a file in the repository will never change (the Attic will go away). All appearance of change will be managed by the PDDB. Objects managed by the PDDB will include regular files: (managed as RCS version files), directories, symlinks, and "special" files (device files, FIFOs, etc). Attribute information about every object will be maintained in the PDDB, including: owner, group, permissions. (When I check out a file, I will own it, and my umask will influence its permissions; however, there should be a way to checkout (export?) a file with default owner, group, and permissions). Attribute information for symlinks and special files will include, e.g., the content of the symlink, and the type (b/c) and major and minor node numbers of the special file. When an object is initially created in the repository, it's location is the logical equivalent of its location in the workspace. Object removal is accomplished by updating the PDDB. Object rename is accomplished by an entry in the PDDB, to the effect that, as of version V of the directory, the working file foo maps to the version file bar,v. Object move is accomplished by an entry in the PDDB, to the effect that, as of version V of the directory, the working file foo maps to the version file ../dir2/foo,v. In the workspace, the CVS/Repository file will provide the path to the repository directory containing the PDDB file. The CVS/Entries file will be extended to include the full path to the version file. This change will permit files from multiple repository directories to reside in the same working directory. Collisions will not happen as duplicate working file names will not be permitted in the PDDB. Such a structure will require at least one change to RCS: The ability to speicfy the name of the version file when it does not correspond to the name of the working file. E.g., to checkout bar from the version file foo,v: co -l -F foo.v bar Questions: How does this structure meet the rename, etc., needs? What are the implications for locking and synchronization conflicts? Cheers, -- Steve Harris - Eaton Corp. - Beverly, MA - vsh%etnibsd@uunet.uu.net From info-cvs-request@prep.ai.mit.edu Mon Jun 5 13:21:40 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA01052 for ; Mon, 5 Jun 1995 13:21:09 -0400 Received: from Sun.COM by ulowell.uml.edu with SMTP id AA11597 (5.67b/IDA-1.5 for ); Mon, 5 Jun 1995 12:55:23 -0400 Received: from Central.Sun.COM (centralmail1.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA06028; Mon, 5 Jun 95 09:50:04 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA19561; Mon, 5 Jun 1995 11:49:54 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23570; Mon, 5 Jun 1995 10:44:54 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23566; Mon, 5 Jun 1995 10:44:53 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA19184; Mon, 5 Jun 1995 11:44:48 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id JAA13271; Mon, 5 Jun 1995 09:44:33 -0700 Received: from gateway.morgan.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA25475; Mon, 5 Jun 95 12:44:28 EDT Received: from rs1.fid.morgan.com ([138.20.1.17]) by gateway.morgan.com with SMTP id <41469>; Mon, 5 Jun 1995 12:44:09 -0400 Received: from sait136.morgan.com by rs1.fid.morgan.com (4.1/MS/FID/Sun-1.3) id AA13977; Mon, 5 Jun 95 12:43:32 EDT Received: by sait136.morgan.com (NX5.67e/NX3.0S) id AA00370; Mon, 5 Jun 95 12:40:21 -0400 Message-Id: <9506051640.AA00370@sait136.morgan.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Received: by NeXT.Mailer (1.118.3) From: Andrew C Athan Date: Mon, 5 Jun 1995 12:40:20 -0400 To: info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules Cc: woods@most.weird.com (Greg A. Woods), athan@morgan.com References: <199506051518.IAA09034@netcom23.netcom.com> Status: RO It seems we (Paul, Greg & I) have agreement/understanding over the various rename/module whatever features that have been discussed here, but have some issues as to how or why each should be implemented. Greg has proposed a methodology which I believe can fairly be characterized as more limited than a full mapping mechanism, but which has a clear and straight path to implementation. If my understanding is correct, I think it also fair to say that his proposal does not satisfactorally handle all project reconfiguration actions (e.g., renaming a fairly high level directory would require a lot of disk space). I believe his methodology is driven by a belief that CVS should remain a simple wrapper on top of RCS, and that the project reconfiguration actions taken by most CVS users are simple and infrequent. Though I disagree with both of the last two assertions (which may or may not be Greg's), as well as other assumptions that have motivated this design, the fact that there is a clearer understanding of what Greg is proposing is paramount--however, I think it would benefit the community if Greg would post a formal description. I think that discussion over what to implement is moot until we have a clear understanding of a "map" implementation, and a similar formal description...I'll try and post such a design in the next few days. In the meantime, functionality is what's important. So if you (Greg) have an implementation of what you proposed, I'd love to have it! (I have projects that would benefit immediately). aca From info-cvs-request@prep.ai.mit.edu Mon Jun 5 19:21:38 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA24311 for ; Mon, 5 Jun 1995 19:21:37 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24798; Mon, 5 Jun 95 16:17:57 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA14370; Mon, 5 Jun 1995 18:17:51 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14360; Mon, 5 Jun 1995 17:01:17 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14356; Mon, 5 Jun 1995 17:01:15 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA13395; Mon, 5 Jun 1995 18:01:10 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id QAA07264; Mon, 5 Jun 1995 16:01:06 -0700 Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA18173; Mon, 5 Jun 95 19:00:59 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA00721; Mon, 5 Jun 95 16:05:03 PDT Date: Mon, 5 Jun 95 16:05:03 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506052305.AA00721@sander.sander.cupertino.ca.us> To: etnibsd!vsh@uunet.uu.net, info-cvs@prep.ai.mit.edu Subject: Re: Renaming vs. modules Status: RO From: etnibsd!vsh@uunet.uu.net (Steve Harris) wrote: >I'm interested that David "zoo" Zuhn has not commented -- much of the >discussion has related to the mechanism for mapping source file names >to version files, isn't this what his PDDB (per-directory data base) is >meant to accomplish? And indeed, much of what came out during this discussion was mentioned in earlier discussion of the PDDB. [Description of PDDB omitted] >Questions: >How does this structure meet the rename, etc., needs? It appears to be capable of solving the problems I've pointed out, but there has so far been nothing said about how modules fit into the picture, how the CVS history log is affected, or certain user-interface details like how to locate an existing RCS file (perhaps one of many choices) to match a file that is re-added to a configuration. >What are the implications for locking and synchronization conflicts? Synchronization seems straightforward using the existing CVS mechanism. Locking becomes a bottleneck after many reorganizations because each of the user's working directories may require locks on multiple repository directories, but seems straightforward using the existing CVS mechanism. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Mon Jun 5 22:10:44 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA01826 for ; Mon, 5 Jun 1995 22:10:43 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14985; Mon, 5 Jun 95 19:05:57 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA18631; Mon, 5 Jun 1995 21:05:50 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA20310; Mon, 5 Jun 1995 20:00:37 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA20305; Mon, 5 Jun 1995 20:00:36 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA18522; Mon, 5 Jun 1995 21:00:31 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id TAA25471; Mon, 5 Jun 1995 19:00:30 -0700 Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA09035; Mon, 5 Jun 95 22:00:21 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA00933; Mon, 5 Jun 95 19:04:21 PDT Date: Mon, 5 Jun 95 19:04:21 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506060204.AA00933@sander.sander.cupertino.ca.us> To: woods@most.weird.com Subject: Re: Renaming vs. modules Cc: info-cvs@prep.ai.mit.edu Status: RO woods@most.weird.com (Greg A. Woods) wrote: >[ On Mon, June 5, 1995 at 01:28:34 (PDT), Paul Sander wrote: ] >> Subject: Re: Renaming vs. modules >> >> >Ah, but remember "renaming" is simply an extra step added to the "add, >> >delete" sequence -- namely the copying of old history to the "new" file. >> >> Nope, a rename involves changing the map between a source file and its >> version file. >I agree that a map would be an elegant solution. Any solution involving >pointers is no doubt more efficient in some ways than keeping multiple >copies of data, and moving large quantities of data about. However, >complexity is also a factor, and the need for a perfect solution must be >weighed against the cost of providing it. I'm more concerned about having a correct solution to the problems I've encountered. It seems that I've had more problems in these areas than you have, for whatever reasons. If the solution is elegant and performs well, then so much the better. Crippling an important feature because it's harder to implement a correct solution is not a good approach. If the crippled approach works for one shop, that's good for them, but I have my share of problems to solve with the tool too, and I require something better. >I would like to suggest that complex renaming of files and directories >(i.e. when they move about on the directory tree, and don't just change >their labels), is a relatively rare occurance in a development >environment, and with a little bit of planning on the part of the >developers contemplating such moves, simple extensions to the current >facilities will be more than adequate to serve their needs. It's not. My experience has been that major reorganizations are done about once per major revision, and minor reogranizations (renaming a mid-level directory containing child and grandchild directories) occurs about 3 times per year. The developers require that complete and correct revision history be kept in all cases. In all cases, the shape of the design is planned and tested well in advance, but new features or whatever make it somehow better to reorganize the project. I've seen this happen both with new development of large projects, and also with licensed operating system source code. >So, in this discussion I've been thinking primarily of renames that >move files from one directory to another, and how to deal with this >given the recursive nature of CVS -- i.e. how to keep enough information >in each directory such that some central shared database is not required. The approach you've outlined is fine for small projects where small reorganizations are performed occasionally; copying an RCS file to a new place in the repository is fine if it's not done often, the moved file is never moved again, and no branches are involved. But such projects are small, perhaps 200K lines of code plus documentation. But the larger the project, the greater the frequency in which it gets reorganized. Users of CVS who work on large projects should reasonably expect CVS to perform correctly, even in the presence of many branches, a long project lifespan, and large reorganizations. >For the case of simply changing labels within the same container >directory, a map of some sort, that could be stored in each repository >directory, should be quite simple to implement and would provide a good >deal of efficiency. True, and the PDDB looks like a good implementation for this, and also the more general problem. >I'd be very curious to see a detailed specification of the data >structures and operations necessary to build a distributed map (i.e. one >that lives in each sub-directory and doesn't require some central >semaphore for modifications), esp. one that can work given the current >recursive operation of CVS. I cannot even begin to picture such a >creature if it is required to support all of the possible types of >renaming that have been proposed. Me too. >> An add and delete sequence are inadequate for the following >> reasons: >> - Multiple copies of the same RCS file are kept, and they each contain >> incomplete histories. >> - Depending on the implementation, history may be lost during a rename. >Both of these problems would be simple implementation deficiencies that >can easily be corrected, and in fact our later conversation indicates >how they would be corrected. >> - Renames are not reversible; or if they are, merging histories is a >> nightmare. >Huh? You've got two ,v files. One is a historical archive used only >for restoring old versions. Another is the new working file. Reversing >the rename means simply copying the new working file back to the >directory it was once in, and moving the now old working file into the >Attic in the intermediate directory. I'm afraid there's more to it than that, as shown in this example: - File A is created in directory D. - Directory D meets its shipment criteria. - A branch in directory D is created, to be used for maintenance. - Directory D is renamed to E. - Modifications are done to A for the next release. - Modifications are done to A for maintenance. - Directory E is renamed back to D. Here, the differing revision histories of A must be merged in a meaningful way. Replacing the old A loses all of the maintenance that was done. Another thing to consider is what to do if changes are made to A that are intended to be new development, but were mistakenly made in directory D before it was first renamed. With a map, the same revision file is used, so it's easy to discover such changes; with a copy of the RCS file, it's harder to discover such changes. >We need to do one further trick that CVS currently doesn't support. We >need to know that a specified range of delta's is off limits for the >renamed file. We can get the hint this is necessary because there's >both an Attic file, and a current file with the same name. (In a copy implementation, RCS version state could be used for this.) >If this is a reversed rename, where the current file also contains the >same initial deltas as the Attic copy, discovering the off-limit set of >deltas is easy, unless the entire rename/reverse process is repeated, in >which case this optimisation fails. >I suppose we can optimise space utilisation if we know it is the same >file being replaced by deleting the Attic copy. A list of off-limit >deltas for this directory is still required though. >If another old file with competing deltas and tags is renamed into >conflict with an Attic file, a list of off-limit deltas should still >suffice. What if revision 1.1 isn't the same for both files, i.e. a file replaces one with the same name? The revision history and tags must be remapped completely. This is especially nasty if the types of data differ. For this, having separate revision files is preferred. >Perhaps the easiest way to build this list is to keep it updated all the >time (i.e. pay a small price incrementally). I.e. every time a delta is >created, append it to the list of valid deltas kept for the filename >while it resides in a given directory and always keep this list as a >part of the directory. >> - A new file cannot be added to replace a file that has been renamed >> away. >Why not? This is the easy case. CVS need only recognize the conflict >with the Attic file and deal with it appropriately. Only if there's >been a mistake will a version of the Attic file and a version of the new >file both be checked out on a date/tag based checkout/export. I'm not >even sure CVS doesn't implicitly support this already! What do you mean by "deal with it appropriately"? Neither RCS file can be removed, but both are needed. You can: - Disallow the move (bad) - Merge revisions and tags (hard and slow, probably wrong, and does remaps revision numbers in ways the user doesn't expect) - Lose the old RCS file (very bad) Unless you plan to keep the old RCS file in the Attic and put the new one in its parent, but then that only postpones the problem until a "cvs remove" is done. >> I have implemented a file rename capability in CVS 1.3 that was based >> on copying an RCS file from source to destination directory, and moving >> the original into the source directory's Attic. It suffered from all >> of these problems. I implemented a directory rename capability that >> invoked the file rename feature for everything in a directory, with >> optional recursive descent. The resulting jumble in the repository was >> awful after just a few reorgs, and an enormous amount of space was wasted. >We have to remember that space is cheap for most folks now, even those >folks such as one of our clients who are contemplating use of CVS and >who have about 250 Mb of source code (and who would have well over a Gb >or two of ,v files if they had been keeping versions from day one). I've worked in a shop that had three multi-gigabyte source code repositories, after the RCS files were compressed. (We hacked CVS and RCS to do this.) Space isn't so cheap to to reorganize these things often, and time is an issue. >Remember that extra space represents at least one way of restoring old >configurations. If you don't think you'll ever need them, delete them! >> There are many possible notions of what is part of a module at a given >> time, depending on what branch you live on. The Attic implementation >> does not solve this problem adequately, as we see by the number of problems >> reported to this list in this area. >> >> Because maps are subject to the same versioning and branching as files, >> they work much better at tracking strange things that might happen on >> branches and can be used to implement much more reasonable behavior when >> merges are done than is possible with an Attic implementation. >Ah, branches. What wonderful structures they are! >Of course I've been assuming that complex renames are not possible on >branches for the same reason that files cannot be added or deleted only >on a branch. >I think this is a fair assumption to make, especially given the apparent >goals of a tool that's a "simple" wrapper on a file-by-file source code >tool. The goal is to have a usable tool that produces correct results. If it's simple, so much the better; but simplicity should not be traded for correct behavior. Adding files on a branch is a basic, necessary capability that is needed during maintenance. Renaming and removal are desirable but may or may not be required. (I haven't seen any cases where they were needed, but I don't have to stretch my imagination too far to see why they might be.) >> Like I said above, I've already implemented this. It is a partial >> solution to a sticky problem, which introduces many new problems. I very >> strongly recommend against this type of implementation. >Well, for your goals, this indeed might be true. >However, for all of the situations I've encountered while using CVS, >this level of solution is more than adequate. We need to use the same tool. If the more robust solution works for you too, why not use it? I require the more robust solution. >I should note one other assumption I've made, but not stated. I assume >that when tracking third party sources, if a significant re-organization >is made to the product source tree, a new module will be created. Once >the local changes have been extracted from the old module, it can be >kept, or can be replaced by the new one, depending on the requirements >for supporting the old version locally. This is fine for shops that use the modules database. Many large projects don't. >In conclusion I would say that what I've proposed extends CVS >sufficiently that it can provide a more than adequate set of facilities >to manage the requirements of most small software shops, and many large >shops willing to provide the management overhead necessary to work >around the "deficiencies" of CVS. CVS already provides a nice blend of >the features necessary for supporting both original developement and >third party source maintenance. This is true for small projects, and a few larger ones. I've already had to live with such a solution, and found it inadequate. It's time for something better. >If anyone wants to think about a complex task, how about devising some >way to guess at structural changes between third party releases. I'd >love to have "cvs import" be able to say something like "It appears that >over 50% of the lines in the new file a/b/c/foo.t are the same as those >in the old file d/e/f/bar.g. Should I rename it?". It should also >handle the simple case of deleting old files, after it has determined >that none of them were renamed. And perhaps it could also manage the >now more complex job of generating local patches to re-apply to a new >local version. Tough problem. It may not have a completely automated and accurate solution, but there are some heuristics that can provide a good start. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Tue Jun 13 12:56:56 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA10117 for ; Tue, 13 Jun 1995 12:56:54 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18193; Tue, 13 Jun 95 09:53:32 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA26761; Tue, 13 Jun 1995 11:53:25 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29849; Tue, 13 Jun 1995 10:40:47 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29845; Tue, 13 Jun 1995 10:40:45 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA26081; Tue, 13 Jun 1995 11:40:41 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id JAA19069; Tue, 13 Jun 1995 09:40:41 -0700 Received: from SSD.intel.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12884; Tue, 13 Jun 95 12:40:38 EDT Received: from sv004.scic.intel.com by SSD.intel.com (4.1/SMI-4.1) id AA20902; Tue, 13 Jun 95 09:40:37 PDT Received: from rs019.scic.intel.com by sv004.scic.intel.com (4.1/sun41.1); Tue, 13 Jun 95 09:42:06 PDT Received: by rs019.scic.intel.com (AIX 3.2/UCB 5.64/rs32.1); Tue, 13 Jun 1995 09:41:27 -0700 Date: Tue, 13 Jun 1995 09:41:27 -0700 From: sharma@scic.intel.com (Arun Sharma) Message-Id: <9506131641.AA12834@rs019.scic.intel.com> To: info-cvs@prep.ai.mit.edu Subject: CVS bug ?? Status: RO Hi, I just installed cvs on a x86 pc running solaris 2.0 and I'm running into this strange problem. After setting up $CVSROOT and other stuff properly, I try cvs import doctor TEST FIRST and here is what happens.. U doctor/Changelog U doctor/Makefile U doctor/TAGS U doctor/Todo U doctor/Files cvs import: Importing /users/sharma/cvs_root/doctor/. U doctor/./Changelog U doctor/./Makefile U doctor/./TAGS U doctor/./Todo U doctor/./Files cvs import: Importing /users/sharma/cvs_root/doctor/./. U doctor/././Changelog U doctor/././Makefile U doctor/././TAGS U doctor/././Todo U doctor/././Files cvs import: Importing /users/sharma/cvs_root/doctor/././. It doesn't come out of the recursion, until I break it. Can you help ? Thanks, -- Arun From info-cvs-request@prep.ai.mit.edu Tue Jun 13 14:26:33 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA14990 for ; Tue, 13 Jun 1995 14:25:57 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00476; Tue, 13 Jun 95 11:21:44 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA02001; Tue, 13 Jun 1995 13:21:36 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04556; Tue, 13 Jun 1995 12:05:26 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA04552; Tue, 13 Jun 1995 12:05:24 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA01030; Tue, 13 Jun 1995 13:05:19 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id LAA06531; Tue, 13 Jun 1995 11:04:36 -0700 Received: from sander.sander.cupertino.ca.u ([192.148.188.3]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA17979; Tue, 13 Jun 95 14:04:00 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA11737; Tue, 13 Jun 95 11:08:08 PDT Date: Tue, 13 Jun 95 11:08:08 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506131808.AA11737@sander.sander.cupertino.ca.us> To: info-cvs@prep.ai.mit.edu, sharma@scic.intel.com Subject: Re: CVS bug ?? Status: RO sharma@scic.intel.com (Arun Sharma) wrote: >I just installed cvs on a x86 pc running solaris 2.0 and I'm running >into this strange problem. >After setting up $CVSROOT and other stuff properly, I try >cvs import doctor TEST FIRST and here is what happens.. [...] >U doctor/././Files >cvs import: Importing /users/sharma/cvs_root/doctor/././. >It doesn't come out of the recursion, until I break it. Try this: cvs import -I. doctor TEST FIRST There is a bug in CVS 1.3 that omits "." from the ignore list during imports. Alternatively, you could create a $HOME/.cvsignore file that contains a single line with a period. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Tue Jun 13 14:27:23 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA28890 for ; Tue, 13 Jun 1995 14:27:21 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00819; Tue, 13 Jun 95 11:24:03 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA02209; Tue, 13 Jun 1995 13:23:52 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA05169; Tue, 13 Jun 1995 12:17:40 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA05165; Tue, 13 Jun 1995 12:17:39 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA01772; Tue, 13 Jun 1995 13:17:34 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id LAA07922; Tue, 13 Jun 1995 11:17:28 -0700 Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA18598; Tue, 13 Jun 95 14:17:18 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA19670; Tue, 13 Jun 1995 14:17:07 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA27823; Tue, 13 Jun 95 14:17:05 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id OAA06666; Tue, 13 Jun 1995 14:17:04 -0400 Date: Tue, 13 Jun 1995 14:17:04 -0400 Message-Id: <199506131817.OAA06666@kayak.odi.com> To: nyap@garban.com Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9506131647.AA00649@> (nyap@garban.com) Subject: Re: Segmentation fault when using checkin Reply-To: dgg@odi.com Status: RO > I get a segmentation fault when I try to checkin several files: > cvs checkin module0/file0 module0/file1 > > It doesn't seem to happen when I try to checkin several modules: > cvs checkin module0 module1 > > If there's a FAQ on this, please refer me to it. > Thanks. This is a bug in CVS 1.3. You can't have '/' characters in a "cvs checkin" argument or you get core dumps. It doesn't happen every time, but it happens enough that you should get used to using "cd" to move into each directory if you don't want to specify the whole directory. Or upgrade to CVS 1.4A2 I don't think this bug ever made the FAQ. Maybe I should add an Archaelogical (Paleontological?) section for common 1.3 bugs. Anyone have a list? I scoured 1.3 bugs out of the FAQ a long time ago. From info-cvs-request@prep.ai.mit.edu Tue Jun 13 12:54:38 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA19707 for ; Tue, 13 Jun 1995 12:54:35 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18064; Tue, 13 Jun 95 09:51:43 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA26619; Tue, 13 Jun 1995 11:51:35 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00341; Tue, 13 Jun 1995 10:47:58 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00337; Tue, 13 Jun 1995 10:47:57 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA26452; Tue, 13 Jun 1995 11:47:54 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id JAA20122; Tue, 13 Jun 1995 09:47:54 -0700 Received: from psi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13199; Tue, 13 Jun 95 12:47:51 EDT Received: from by psi.com (8.6.10/2.1-PSI/PSINet) id MAA18379; Tue, 13 Jun 1995 12:47:53 -0400 Received: by (5.0/SMI-SVR4) id AA00649; Tue, 13 Jun 1995 12:47:41 -0400 Date: Tue, 13 Jun 1995 12:47:41 -0400 From: nyap@garban.com (Noel Yap) Message-Id: <9506131647.AA00649@> To: info-cvs@prep.ai.mit.edu Subject: Segmentation fault when using checkin X-Sun-Charset: US-ASCII Status: RO I get a segmentation fault when I try to checkin several files: cvs checkin module0/file0 module0/file1 It doesn't seem to happen when I try to checkin several modules: cvs checkin module0 module1 If there's a FAQ on this, please refer me to it. Thanks. From info-cvs-request@prep.ai.mit.edu Fri Jun 16 15:08:24 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA19011 for ; Fri, 16 Jun 1995 15:08:22 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA07983; Fri, 16 Jun 95 11:51:57 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA00587; Fri, 16 Jun 1995 13:51:47 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14140; Fri, 16 Jun 1995 12:36:12 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14136; Fri, 16 Jun 1995 12:36:10 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA29660; Fri, 16 Jun 1995 13:35:59 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id LAA04843; Fri, 16 Jun 1995 11:35:58 -0700 Received: from idefix.comco.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA18463; Fri, 16 Jun 95 14:35:55 EDT Received: from idefix.comco.com (meyering@localhost) by idefix.comco.com (8.6.10/8.6.9) with ESMTP id NAA10730; Fri, 16 Jun 1995 13:35:49 -0500 Message-Id: <199506161835.NAA10730@idefix.comco.com> To: derek.baum@sbil.co.uk Subject: Re: cvs -n update fails in CVS1.4A2 when conflict exists Cc: info-cvs@prep.ai.mit.edu Return-Receipt-To: meyering@comco.com Date: Fri, 16 Jun 1995 13:35:49 -0500 From: Jim Meyering Status: RO Here's how I fixed this: I sent this same report to bug-cvs, then forwarded it to info-cvs. Forwarded: Tue, 04 Apr 1995 12:24:14 -0500 Forwarded: "info-cvs@prep.ai.mit.edu " Received: (from meyering@localhost) by idefix.comco.com (8.6.10/8.6.9) id MAA20647; Tue, 4 Apr 1995 12:09:12 -0500 Date: Tue, 4 Apr 1995 12:09:12 -0500 From: Jim Meyering Message-Id: <199504041709.MAA20647@idefix.comco.com> To: bug-cvs@prep.ai.mit.edu Subject: simple fix for `cvs -n update' bug Reply-To: meyering X-send-pr-version: 3.2 >Submitter-Id: net >Originator: Jim Meyering >Organization: Computational Mechanics Co. Inc. >Confidential: no >Synopsis: simple fix for `cvs -n update' bug >Severity: serious >Priority: medium >Category: cvs >Class: sw-bug >Release: cvs-1.4A2 >Environment: System: IRIX idefix 5.3 11091810 IP12 mips >Description: cvs -n update fails when there is a conflict because it tries to run merge_file in spite of the -n flag. >How-To-Repeat: - check out two copies of a module - modify and commit a file in one copy - modify that same file in the other copy of the module so it conflicts, then run `cvs -n update file' >Fix: In update_file_proc, in case T_NEEDS_MERGE, output `C' and the file name instead of calling merge_file. Index: update.c =================================================================== RCS file: /w/src/cvsroot/cvs/src/update.c,v retrieving revision 1.12 diff -u -F^[_a-zA-Z$][_a-zA-Z0-9$]*.(\(.*)[^;]*\|[^;]+,$\) -r1.12 update.c --- update.c 1995-01-10 15:13:53-0600 1.12 +++ update.c 1995-04-04 11:50:24-0500 @@ -357,8 +357,16 @@ update_file_proc (file, update_dir, repo (void) write_letter (file, 'C', update_dir); break; case T_NEEDS_MERGE: /* needs merging */ - retval = merge_file (file, repository, entries, - vers, update_dir); + if (noexec) + { + retval = 1; + (void) write_letter (file, 'C', update_dir); + } + else + { + retval = merge_file (file, repository, entries, + vers, update_dir); + } break; case T_MODIFIED: /* locally modified */ retval = 0; From info-cvs-request@prep.ai.mit.edu Fri Jun 16 14:49:45 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA20747 for ; Fri, 16 Jun 1995 14:49:42 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05785; Fri, 16 Jun 95 11:36:50 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA29715; Fri, 16 Jun 1995 13:36:43 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13984; Fri, 16 Jun 1995 12:33:59 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13980; Fri, 16 Jun 1995 12:33:57 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA29519; Fri, 16 Jun 1995 13:33:50 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id LAA04543; Fri, 16 Jun 1995 11:33:45 -0700 Received: from kuma.web.net by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA18305; Fri, 16 Jun 95 14:33:36 EDT Received: by kuma.web.net via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.30.7.0.2 #30.1 built 17-may-95) id ; Fri, 16 Jun 95 14:26 EDT Message-Id: Date: Fri, 16 Jun 95 14:26 EDT From: woods@kuma.web.net (Greg A. Woods) To: mturok@bfm.com Cc: info-cvs@prep.ai.mit.edu Subject: Re: make and automatic retrieval from cvs In-Reply-To: mturok@bfm.com's message of "Fri, June 16, 1995 12:53:38 EDT" regarding "make and automatic retrieval from cvs" id <9506161653.AA15163@dev9.dev0> References: <9506161653.AA15163@dev9.dev0> Reply-To: woods@kuma.web.net (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (sparc-sun-sunos4.1.3) of Fri Mar 10 1995 on kuma Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Fri, June 16, 1995 at 12:53:38 (EDT), mturok@bfm.com wrote: ] > Subject: make and automatic retrieval from cvs > > > Has anyone set up their makefile to automatically retrieve new changes > made to any dependency in your build from the cvs repository? I > couldn't find any mention of this in the cvs info pages. It's probably not what you're thinking of, but how about: all: CVS-UPDATE real-all real-all: $(PRODUCTS) CVS-UPDATE: FRC cvs -q update -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets Of The Weird From info-cvs-request@prep.ai.mit.edu Fri Jun 16 13:46:11 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA22993 for ; Fri, 16 Jun 1995 13:45:57 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24778; Fri, 16 Jun 95 10:21:41 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA25818; Fri, 16 Jun 1995 12:21:34 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10287; Fri, 16 Jun 1995 11:09:58 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA10283; Fri, 16 Jun 1995 11:09:57 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA24964; Fri, 16 Jun 1995 12:09:53 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id KAA17578; Fri, 16 Jun 1995 10:09:46 -0700 Received: from uu9.psi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13633; Fri, 16 Jun 95 13:09:43 EDT Received: from garfield.UUCP by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA14691 for ; Fri, 16 Jun 95 13:04:23 -0400 Received: from dev9.dev0 by garfield.bfm.com (4.1/SMI-4.1) id AA22597; Fri, 16 Jun 95 12:53:37 EDT Received: by dev9.dev0 (4.1/SMI-4.1) id AA15163; Fri, 16 Jun 95 12:53:38 EDT Date: Fri, 16 Jun 95 12:53:38 EDT From: mturok@bfm.com Message-Id: <9506161653.AA15163@dev9.dev0> To: info-cvs@prep.ai.mit.edu Subject: make and automatic retrieval from cvs Status: RO Has anyone set up their makefile to automatically retrieve new changes made to any dependency in your build from the cvs repository? I couldn't find any mention of this in the cvs info pages. I know that gnu make has a built-in awareness of RCS, but that requires setting up a link to the directory containing the ",v" files. Is that required in cvs? Is there a better way? Please send all replies be Cc'ed to mturok@bfm.com. Michael -- +----------------------------------------------------------+ |Michael Turok email: mturok@bfm.com | |Blackrock Financial Management phone: (212) 754-5593 | |New York, NY | +----------------------------------------------------------+ From lechner Fri Jun 16 17:25:56 1995 Received: (from lechner@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id RAA22501 for lechner; Fri, 16 Jun 1995 17:25:56 -0400 From: Bob Lechner Message-Id: <199506162125.RAA22501@jupiter.cs.uml.edu> Subject: Re: CVS bug ?? (recursoin on "." path) To: lechner Date: Fri, 16 Jun 1995 17:25:55 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1377 Status: RO Forwarded message: >From info-cvs-request@prep.ai.mit.edu Fri Jun 16 01:04:27 1995 Date: Thu, 15 Jun 95 21:38:54 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9506160438.AA15562@sander.sander.cupertino.ca.us> To: dlange@nosc.mil, info-cvs@prep.ai.mit.edu Subject: Re: CVS bug ?? dlange@nosc.mil (Doug Lange) wrote: >>From: paul@sander.cupertino.ca.us (Paul Sander) >>Try this: >> >>cvs import -I. doctor TEST FIRST >> >>There is a bug in CVS 1.3 that omits "." from the ignore list during imports. >>Alternatively, you could create a $HOME/.cvsignore file that contains a >>single line with a period. >I too am seeing this on Solaris 2.4. I tried Paul's solution but to no >avail. Not only is '.' recursing but if I use -I to ignore any other files >they are not ignored either. Does not look as if any ignore capability is >working either from -I or .cvsignore. >Did the solution work for the original complaintant?? >Any more ideas on what is wrong? That is what it is. I use the following in my $HOME/.cvsignore file, and am able to use "cvs import" without incident, using CVS 1.3. In fact, I just confirmed this today by importing a new product under CVS control. My $HOME/.cvsignore file in place when I performed the import contained this line: ! . .. At another site I use, also without incident, these four lines: ! . .. .cvsignore From info-cvs-request@prep.ai.mit.edu Fri Jun 16 16:26:45 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA30354 for ; Fri, 16 Jun 1995 16:26:43 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18871; Fri, 16 Jun 95 13:09:06 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA05972; Fri, 16 Jun 1995 15:09:00 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA17992; Fri, 16 Jun 1995 14:04:31 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA17988; Fri, 16 Jun 1995 14:04:29 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA05524; Fri, 16 Jun 1995 15:04:26 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA15537; Fri, 16 Jun 1995 13:04:24 -0700 Received: from kuma.web.net by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA23794; Fri, 16 Jun 95 16:04:19 EDT Received: by kuma.web.net via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.30.7.0.2 #30.1 built 17-may-95) id ; Fri, 16 Jun 95 16:03 EDT Message-Id: Date: Fri, 16 Jun 95 16:03 EDT From: woods@kuma.web.net (Greg A. Woods) To: mturok@bfm.com Cc: info-cvs@prep.ai.mit.edu Subject: Re: make and automatic retrieval from cvs In-Reply-To: mturok@bfm.com's message of "Fri, June 16, 1995 15:17:57 EDT" regarding "Re: make and automatic retrieval from cvs" id <9506161917.AA18489@dev9.dev0> References: <9506161653.AA15163@dev9.dev0> <9506161917.AA18489@dev9.dev0> Reply-To: woods@kuma.web.net (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (sparc-sun-sunos4.1.3) of Fri Mar 10 1995 on kuma Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [[ GRRRR!!!! I hate PSI's mailer!!!! kuma.web.net!woods@uu9.psi.com (Greg A. Woods) ]] [ On Fri, June 16, 1995 at 15:17:57 (EDT), mturok@bfm.com wrote: ] > Subject: Re: make and automatic retrieval from cvs > > Greg> It's probably not what you're thinking of, but how about: > > > Greg> all: CVS-UPDATE real-all > > Greg> real-all: $(PRODUCTS) > > Greg> CVS-UPDATE: FRC > Greg> cvs -q update > > This won't update the header files my *.C depend on, however. Are your header files not a part of the module you're working within? If not, are you not performing release management on their module and installing them in some standard place on your system? In general I'd recommend that your CVS module encompass everything that your Makefile depends upon. You should treat everything outside of that module as separately released software, and if there are release differences that cause compatability issues, a scheme such as Sun's shared library numbering could be used (but perhaps on the directory names, or some such).... -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets Of The Weird From info-cvs-request@prep.ai.mit.edu Fri Jun 16 11:14:02 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA00152 for ; Fri, 16 Jun 1995 11:13:57 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA08088; Fri, 16 Jun 95 07:58:15 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA15667; Fri, 16 Jun 1995 09:58:09 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03715; Fri, 16 Jun 1995 08:51:38 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03711; Fri, 16 Jun 1995 08:51:36 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA15299; Fri, 16 Jun 1995 09:51:31 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id HAA00774; Fri, 16 Jun 1995 07:51:29 -0700 Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA05073; Fri, 16 Jun 95 10:51:26 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA12765; Fri, 16 Jun 1995 10:51:15 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA06890; Fri, 16 Jun 95 10:51:13 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id KAA05300; Fri, 16 Jun 1995 10:51:12 -0400 Date: Fri, 16 Jun 1995 10:51:12 -0400 Message-Id: <199506161451.KAA05300@kayak.odi.com> To: paul@sander.cupertino.ca.us Cc: dlange@nosc.mil, info-cvs@prep.ai.mit.edu, paul@sander.cupertino.ca.us In-Reply-To: <9506160535.AA15659@sander.sander.cupertino.ca.us> (paul@sander.cupertino.ca.us) Subject: Re: CVS bug ?? Reply-To: dgg@odi.com Status: RO > Hmmm. Just got bitten by a mail bug. Those last three lines were > dropped from my message somewhere along the line. Here's a one-line > equivalent: > > ! . .. .cvsignore There is some justification in calling it a bug, but it is an intentional feature of sendmail. A line consisting entirely of a single dot (".") has meant "End of Message" (at least to sendmail) for a very long time now. From info-cvs-request@prep.ai.mit.edu Fri Jun 16 16:44:57 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA21296 for ; Fri, 16 Jun 1995 16:44:55 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20892; Fri, 16 Jun 95 13:24:42 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA07273; Fri, 16 Jun 1995 15:22:45 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18331; Fri, 16 Jun 1995 14:09:51 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18327; Fri, 16 Jun 1995 14:09:49 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA06027; Fri, 16 Jun 1995 15:09:46 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA16236; Fri, 16 Jun 1995 13:09:39 -0700 Received: from uu9.psi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AB23938; Fri, 16 Jun 95 16:09:33 EDT Received: from garfield.UUCP by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA07343 for ; Fri, 16 Jun 95 16:03:55 -0400 Received: from dev9.dev0 by garfield.bfm.com (4.1/SMI-4.1) id AA24815; Fri, 16 Jun 95 15:48:59 EDT Received: by dev9.dev0 (4.1/SMI-4.1) id AA18609; Fri, 16 Jun 95 15:49:01 EDT Date: Fri, 16 Jun 95 15:49:01 EDT From: mturok@bfm.com Message-Id: <9506161949.AA18609@dev9.dev0> To: info-cvs@prep.ai.mit.edu Subject: Re: make and automatic retrieval from cvs In-Reply-To: <9506161740.AA00496@cambric> References: <9506161653.AA15163@dev9.dev0> <9506161740.AA00496@cambric> Status: RO (I have merged two replies from Tom Tromey and David `zoo' Zhuh). My responses are at the bottom. >>>>> "mturok" == mturok writes: mturok> Has anyone set up their makefile to automatically retrieve new mturok> changes made to any dependency in your build from the cvs mturok> repository? I couldn't find any mention of this in the cvs mturok> info pages. mturok> I know that gnu make has a built-in awareness of RCS, but that mturok> requires setting up a link to the directory containing the mturok> ",v" files. Is that required in cvs? Is there a better way? >>>>> On Fri, 16 Jun 95 11:40:41 MDT, Tom Tromey said: Tom> I'm not sure this is what you really want. Tom> Don't do this with CVS! It will wreak havoc. Tom> CVS isn't like RCS, really. They require different ways of looking at Tom> the problems of source control. Tom> Generally I've found that I want to be able to decide when I Tom> incorporate other people's changes into my source tree. For Tom> instance if I am right in the middle of a major change, I Tom> generally don't want to "cvs update", because the results can be Tom> confusing. This can be true even when the code currently in my Tom> source tree compiles. Tom> What we've done is set up a mailing list that gets notified Tom> whenever anyone does a commit. Then all the developers see when Tom> things change, and can decide for themselves whether or not to Tom> update. >>>>> On Fri, 16 Jun 1995 12:42:29 -0500, "david d `zoo' zuhn" said: david> This tends to be different from the basic use of CVS, in which david> the User is the one to decide when something needs to be david> updated from the repository. Doing this via Make, david> automatically, would be damned near imposible. david> Why do you feel this is needed, as opposed to letting the david> developer update the tree as needed. I think the same way you two do -- I don't want anyone else's changes impacting me until I am ready for them. However, some people here believe you should automatically check out new copies of code from SCCS when you compile. We are currently contemplating changing from sccs->cvs, and I wanted to try to maintain that functionality. This is supported using SCCS and Sun's make through the .SCCS_GET target. Under cvs, there doesn't seem to be a clear way to do it, as you both stated. I think the problem comes in when you have a large, multi-library system, with separate work areas for each individual user. However, each user doesn't have a complete copy of all of the code; he/she only checks out the code he/she is working on. The rest is linked in from the production area. It sounds like the easiest thing to do is to simply do a 'cvs update' at the top level of our tree, whenever they compile. This will insure that all their working code gets updated with respect to our respository. This way, all headers, as well as *.C get updated. Michael +----------------------------------------------------------+ |Michael Turok email: mturok@bfm.com | |Blackrock Financial Management phone: (212) 754-5593 | |New York, NY | +----------------------------------------------------------+ From info-cvs-request@prep.ai.mit.edu Thu Jun 15 17:13:22 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA02228 for ; Thu, 15 Jun 1995 17:13:20 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA01494; Thu, 15 Jun 95 14:06:46 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA17576; Thu, 15 Jun 1995 16:06:38 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29521; Thu, 15 Jun 1995 14:56:46 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29515; Thu, 15 Jun 1995 14:56:45 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA16847; Thu, 15 Jun 1995 15:56:40 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA03686; Thu, 15 Jun 1995 13:56:34 -0700 From: algeej@ccmail.ncsc.navy.mil Received: from telesys.ncsc.navy.mil ([130.109.120.22]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA15356; Thu, 15 Jun 95 16:56:27 EDT Received: from CCMAIL.NCSC.NAVY.MIL by telesys.ncsc.navy.mil (4.1/SMI-4.1) id AA06528; Thu, 15 Jun 95 15:12:04 PDT Received: from cc:Mail by CCMAIL.NCSC.NAVY.MIL id AA803255944; Thu, 15 Jun 95 15:35:39 CDT Date: Thu, 15 Jun 95 15:35:39 CDT Encoding: 9 Text Message-Id: <9505158032.AA803255944@CCMAIL.NCSC.NAVY.MIL> To: info-cvs@prep.ai.mit.edu, Johnny Tang Subject: Re: log message for C++ code Status: RO > How can I turn off the log message for cvs checkout > The cvs inserts the log message in the c++ file incorrectly Invoke the command: "cvs admin -c//" This will change the comment leader string to "//" and then each line of the source code will have this as a comment. From info-cvs-request@prep.ai.mit.edu Thu Jun 15 16:57:59 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA31945 for ; Thu, 15 Jun 1995 16:57:54 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00272; Thu, 15 Jun 95 13:52:05 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA16573; Thu, 15 Jun 1995 15:51:57 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28300; Thu, 15 Jun 1995 14:35:56 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28295; Thu, 15 Jun 1995 14:35:55 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA15524; Thu, 15 Jun 1995 15:35:51 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA00440; Thu, 15 Jun 1995 13:35:45 -0700 Received: from spsgate.sps.mot.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13938; Thu, 15 Jun 95 16:35:33 EDT Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA00578 for info-cvs@prep.ai.mit.edu; Thu, 15 Jun 95 13:35:28 MST Received: from motsps by mogate (4.1/SMI-4.1/Email-2.0) id AA18358; Thu, 15 Jun 95 13:35:26 MST Received: from risc.sps.mot.com by motsps (4.1/SMI-4.1/Email-2.1) id AA14946 for info-cvs@prep.ai.mit.edu; Thu, 15 Jun 95 13:35:24 MST Received: from miaow.sps.mot.com by risc.sps.mot.com (4.1/SMI-3.0DEV3) id AA23465; Thu, 15 Jun 95 15:35:21 CDT Received: by miaow.sps.mot.com (AIX 3.2/UCB 5.64/4.03) id AA12177; Thu, 15 Jun 1995 15:35:19 -0500 From: dwolfe@risc.sps.mot.com (Dave Wolfe) Message-Id: <9506152035.AA12177@miaow.sps.mot.com> Subject: Re: log message for C++ code To: tang@cebaf.gov (Johnny Tang) Date: Thu, 15 Jun 1995 15:35:19 -0500 (CDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9506151958.AA11505@life.ai.mit.edu> from "Johnny Tang" at Jun 15, 95 03:58:04 pm Reply-To: David Wolfe X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO [ Johnny Tang writes: ] > How can I turn off the log message for cvs checkout ? > > The cvs inserts the log message in > the c++ file incorrectly: > > Example: > [...] > // Revision History: > // $Log: ns.l,v $ > * Revision 1.1.1.1 1995/06/01 22:23:40 epics > * Initial import of cdev source. > * > // cvs admin -ko RCS recognizes files by the extension. I doubt that it recognizes ns.l as a C++ file. -- Dave Wolfe *Not a spokesman for Motorola* (512) 891-3246 Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598 From info-cvs-request@prep.ai.mit.edu Thu Jun 15 16:42:00 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA00361 for ; Thu, 15 Jun 1995 16:41:58 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28813; Thu, 15 Jun 95 13:37:40 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA15630; Thu, 15 Jun 1995 15:37:30 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27397; Thu, 15 Jun 1995 14:20:25 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27393; Thu, 15 Jun 1995 14:20:23 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA14655; Thu, 15 Jun 1995 15:20:20 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA28497; Thu, 15 Jun 1995 13:20:13 -0700 Received: from netmail.austin.ibm.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13061; Thu, 15 Jun 95 16:19:55 EDT Received: from fliegen.austin.ibm.com (fliegen.austin.ibm.com [129.35.128.200]) by netmail.austin.ibm.com (8.6.11/8.6.11) with SMTP id PAA29175; Thu, 15 Jun 1995 15:19:53 -0500 Received: by fliegen.austin.ibm.com (AIX 9518A-UP 4.1/UCB 5.64/4.03-client-2.6) for info-cvs@prep.ai.mit.edu at austin.ibm.com; id AA36904; Thu, 15 Jun 1995 15:19:49 -0500 From: knutson@austin.ibm.com (Jim Knutson) Message-Id: <9506152019.AA36904@fliegen.austin.ibm.com> Subject: Re: log message for C++ code To: tang@cebaf.gov (Johnny Tang) Date: Thu, 15 Jun 1995 15:19:48 -0500 (CDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9506151958.AA11505@life.ai.mit.edu> from "Johnny Tang" at Jun 15, 95 03:58:04 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO > How can I turn off the log message for cvs checkout ? > > The cvs inserts the log message in > the c++ file incorrectly: Either remove the $Log:$ rcs keyword from the file or try cvs admin -c'// ' foo.C to change the comment prefix. Jim From info-cvs-request@prep.ai.mit.edu Thu Jun 15 16:26:56 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA08642 for ; Thu, 15 Jun 1995 16:26:50 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27232; Thu, 15 Jun 95 13:22:24 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA14840; Thu, 15 Jun 1995 15:22:13 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27335; Thu, 15 Jun 1995 14:18:03 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27331; Thu, 15 Jun 1995 14:18:01 -0600 Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA14541; Thu, 15 Jun 1995 15:17:57 -0500 Received: from life.ai.mit.edu by venus.Sun.COM (Sun.COM) id NAA28803; Thu, 15 Jun 1995 13:17:50 -0700 Received: from gandalf.llnl.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12319; Thu, 15 Jun 95 16:15:11 EDT Received: by gandalf.llnl.gov (4.1/LLNL-1.18) id AA20446; Thu, 15 Jun 95 13:13:24 PDT Date: Thu, 15 Jun 95 13:13:24 PDT From: jac@gandalf.llnl.gov (James Crotinger) Message-Id: <9506152013.AA20446@gandalf.llnl.gov> To: Johnny Tang Cc: info-cvs@prep.ai.mit.edu Subject: log message for C++ code In-Reply-To: <9506151958.AA11505@life.ai.mit.edu> References: <9506151958.AA11505@life.ai.mit.edu> Status: RO Johnny Tang writes: > How can I turn off the log message for cvs checkout ? [..] > // Revision History: > // $Log: ns.l,v $ > * Revision 1.1.1.1 1995/06/01 22:23:40 epics > * Initial import of cdev source. > * > // Just remove the $Log:...$ line. Revision histories can be a pain to merge, so this is probably a good idea anyway. All the information is available with the cvs log command. If you really want to keep them, you can change the comment leader using the cvs admin command: % cvs admin -c"// " ns.l There may be a way to get cvs to do the right thing for C++ files automatically, but I'm not aware of it. Jim From info-cvs-request@prep.ai.mit.edu Thu Jun 15 10:40:25 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA25990 for ; Thu, 15 Jun 1995 10:40:24 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA23936; Thu, 15 Jun 95 07:37:22 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA10006; Thu, 15 Jun 1995 09:37:15 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09025; Thu, 15 Jun 1995 08:29:22 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09021; Thu, 15 Jun 1995 08:29:21 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA09134; Thu, 15 Jun 1995 09:29:17 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id HAA06917; Thu, 15 Jun 1995 07:29:17 -0700 From: jim@pfm-tun-wells.ccmail.compuserve.com Received: from dub-img-2.compuserve.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA22073; Thu, 15 Jun 95 10:29:14 EDT Received: by dub-img-2.compuserve.com (8.6.10/5.950515) id KAA29341; Thu, 15 Jun 1995 10:29:14 -0400 Date: 15 Jun 95 10:24:49 EDT To: Subject: Re: cvs for dos? Message-Id: <950615142448_702420.204300_BHD39-24@CompuServe.COM> Status: RO >Is there a cvs for dos? There appears to be, we're using an OS/2 port of CVS 1.4 which also comes with a dos port, I haven't tried the dos port so I can't vouch for its integrity. >From one of the readme files: --- Quote --- The complete source will be available from ftp.rrzn.uni-hannover.de as long as Lutz keeps making space available. It will be in both /pub/msdos-local and /pub/os2-local. I also upload to ftp-os2.cdrom.com, but rrzn might be more up to date on occasion. --- End --- There's a dos port of RCS as well (from another readme): --- Quote --- This package is primarily distributed as ftp.informatik.tu-muenchen.de:/pub/comp/os/os2/gnu/devtools/rcs567pc.z ip As long as the author of this revision maintains the OS/2 and MS-DOS versions of RCS and has access to this archive site, the latest version can be found there (with file names indicating higher revisions, perhaps). --- End --- Good Luck! Jim Hughes Work: jim@pfm-tun-wells.cccmail.compuserve.com Play: jimh@cix.compulink.co.uk From info-cvs-request@prep.ai.mit.edu Tue May 23 20:15:47 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA11429 for ; Tue, 23 May 1995 20:15:46 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18462; Tue, 23 May 95 17:01:13 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.0/SMI-5.3) id AA15955; Tue, 23 May 1995 19:01:00 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19602; Tue, 23 May 1995 17:51:23 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19594; Tue, 23 May 1995 17:51:21 -0600 Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (5.0/SMI-5.3) id AA14704; Tue, 23 May 1995 18:51:19 -0500 Received: from life.ai.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA16827; Tue, 23 May 95 16:51:17 PDT Received: from dkuug.dk by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13139; Tue, 23 May 95 19:51:11 EDT Received: from mailer.uucp by dkuug.dk with UUCP id AA18730 (5.65c8/IDA-1.4.4j for info-cvs@prep.ai.mit.edu); Tue, 23 May 1995 11:59:56 +0200 Received: from smtplink.ne.dk by mailer.ne.dk (5.65/DKnet2.0.6) with SMTP id AA09196; Tue, 23 May 95 09:34:59 +0200 Received: from ccMail by smtplink.ne.dk id AA801246503 Tue, 23 May 95 09:28:23 dst Date: Tue, 23 May 95 09:28:23 dst From: "tsc" Encoding: 1095 Text Message-Id: <9504238012.AA801246503@smtplink.ne.dk> To: info-cvs@prep.ai.mit.edu Subject: Q: CVS on top of PVCS? X-Charset: ASCII X-Char-Esc: 29 Content-Length: 1071 Status: RO Hi guys Being part of a company using PVCS (a commercial a'la RCS system from Intersolv Inc.) for revision control, I would *still* like to use all the wonderfull features of CVS, which I know & love. Looking at PVCS, it looks like an almost exact clone of RCS, with a *very* few omissions/enhancements. SO: has anyone out there ported CVS to work on top of PVCS instead of RCS? :-) Thomas Schaumburg NKT Elektronik A/S (a.k.a DSC Denmark) Telecom Systems R&D PS: One way of doing this would be to write a little C program "emulating" each RCS command using the corresponding PVCS executable - in general only a translation of switches is needed. I've already done this on an experimental basis. The only problem is that CVS at some point parses the raw RCS file - and PVCS uses a completely different format. From info-cvs-request@prep.ai.mit.edu Wed Jun 21 04:36:30 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA19486 for ; Wed, 21 Jun 1995 04:36:22 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21288; Wed, 21 Jun 95 01:22:36 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA07346; Wed, 21 Jun 1995 03:22:29 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24059; Wed, 21 Jun 1995 02:16:04 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24055; Wed, 21 Jun 1995 02:16:03 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA06548; Wed, 21 Jun 1995 03:15:55 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id BAA02177; Wed, 21 Jun 1995 01:15:54 -0700 Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA24374; Wed, 21 Jun 95 04:15:47 EDT Received: from now by mail.uunet.ca with UUCP id <176906-4>; Wed, 21 Jun 1995 04:17:40 -0400 From: Eric Siegerman To: info-cvs@prep.ai.mit.edu Date: Wed, 21 Jun 1995 04:08:51 -0400 Message-Id: <950621040851.13676@now.com> Subject: Some details on ODE (was Re: make and automatic retrieval from cvs) Status: RO Chris Dean writes: > mturok@bfm.com writes: > > each user doesn't have a complete copy of all of the code; he/she only > > checks out the code he/she is working on. The rest is linked in from > > the production area. > [...] > What we ended up doing was having the main branch with all of the code > checked out in some public area (/source/pcs) that was updated N times > a day. Every developer had local copies of the directories they were > working on and used /source/pcs (via the vpath feature of GNU Make) > for the directories they didn't need. Paul Eggert pointed out a couple of weeks ago that ODE, the OSF Development Environment, is now freeware. From my cursory inspection, it looks as though ODE handles this kind of situation quite well. I read the tutorials, and decided that ODE is serious overkill for my needs, so I'll be sticking with CVS for the foreseeable future. But some people may find ODE of interest -- and some of its ideas may be worth ripping off^H^H^H^H^H^H^H^H^H^H^Hborrowing for CVS -- so I'll try to summarize what I remember of it. You start with a full checked-out development tree (their term is "backing build"). This contains sources, headers, and also generated files -- objects, libraries, etc. But the backing build isn't used as a sandbox by any individual; it's maintained strictly by ODE. Each user's sandbox contains only those files that the user has actually changed; ODE's Make uses a VPATH-like scheme to find the right version of each source file (and, I think, of each library or executable as well), reading the file from the backing build unless there's a version in the user's sandbox to override it. Once a user has submitted their changes to a given file (and resolved conflicts if necessary), the new version is placed into the backing build, and the file is deleted from the sandbox. So sandboxes, presumably, tend to stay fairly small, since they get pruned with every submit. ODE draws a distinction between checking a file in and making the new version available to others, as opposed to RCS and CVS, where "checking in" or "committing" does both things at once. With ODE, you can check as many revisions as you want into the revision-control system, but they're still private; only you can see them. It's only when you "submit" your changes, a separate step, that they become visible outside your own sandbox. You can get the same effect in CVS by creating a branch when you're about to start into a round of changes, but you don't always know at the outset whether the project will be big enough to require a branch (or whether, part-way through a 3-hour project, an emergency will tear you away from it for days). The alternative, always starting a branch as a matter of course (which is closer to ODE's approach), just litters the repository with zillions of useless branch tags, all of which require unique names, all of which have to be consciously merged-and-forgotten at some point, and most of which never confer any benefit. ODE basically turns it backward: instead of publishing changes by default and forcing the user to take action (starting a branch) when publication should be deferred for a few revisions, it keeps changes private by default and forces the user to take action (submitting) when the work is ready to be published. I'm not sure what ODE does with any private, intermediate revisions once you submit the end results. But I infer that a submit automatically terminates the private branch-in-development, so that humans don't have to keep track of which branches are still active. Of course, it would often immediately start a new branch... This sounds to me like a minor, but useful, improvement over the CVS model, akin to anonymous code in some languages (eg. Postscript) and the "|" shell syntax for chaining commands. In none of these cases does the improvement get you any new functionality (yeah, I know, in Unix, "|" is done with pipes, but that's almost beside the point. MS-DOS does it with temp-files and one rarely notices the difference). But there's less bookkeeping involved: fewer names that people have to come up with and worry about uniqueness of, and fewer things to be disposed of (temp-files, active branches) when -- but not before -- they're no longer required. ODE lets you have a chain of several sandboxes between your private work area and the backing build. Consider a project which consists of a number of teams. Each team member has their own private sandbox; changes are merged into the team's sandbox, so other team members can see them but the rest of the project can't; later, after module testing, the team's changes are submitted one step higher to the backing build -- it's only then that they become visible to people outside the team. You can also "retarget" your sandbox to a different backing build, changing where ODE looks for files you don't have private copies of. You'd use this if you were developing for multiple systems, and wanted to test your changes on all of the platforms before submitting them. I didn't read the details, but it's probably along the lines of: NFS-mount your sandbox from a test machine; retarget your sandbox to the backing build for that platform; make clean; make. Oh, and the thing's client-server, too. The down-side? As far as I can tell, ODE takes more administration than CVS. For example, I seem to remember that it's rather more annoying to create a new sandbox than a simple "cvs co foo". But take this with a grain of salt -- I've never used ODE. For that matter, I've never even used CVS in a large, many-developer project, so I don't know how much administration that takes. What sandbox-creation taketh away, branch-accounting may giveth back :-) Also, ODE doesn't seem to have gotten away from the idea of locking files. Like raw RCS (which ODE also uses for its low-level revision storage), you must check out files either "for update" or "read-only" -- and, also like RCS, it sets the working-file's permissions accordingly. I may be wrong here, in that checking out for update may not actually prevent others from doing the same, but even so, the fact that there is a distinction is annoying, whatever they do with it. And I didn't see mention of anything resembling a vendor branch. I thought at first that one could get the same effect with some appropriate tree of sandboxes feeding into the backing build, but on second thought I'm not so sure. Finally, I'm not sure how portable ODE is. Their FTP site has binaries for a number of systems, but after all, the thing was written to keep track of OSF/1 sources, so they may not have bothered too much making it portable to non-OSF/1-like systems. There is certainly at least one major host-platform assumption built in: ODE *requires* symlinks. Not too much of a problem these days, but it means I couldn't use it on Xenix at work, even if it did meet our needs. (It makes rather clever use of symlinks, actually. The chain of sandboxes I mentioned is actually implemented as a symlinked-list; each sandbox's root directory contains a symlink called "link" pointing to the next sandbox up the chain (of course, the directory at the end of the chain is the backing build, not a sandbox). It probably also requires TCP/IP -- I think it always runs in client/server mode, it just looks for the servers on localhost if you don't want to network it. Again, no trouble for most, but probably a killer for a few. Here are Paul's instructions for how to get it: > You can FTP ODE from riftp.osf.org; here are some references to help > you get started. > > FTP instructions > prebuilt documentation > ODE 2.3.4 source > ODE 2.3.4A source additions > > 2.3.4A contains optional enhancements to ODE 2.3.4 by OSF RI. To which I'd only add: just fetch the Users Guide to start with. It's 48 pages, which will quickly give you a good idea whether you want to explore further (and even if you know you do, you want to read the Users Guide before the delving into the Sys-Admin Guide anyway). I should say, the main document is 48 pages. Appendix A, which they split off into a separate file, is about 3 times that; it consists of the man pages for all the commands. This longwinded blurb for a competitor isn't meant to put down CVS. On the contrary, I've looked at ODE, and despite very much liking some things about it (especially the split between "check in" and "submit"), I've decided that CVS suits my needs better. But my needs aren't everyone's; there may be some here who will find that ODE's strengths outweigh CVS's for what they're doing. I hope this helps at least one person, after all this typing :-) -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont. erics@now.com | | / This fiendish string devised by my student Annie Senghas is a grammatical English sentence: Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo. - Steven Pinker, _The Language Instinct_ From info-cvs-request@prep.ai.mit.edu Wed Jun 21 16:51:40 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA12985 for ; Wed, 21 Jun 1995 16:51:28 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA17016; Wed, 21 Jun 95 13:37:54 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA21329; Wed, 21 Jun 1995 15:37:44 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28773; Wed, 21 Jun 1995 14:34:22 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28766; Wed, 21 Jun 1995 14:34:19 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA20734; Wed, 21 Jun 1995 15:34:11 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA14956; Wed, 21 Jun 1995 13:34:07 -0700 From: fouts@bozeman.hpl.hp.com Received: from hplms26.hpl.hp.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA29977; Wed, 21 Jun 95 16:34:02 EDT Received: from bozeman.hpl.hp.com by hplms26.hpl.hp.com with SMTP ($Revision: 1.36.108.11 $/15.5+ECS 3.3+HPL1.1S) id AA118836850; Wed, 21 Jun 1995 13:34:10 -0700 Received: by bozeman.hpl.hp.com (1.37.109.8/15.5+ECS 3.3+HPL1.1) id AA11550; Wed, 21 Jun 1995 13:37:55 -0700 Date: Wed, 21 Jun 1995 13:37:55 -0700 Message-Id: <9506212037.AA11550@bozeman.hpl.hp.com> To: info-cvs@prep.ai.mit.edu In-Reply-To: <950621040851.13676@now.com> (message from Eric Siegerman on Wed, 21 Jun 1995 04:08:51 -0400) Subject: ODE downside (was Re: Some details on ODE...) Reply-To: Martin Fouts Comments: Hyperbole mail buttons accepted, v3.18. Status: RO Besides not being freeware, ODE has some other downsides that I'd like to highlight. I have used ODE in another life, while doing vendor ports of OSF to other platforms. Some of my recollections include: 1) The development environment required to support ODE is extensive. I'm not sure how much of this is OSF/CMU and how much of it is ODE, but make is not the only utility that requires a VPATH variable. I was *amazed* at the number of tools that needed to be ported before we could do cross development. 2) ODE requires considerable administration. Large complex tools require signficant intellectual investment and maintainance overhead. ODE is such a tool. We felt it was necessary to devote a FTE (full time equivalent) to maintaing our repository/sandbox collection 3) ODE is very much specialized for the environment that OSF thought would surround OSF-1 development: A major provider pushing source to platform-porters who pushed bug fixes back in a way that allowed the bug fixes to be decoupled from the tree but tracked for potential use in future releases. It actually has significant weaknesses for that approach, relying heavily on vendor discipline for the "hard" parts and is dramatic overkill for other sorts of development. In particular, it has no real provision for the sort of parallel development with synchronization model that CVS is good at. marty From info-cvs-request@prep.ai.mit.edu Wed Jun 21 20:03:10 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA11322 for ; Wed, 21 Jun 1995 20:03:09 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA10814; Wed, 21 Jun 95 16:52:43 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA16322; Wed, 21 Jun 1995 18:52:35 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06567; Wed, 21 Jun 1995 17:47:57 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06562; Wed, 21 Jun 1995 17:47:56 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA15941; Wed, 21 Jun 1995 18:47:50 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id QAA13082; Wed, 21 Jun 1995 16:47:41 -0700 Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA16608; Wed, 21 Jun 95 19:47:37 EDT Received: from now by mail.uunet.ca with UUCP id <177826-4>; Wed, 21 Jun 1995 19:49:28 -0400 From: Eric Siegerman To: info-cvs@prep.ai.mit.edu Date: Wed, 21 Jun 1995 19:42:03 -0400 Message-Id: <950621194204.18515@now.com> Subject: re: ODE downside Status: RO First, let me clear up a misunderstanding. Martin Fouts wrote: > Besides not being freeware, This appears to have been true in the past, but to have changed (I don't know just when). The copyright notice from a randomly picked source file (bco.c -- the "co" substring means what you think it does) says in full: /* * COPYRIGHT NOTICE * Copyright (c) 1992, 1991, 1990 * Open Software Foundation, Inc. * * Permission is hereby granted to use, copy, modify and freely distribute * the software in this file and its documentation for any purpose without * fee, provided that the above copyright notice appears in all copies and * that both the copyright notice and this permission notice appear in * supporting documentation. Further, provided that the name of Open * Software Foundation, Inc. ("OSF") not be used in advertising or * publicity pertaining to distribution of the software without prior * written permission from OSF. OSF makes no representations about the * suitability of this software for any purpose. It is provided "as is" * without express or implied warranty. */ One of the readme files contains some history. It seems that the OSF has been bundling ODE with all of their source-code products, presumably (as Martin says later) to control feedback of bug fixes. And some of their source licensees have started using ODE for other stuff. But, more to the point: > As part of its technology transfer mission, > the [OSF] Research Institute makes available free > and unencumbered releases of its Mach microkernel and other technologies. > (For instance, ODE 2.3.4 is the build environment for the recently > announced free and unencumbered mk6.1 microkernel). Hence, the RI is > also making ODE available separately as a free and unencumbered release. In other words, they use ODE to maintain MK, so they want to receive MK bug-fixes in a form compatible with ODE; MK is Free Software(TM); hence they had (or felt they had) no choice but to free up ODE as well. Enough about whether you can use it. Back to the more interesting topic: whether you want to. Martin again: > 1) The development environment required to support ODE is extensive. Hmm, I hadn't even thought of this. It sounds like a major drawback. > I'm not sure how much of this is OSF/CMU and how much of it is > ODE, but make is not the only utility that requires a VPATH > variable. I was *amazed* at the number of tools that needed to > be ported before we could do cross development. Is this a matter of adding VPATH functionality to existing programs, or of importing OSF-specific tools that other Unices don't have at all? Or are you referring to standard Unix tools (Yacc, Lex, etc.) that you had to port to non-Unix environments? > 2) ODE requires considerable administration ... > We felt it was necessary to > devote a FTE (full time equivalent) to maintaing our > repository/sandbox collection Which is basically what scared me off. I mostly use CVS for dealing with stuff I get off the Net (using CVS to administer its own sources has been most interesting); I'm not about to commit to a system that makes me spend hours per week just to administer GNU sources. Once a project reaches a certain size, however, I hear (having never myself worked on such a large project) that it needs a dedicated source-administrator / build-coordinator / change-merger anyway; I gather that some of the people on this list are employed in just such a capacity. In that case, the fact that the software tools demand such a role is no longer a liability -- indeed, it may be an asset in that it forces the managers to dedicate resources to a function they might otherwise try to weasel out of paying for (since they don't see why the programmers can't do it themselves). But until a project has reached such a size, forcing a source administrator on it is just a waste of money that could be better spent elsewhere (eg. having that person write code). This brings up an interesting side-question: how big *can* a project get and still have source and build control, etc. done ad hoc by the programmers? > 3) ODE is very much specialized for the environment that OSF thought > would surround OSF-1 development: A major provider pushing > source to platform-porters who pushed bug fixes back > ... > It actually has significant > weaknesses for that approach, relying heavily on vendor discipline > for the "hard" parts So much for using it on programs that aren't ODE-controlled by the vendor in the first place (ie. just about everything FTPable) -- in such a case, there is by definition no vendor discpline, in the narrow sense ODE presumably requires. > In particular, it has no real provision for the sort > of parallel development with synchronization model that CVS is good > at. Is this limited to the checkout "for changes" or "read-only" that I mentioned? What use *do* they make of that distinction, anyway? Or is there more to it than that? The Users Guide did talk about merging, but wasn't clear on how you know when a merge is necessary. In fact, it was rather short on giving one a feel for the actual steps a programmer goes through to make a change in an ODE-administered program (and, again since I've already rejected the thing, I haven't read enough of the manual pages to answer such questions). (I guess it's kind of odd to be saying such good things about a system I've decided not to use; I guess I have to just fall back on Mr. Whitman: "I contain multitudes"). > I have used ODE in another life, while doing vendor > ports of OSF to other platforms. Experience is always better than supposition. Thanks much. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont. erics@now.com | | / This fiendish string devised by my student Annie Senghas is a grammatical English sentence: Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo. - Steven Pinker, _The Language Instinct_ From info-cvs-request@prep.ai.mit.edu Sat Jun 17 16:42:00 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA14510 for ; Sat, 17 Jun 1995 16:41:59 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29737; Sat, 17 Jun 95 13:21:47 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA20271; Sat, 17 Jun 1995 15:21:41 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00295; Sat, 17 Jun 1995 14:13:39 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00291; Sat, 17 Jun 1995 14:13:38 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA19228; Sat, 17 Jun 1995 15:13:35 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA24112; Sat, 17 Jun 1995 13:13:34 -0700 From: Goodsen_John-SC371C@email.mot.com Received: from motgate.mot.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA19590; Sat, 17 Jun 95 16:13:31 EDT Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.6.11/8.6.10/MOT-3.7) with ESMTP id PAA20954 for ; Sat, 17 Jun 1995 15:13:05 -0500 Received: from ilbx.mot.com (ilbx.mot.com [129.188.137.185]) by pobox.mot.com (8.6.11/8.6.10/MOT-3.7) with SMTP id PAA23055 for ; Sat, 17 Jun 1995 15:13:05 -0500 Received: by ilbx.mot.com (1.37.109.4/16.2) id AA15722; Sat, 17 Jun 95 15:13:05 -0500 Received: by email.mot.com via Worldtalk with X400 (2.3.0/1.38.1.3) id WT13333.1; Sat, 17 Jun 1995 15:13:04 CDT Date: 17 Jun 95 13:11:00 -0500 To: info-cvs@prep.ai.mit.edu Subject: CVS 1.4A2 is blowing away files and repositories Message-Id: Status: RO Hello, We've recently installed CVS1.4A2 on Solaris 2.4 and are having some serious problems: 1. A merge (using diff3) failed and left us with a zero length file ;-( 2. I just did a cvs checkout of the entire repository and cvs core dumped in the middle of the checkout. Worse, my $CVSROOT tree (the entire repository) is no where to be found on disk! ;-( Before we moved to the 1.4A2 version on Solaris 2.4, we were successfully using cvs 1.3 on Solaris 2.3 What is going on here !??!?!?? $#*R^(&$(&^& thanks for any help -- John Goodsen Currently On-Site: Rapid Engineering Specialist Motorola Satellite Communications The Dalmatian Group, Inc. Chandler, AZ jgoodsen@dalmatian.com Today's Weather: Getting Hotter ;-) http://www.indirect.com/www/radsoft/jgoodsen.html From info-cvs-request@prep.ai.mit.edu Sun Jun 18 15:19:14 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA01946 for ; Sun, 18 Jun 1995 15:19:08 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA17582; Sun, 18 Jun 95 12:06:49 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA19299; Sun, 18 Jun 1995 14:06:44 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27272; Sun, 18 Jun 1995 12:52:01 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27268; Sun, 18 Jun 1995 12:52:00 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA19092; Sun, 18 Jun 1995 13:51:57 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id LAA29773; Sun, 18 Jun 1995 11:51:54 -0700 Received: from telerobotics.jpl.nasa.gov by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AB00786; Sun, 18 Jun 95 14:51:38 EDT Received: from jefferson.telerobnet (jefferson.jpl.nasa.gov [128.149.53.66]) by telerobotics.jpl.nasa.gov (8.6.10/8.6.6) with SMTP id LAA19754; Sun, 18 Jun 1995 11:51:26 -0700 Received: from loghost by jefferson.telerobnet (4.1/SMI-4.1) id AA05680; Sun, 18 Jun 95 11:51:22 PDT Message-Id: <9506181851.AA05680@jefferson.telerobnet> To: mturok@bfm.com Cc: info-cvs@prep.ai.mit.edu Subject: Re: make and automatic retrieval from cvs In-Reply-To: Your message of "Fri, 16 Jun 1995 15:49:01 EDT." <9506161949.AA18609@dev9.dev0> Date: Sun, 18 Jun 1995 11:51:21 -0700 From: Chris Dean Status: RO mturok@bfm.com writes: > However, some people here > believe you should automatically check out new copies of code from > SCCS when you compile. We are currently contemplating changing from > sccs->cvs, and I wanted to try to maintain that functionality. > > This is supported using SCCS and Sun's make through the .SCCS_GET > target. Under cvs, there doesn't seem to be a clear way to do it I had this problem too when converting to cvs 1.3 from RCS. Some of the other developers felt that our code changed so dramatically that they could not afford to have one compile without the latest code. > I think the problem comes in when you have a large, multi-library > system, with separate work areas for each individual user. However, > each user doesn't have a complete copy of all of the code; he/she only > checks out the code he/she is working on. The rest is linked in from > the production area. One problem we had is that our code base was too large and lived in too many directories to allow every developer to have a full copy of the source tree. We also needed a tree of the main branch of the working code base available for people (like Support & QA) to examine. What we ended up doing was having the main branch with all of the code checked out in some public area (/source/pcs) that was updated N times a day. Every developer had local copies of the directories they were working on and used /source/pcs (via the vpath feature of GNU Make) for the directories they didn't need. We agreed that after a few weeks of working this way that we could change the build procedure to add a cvs update (no recursion) target to 'all:' if people wanted it. We updated /source/pcs 4 times during working hours and once at 1:00 am. We also had two mailing lists; the first sent mail once a day, and the second sent mail at every cvs commit. Every one was very happy with this arrangement, we never added the cvs update target, and we reduced out updates of /source/pcs to noon and midnight only. Chris Dean From info-cvs-request@prep.ai.mit.edu Mon Jun 19 00:32:56 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id AAA24276 for ; Mon, 19 Jun 1995 00:32:55 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA26615; Sun, 18 Jun 95 21:21:57 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA24692; Sun, 18 Jun 1995 23:21:52 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09899; Sun, 18 Jun 1995 22:06:27 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09895; Sun, 18 Jun 1995 22:06:26 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA24281; Sun, 18 Jun 1995 23:06:24 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id VAA17286; Sun, 18 Jun 1995 21:06:18 -0700 Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA24768; Mon, 19 Jun 95 00:06:06 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA20994; Mon, 19 Jun 1995 00:05:58 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA26634; Mon, 19 Jun 95 00:05:56 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id AAA24906; Mon, 19 Jun 1995 00:05:55 -0400 Date: Mon, 19 Jun 1995 00:05:55 -0400 Message-Id: <199506190405.AAA24906@kayak.odi.com> To: mturok@bfm.com Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9506161949.AA18609@dev9.dev0> (mturok@bfm.com) Subject: Re: make and automatic retrieval from cvs Reply-To: dgg@odi.com Status: RO > I think the same way you two do -- I don't want anyone else's changes > impacting me until I am ready for them. However, some people here > believe you should automatically check out new copies of code from > SCCS when you compile. What I would do under CVS is to build in a tree that was all checked out. You check it out from a particular "STABLE" tag that moves forward as code is tested. Normal developers should just run "make" and "cvs update" on the files they placed on purpose into their working directories. They should not be auto-extracting anything. Master builders (I used to call my position "Build Meister") should build from sets of marked revisions. From info-cvs-request@prep.ai.mit.edu Thu Jun 29 16:09:18 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA05099 for ; Thu, 29 Jun 1995 16:09:15 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28605; Thu, 29 Jun 95 13:03:07 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA07040; Thu, 29 Jun 1995 15:02:59 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18615; Thu, 29 Jun 1995 13:57:52 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA18610; Thu, 29 Jun 1995 13:57:51 -0600 Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA06611; Thu, 29 Jun 1995 14:57:43 -0500 Received: from life.ai.mit.edu by venus.Sun.COM (Sun.COM) id MAA26777; Thu, 29 Jun 1995 12:57:35 -0700 Received: from ns-mx.uiowa.edu by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA10229; Thu, 29 Jun 95 15:55:55 EDT Received: from ender.iaf.uiowa.edu by ns-mx.uiowa.edu (8.6.10/19950309.1) on Thu, 29 Jun 1995 14:54:02 -0500 id OAA72034 with ESMTP Received: by ender.iaf.uiowa.edu (940816.SGI.8.6.9/940406.SGI) id OAA21708; Thu, 29 Jun 1995 14:51:55 -0500 Date: Thu, 29 Jun 1995 14:30:08 -0500 (CDT) From: speakman Subject: problems with import time To: info-cvs@prep.ai.mit.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO just imported some code to start a new branch, the date (in *,v) shows some 5 hours in the future. now we can't check in anything (until 5 hours into the future) When we try to commit, there is a commit error from 'ci' complaining the revision to be committed is of an older date than the initial revision(imported revision, which is ofcourse dated 5 hours into the future). So what is a solution to this problem , other than waiting for 5 hours. Thanks for all the help, speak From info-cvs-request@prep.ai.mit.edu Tue Jun 27 11:12:01 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA01394 for ; Tue, 27 Jun 1995 11:11:48 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA17982; Tue, 27 Jun 95 08:01:26 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA03287; Tue, 27 Jun 1995 10:01:18 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13755; Tue, 27 Jun 1995 08:53:07 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13751; Tue, 27 Jun 1995 08:53:06 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA02758; Tue, 27 Jun 1995 09:53:03 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id HAA18825; Tue, 27 Jun 1995 07:53:02 -0700 Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12044; Tue, 27 Jun 95 10:52:56 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Tue, 27 Jun 95 10:52 EDT Message-Id: Date: Tue, 27 Jun 95 10:52 EDT From: woods@most.weird.com (Greg A. Woods) To: dtayl@rotiprata.nii.ncb.gov.sg (root) Cc: info-cvs@prep.ai.mit.edu Subject: Re: Removing obsolete directories? In-Reply-To: dtayl@rotiprata.nii.ncb.gov.sg's message of "Tue, June 27, 1995 16:04:35 +0800" regarding "Removing obsolete directories?" id <9506270804.AA11132@bakchang.nii.ncb.gov.sg> References: <9506270804.AA11132@bakchang.nii.ncb.gov.sg> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Status: RO [ On Tue, June 27, 1995 at 16:04:35 (+0800), dtayl@rotiprata.nii.ncb.gov.sg wrote: ] > Subject: Removing obsolete directories? > > But if I remove the directory in the Repository, the histories of the > obsoleted files (in the Attic) go with it, killing the possibility of > resurrection. That's what confuses me: > why would I execute 'cvs remove', which saves histories of obsolete > files in the Attic, and then go and delete those histories?? You are indeed being led astray by the FAQ -- it's just answering your question with a truthful answer, but not a useful one I think. What you can currently do with CVS is use "cvs {co,update} -P" to prune empty directories -- i.e. if a directory in the repository is empty of all objects except the "Attic" directory, it will not be created in the working directory, thus effectively removed. What the full proposed Per-Directory_DataBase, and a simpler version I've proposed, permit is for a directory to be actively removed (and also tagged), just like any other file. In my proposal I suggest simply moving the directory object (a history file named "CVS,v") into the Attic to mark the directory as deleted. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Tue Jun 27 11:01:51 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA17589 for ; Tue, 27 Jun 1995 11:01:49 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA16608; Tue, 27 Jun 95 07:46:21 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA02394; Tue, 27 Jun 1995 09:46:11 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13251; Tue, 27 Jun 1995 08:43:59 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13247; Tue, 27 Jun 1995 08:43:58 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA02252; Tue, 27 Jun 1995 09:43:51 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id HAA17641; Tue, 27 Jun 1995 07:43:45 -0700 Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA11029; Tue, 27 Jun 95 10:43:21 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA21762; Tue, 27 Jun 1995 10:43:11 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA05619; Tue, 27 Jun 95 10:43:09 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id KAA28252; Tue, 27 Jun 1995 10:43:09 -0400 Date: Tue, 27 Jun 1995 10:43:09 -0400 Message-Id: <199506271443.KAA28252@kayak.odi.com> To: dtayl@rotiprata.nii.ncb.gov.sg Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9506270804.AA11132@bakchang.nii.ncb.gov.sg> (dtayl@rotiprata.nii.ncb.gov.sg) Subject: Re: Removing obsolete directories? Reply-To: dgg@odi.com Status: RO > I went looking in the FAQ for a simple answer to what I thought was a > simple problem, but I'm getting more confused. > > I have a directory with two subdirectories. The subdirectories are no > longer built, but were part of previous releases. Now the new > maintainer of this code finds it confusing to see these obsolete > directories when he checks out the component. > > So I used 'cvs remove' and committed the files in those subdirectories. > But now when the component is checked out, the empty subdirectories > appear. This is still confusing. So how do I get rid of the > subdirectories? The FAQ has this to say: > > 3L.2 Why doesn't "remove" work on directories when it appears to try? > > Oversight. It should be able to delete an empty directory, but > you still don't have a way to remember when it was there and when > it disappeared to allow the "-D " option to work. > > You'll have to remove the working directory and the matching > directory in the Repository. > > But if I remove the directory in the Repository, the histories of the > obsoleted files (in the Attic) go with it, killing the possibility of > resurrection. That's what confuses me: > why would I execute 'cvs remove', which saves histories of obsolete > files in the Attic, and then go and delete those histories?? > > I'm sure i'm missing something obvious. Any help? You simply can't do what you want to do. What you are missing is that what you are trying to do is not handled correctly by CVS. You are also missing the point the FAQ is (clumsily) trying to make: "remove" doesn't even work for files (it doesn't store enough state to fully handle -D). From info-cvs-request@prep.ai.mit.edu Fri Jun 30 09:42:50 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA02243 for ; Fri, 30 Jun 1995 09:42:46 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA01925; Thu, 29 Jun 95 22:16:24 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA23664; Fri, 30 Jun 1995 00:16:18 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA07459; Thu, 29 Jun 1995 23:02:54 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA07454; Thu, 29 Jun 1995 23:02:53 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA23299; Fri, 30 Jun 1995 00:02:50 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id WAA15695; Thu, 29 Jun 1995 22:02:45 -0700 Received: from nii.ncb.gov.sg ([160.96.6.237]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13416; Fri, 30 Jun 95 01:02:28 EDT Received: from bakchang.nii.ncb.gov.sg by nii.ncb.gov.sg (4.1/SMI-4.1) id AA22627; Fri, 30 Jun 95 13:06:34 SST From: dtayl@rotiprata.nii.ncb.gov.sg (David Taylor) Received: by bakchang.nii.ncb.gov.sg; (5.65/1.1.8.2/17Sep94-0851AM) id AA15930; Fri, 30 Jun 1995 13:02:52 +0800 Message-Id: <9506300502.AA15930@bakchang.nii.ncb.gov.sg> Subject: Re: Removing obsolete directories? To: info-cvs@prep.ai.mit.edu Date: Fri, 30 Jun 1995 13:02:51 +0800 (GMT) In-Reply-To: from "Greg A. Woods" at Jun 27, 95 10:52:00 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Thanks to David Grubbs and Greg Woods for clearing up the problem of obsolete directories for me. As a footnote to that discussion, I should point out that in 1.4A2 "cvs {co,update} -P" unfortunately does not seem to work in the way suggested in the mail below. It prunes *any* empty directory, not just obsoleted directories. From the code in update.c, it appears the search for and removal of empty directories happens *after* they are created in the working directory. A directory is considered nonempty if it contains an entry other than '.', '..', or 'CVS'. Thus, with checkout -P the user will also see new and intentionally empty directories disappear, as well as obsolete ones. Oh well...looking forward to the PDDB! thanks, D.L.Taylor dtayl@nii.ncb.gov.sg from update.c: /* Prune empty dirs on the way out - if necessary */ (void) chdir (".."); if (update_prune_dirs && isemptydir (dir)) { run_setup ("%s -fr", RM); run_arg (dir); (void) run_exec (RUN_TTY, RUN_TTY, RUN_TTY, RUN_NORMAL); } ... static int isemptydir (dir) char *dir; { DIR *dirp; struct dirent *dp; if ((dirp = opendir (dir)) == NULL) { error (0, 0, "cannot open directory %s for empty check", dir); return (0); } while ((dp = readdir (dirp)) != NULL) { if (strcmp (dp->d_name, ".") != 0 && strcmp (dp->d_name, "..") != 0 && strcmp (dp->d_name, CVSADM) != 0 && strcmp (dp->d_name, OCVSADM) != 0) { (void) closedir (dirp); return (0); } } (void) closedir (dirp); return (1); } Greg A. Woods wrote: > > [ On Tue, June 27, 1995 at 16:04:35 (+0800), dtayl@rotiprata.nii.ncb.gov.sg wrote: ] > > Subject: Removing obsolete directories? > > > > But if I remove the directory in the Repository, the histories of the > > obsoleted files (in the Attic) go with it, killing the possibility of > > resurrection. That's what confuses me: > > why would I execute 'cvs remove', which saves histories of obsolete > > files in the Attic, and then go and delete those histories?? > > You are indeed being led astray by the FAQ -- it's just answering your > question with a truthful answer, but not a useful one I think. > > What you can currently do with CVS is use "cvs {co,update} -P" to prune > empty directories -- i.e. if a directory in the repository is empty of > all objects except the "Attic" directory, it will not be created in the > working directory, thus effectively removed. > > What the full proposed Per-Directory_DataBase, and a simpler version > I've proposed, permit is for a directory to be actively removed (and > also tagged), just like any other file. In my proposal I suggest simply > moving the directory object (a history file named "CVS,v") into the > Attic to mark the directory as deleted. > > -- > Greg A. Woods > > +1 416 443-1734 VE3TCP robohack!woods > Planix, Inc. ; Secrets of the Weird > > From info-cvs-request@prep.ai.mit.edu Fri Jun 30 11:40:19 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA09196 for ; Fri, 30 Jun 1995 11:40:18 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24758; Fri, 30 Jun 95 06:16:33 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA00412; Fri, 30 Jun 1995 08:16:28 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19833; Fri, 30 Jun 1995 07:02:57 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19828; Fri, 30 Jun 1995 07:02:55 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA29797; Fri, 30 Jun 1995 08:02:51 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id GAA13239; Fri, 30 Jun 1995 06:02:43 -0700 Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA24551; Fri, 30 Jun 95 09:02:36 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Fri, 30 Jun 95 09:02 EDT Message-Id: Date: Fri, 30 Jun 95 09:02 EDT From: woods@most.weird.com (Greg A. Woods) To: dtayl@rotiprata.nii.ncb.gov.sg (David Taylor) Cc: info-cvs@prep.ai.mit.edu Subject: Re: Removing obsolete directories? In-Reply-To: David Taylor's message of "Fri, June 30, 1995 13:02:51 +0800" regarding "Re: Removing obsolete directories?" id <9506300502.AA15930@bakchang.nii.ncb.gov.sg> References: <9506300502.AA15930@bakchang.nii.ncb.gov.sg> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Fri, June 30, 1995 at 13:02:51 (+0800), David Taylor wrote: ] > Subject: Re: Removing obsolete directories? > > As a footnote to that discussion, I should point out that in 1.4A2 > "cvs {co,update} -P" unfortunately does not seem to work in the way > suggested in the mail below. It prunes *any* empty directory, not just > obsoleted directories. You're exactly right! Sorry I didn't point that out -- I was assuming the documentation was also clear and that you'd be able to figure it out from there. On the other hand, you figured it out from the source, so who needs (possibly wrong) documentation, eh? ;-) Anyway, there are several easy work-arounds that I've used before: - put a file in the "intentionally" empty directoryies, such as ".keep-me" - have the makefile (or other build script) one level up create empty directories at build time - don't use "-P" and just live with the old empty directory. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Fri Jun 30 12:49:05 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA13650 for ; Fri, 30 Jun 1995 12:49:02 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB10776; Fri, 30 Jun 95 09:45:05 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA11452; Fri, 30 Jun 1995 11:44:58 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00625; Fri, 30 Jun 1995 10:31:41 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00620; Fri, 30 Jun 1995 10:31:40 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA10574; Fri, 30 Jun 1995 11:31:36 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id JAA05025; Fri, 30 Jun 1995 09:31:35 -0700 Received: from gateway.sctc.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA06914; Fri, 30 Jun 95 12:31:31 EDT Received: from sccmailhost.sctc.com (sccmailhost.sctc.com [192.55.214.100]) by gateway.sctc.com (8.6.10/8.6.9) with SMTP id LAA15609 for ; Fri, 30 Jun 1995 11:34:21 -0500 Received: from sccmailhost.sctc.com by sccmailhost.sctc.com id 008990000; 30 Jun 95 12:30 CDT Received: from sctc.com by sccmailhost.sctc.com id 109000000; 30 Jun 95 12:30 CDT Received: from dagobah.sctc.com (dagobah.sctc.com [172.17.192.121]) by spirit.sctc.com (8.6.12/8.6.9) with ESMTP id LAA18349 for ; Fri, 30 Jun 1995 11:30:50 -0500 Received: (from koster@localhost) by dagobah.sctc.com (8.6.12/8.6.9) id LAA01109 for info-cvs@prep.ai.mit.edu; Fri, 30 Jun 1995 11:30:46 -0500 From: Kirby Koster Message-Id: <199506301630.LAA01109@dagobah.sctc.com> Subject: Permissions getting changed as result of cvs status. To: info-cvs@prep.ai.mit.edu Date: Fri, 30 Jun 1995 11:30:44 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO I'm curious why when doing a cvs status, the function No_Difference finds it necessary to change the mode of the file it's checking. The result is that the file has write permissions added and these are only removed if no difference is found and cvswrite is false. What I would like is for cvs to just leave the permissions alone since I have some cases where the files should be read only and some cases when they shouldn't. Anybody know why write permissions are added to the file? I'm probably missing the obvious. Thanks, Kirby Koster kkoster@sctc.com >From no_diff.c ============== [ Stuff deleted ...] run_setup ("%s%s -p -q -r%s %s", Rcsbin, RCS_CO, vers->vn_user ? vers->vn_user : "", options); run_arg (vers->srcfile->path); if ((retcode = run_exec (RUN_TTY, tmpnam (tmp), RUN_TTY, RUN_REALLY)) == 0) { if (!iswritable (file)) /* fix the modes as a side effect */ xchmod (file, 1); /* do the byte by byte compare */ if (xcmp (file, tmp) == 0) { if (cvswrite == FALSE) /* fix the modes as a side effect */ xchmod (file, 0); /* no difference was found, so fix the entries file */ ts = time_stamp (file); Register (entries, file, vers->vn_user ? vers->vn_user : vers->vn_rcs, ts, options, vers->tag, vers->date, (char *) 0); free (ts); /* update the entdata pointer in the vers_ts structure */ p = findnode (entries, file); vers->entdata = (Entnode *) p->data; ret = 0; } else ret = 1; /* files were really different */ } [ Stuff deleted ...] From info-cvs-request@prep.ai.mit.edu Mon Jul 3 14:08:18 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA25400 for ; Mon, 3 Jul 1995 14:08:13 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03044; Mon, 3 Jul 95 10:54:20 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA11843; Mon, 3 Jul 1995 12:54:13 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00455; Mon, 3 Jul 1995 11:41:45 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00450; Mon, 3 Jul 1995 11:41:44 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA11705; Mon, 3 Jul 1995 12:41:36 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id KAA00195; Mon, 3 Jul 1995 10:41:32 -0700 Received: from alcor.twinsun.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA05245; Mon, 3 Jul 95 13:41:18 EDT Received: from twinsun.com (twinsun.twinsun.com [192.54.239.2]) by alcor.twinsun.com (8.6.10/8.6.5) with SMTP id JAA04973; Mon, 3 Jul 1995 09:50:57 -0700 Received: from light.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA20397; Mon, 3 Jul 95 10:40:02 PDT Received: by light.twinsun.com (5.x/SMI-SVR4) id AA05268; Mon, 3 Jul 1995 10:39:46 -0700 Message-Id: <9507031739.AA05268@light.twinsun.com> From: Paul Eggert Date: 3 Jul 1995 10:39:46 -0700 To: knutson@austin.ibm.com Cc: dwig@markv.com, info-cvs@prep.ai.mit.edu In-Reply-To: <9507021945.AA62192@fliegen.austin.ibm.com> (knutson@austin.ibm.com) Subject: Re: Diff problems on RS6000 Status: RO From: knutson@austin.ibm.com (Jim Knutson) Date: Sun, 2 Jul 1995 14:45:39 -0500 (CDT) Even with gnu diff, the rcsmerge does strange things on occaision (like check out files with the rcs field seperator in place of the missing trailing newline). I believe that bug is fixed in RCS 5.7. Aside from files not ending in newline, traditional diff also chokes if it decides that the file is ``binary'', and I've seen this trash RCS files in old versions of RCS, which are less bulletproof against this particular misbehavior. Traditional diff is generally slower than GNU diff. I don't know of any technical reason to prefer traditional diff to GNU diff, other than the minor hassle of installing GNU diff on hosts where it is not already the default system diff. From info-cvs-request@prep.ai.mit.edu Mon Jul 3 09:07:38 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA14778 for ; Mon, 3 Jul 1995 09:07:37 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA24419; Sun, 2 Jul 95 13:10:32 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA28103; Sun, 2 Jul 1995 15:10:26 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06222; Sun, 2 Jul 1995 14:03:57 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06218; Sun, 2 Jul 1995 14:03:56 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA27985; Sun, 2 Jul 1995 15:03:53 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id NAA03388; Sun, 2 Jul 1995 13:03:52 -0700 Received: from internet.milkyway.com (milkyway.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA23980; Sun, 2 Jul 95 16:02:32 EDT Received: from jupiter.milkyway.com (jupiter.milkyway.com [192.168.77.9]) by internet with ESMTP (DuhMail/2.0) id UAA21260; Sun, 2 Jul 1995 20:03:53 GMT Received: from metis.milkyway.com (mcr@metis.milkyway.com [192.168.77.21]) by jupiter.milkyway.com (8.6.7/8.6.6) with ESMTP id QAA01975 for ; Sun, 2 Jul 1995 16:00:16 -0400 Received: by metis.milkyway.com (8.6.9/BSDI-Client) id QAA24547; Sun, 2 Jul 1995 16:00:15 -0400 To: info-cvs@prep.ai.mit.edu Path: not-for-mail From: mcr@milkyway.com (Michael Richardson) Newsgroups: milkyway.mail.info-cvs Subject: Re: Libraries, ranlib, and CVS Date: 2 Jul 1995 16:00:15 -0400 Organization: Milkyway Networks Corporation, Ottawa, ON Lines: 50 Distribution: milkyway Message-Id: <3t6tsf$nv1@metis.milkyway.com> References: <199506302238.PAA24937@vygr.NVidia.COM> Status: RO In article <199506302238.PAA24937@vygr.NVidia.COM>, Mike Ekberg wrote: >Has anyone solved the riddle of how to archive libraries >w/ CVS? > >I seem to be in a muddle where I check in the library, get it back out >w/ update, and then have to run "ranlib" on it, which changes the >file. It's now out of date. Each user who checks it out and >runs ranlib on it, gets it out of date also, although the >library is unchanged. Yes, I ran into this problem while keeping SunOS kernel stuff under CVS (arch/libprom.a). We do not have a source license, but do compile several custom .c files, and of course, the configuration files for the kernel are very important. We can "back out" of kernel patches too... In my Makefile at the top of the kernel tree: sun4m/BLACKHOLE/vmunix: sun4m/BLACKHOLE/Makefile ./retouch 100 sun4m/libprom.a cd sun4m/BLACKHOLE; make; sun4m/BLACKHOLE/Makefile: sun4m/conf/BLACKHOLE cd sun4m/conf; config BLACKHOLE sun4c/BLACKHOLE/vmunix: sun4c/BLACKHOLE/Makefile ./retouch 100 sun4c/libprom.a cd sun4c/BLACKHOLE; make; sun4c/BLACKHOLE/Makefile: sun4c/conf/BLACKHOLE cd sun4c/conf; config BLACKHOLE % cat retouch #!/usr/bin/perl # # Set timestamp of args 2nd-Last to that of the first arg. # $time=shift; utime($time,$time,@ARGV); % This makes ld happy. -- :!mcr!: | Milkyway Networks Corporation Michael Richardson | Makers of the Black Hole firewall NCF: aa714 || xx714 | +1 613 566-4574 ... mcr@milkyway.com Home: mcr@sandelman.ocunix.on.ca. PGP key available. From info-cvs-request@prep.ai.mit.edu Mon Jul 3 09:08:51 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA14811 for ; Mon, 3 Jul 1995 09:08:49 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA22160; Sun, 2 Jul 95 10:09:09 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA24033; Sun, 2 Jul 1995 12:09:02 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02894; Sun, 2 Jul 1995 10:57:46 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA02890; Sun, 2 Jul 1995 10:57:45 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA23295; Sun, 2 Jul 1995 11:57:32 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id JAA22972; Sun, 2 Jul 1995 09:57:32 -0700 Received: from harvey.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA17845; Sun, 2 Jul 95 12:57:29 EDT Received: (from kingdon@localhost) by harvey.cyclic.com (8.6.9/8.6.9) id MAA00233; Sun, 2 Jul 1995 12:56:51 -0400 Date: Sun, 2 Jul 1995 12:56:51 -0400 From: James Kingdon Message-Id: <199507021656.MAA00233@harvey.cyclic.com> To: Fred.Appelman@cv.ruu.nl Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <199507020757.JAA04391@wodan.cv.ruu.nl> (message from Fred Appelman on Sun, 2 Jul 1995 09:57:06 +0200 (METDST)) Subject: Re: Minor patch to install cvs.1.4.93 on Unixware-2.01 Status: RO > - On unixware 2.01 the symbols strlist can not be used. This because it is > a global function present in the file string.h > A rename to str_list is enough to fix the problem. Thanks for the report. Unfortunately, it is too late to get this change into 1.5, but I have checked it in for inclusion in subsequent releases. From info-cvs-request@prep.ai.mit.edu Mon Jul 3 09:21:07 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA15508 for ; Mon, 3 Jul 1995 09:21:06 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB03271; Sat, 1 Jul 95 16:01:15 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA14338; Sat, 1 Jul 1995 18:01:09 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09679; Sat, 1 Jul 1995 16:43:19 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA09674; Sat, 1 Jul 1995 16:43:18 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA13079; Sat, 1 Jul 1995 17:43:15 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id PAA02049; Sat, 1 Jul 1995 15:43:15 -0700 From: dwig@markv.com Received: from markv.com (hermix.markv.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA18503; Sat, 1 Jul 95 18:43:07 EDT To: info-cvs@prep.ai.mit.edu Subject: [berliner@bilge.Central.Sun.COM: Re: Beta CVS test version 1.4.92 now available] Reply-To: Don Dwiggins Date: Sat, 1 Jul 95 15:41:46 PDT Sender: dwig@markv.com Message-Id: <9507011541.aa14803@hermix.markv.com> Source-Info: From (or Sender) name not authenticated. Status: RO >From sun.com!prep.ai.mit.edu!info-cvs-request Tue Jun 27 10:08:46 1995 Return-Path: To: Tom Tromey Cc: James Kingdon , info-cvs@prep.ai.mit.edu Subject: Re: Beta CVS test version 1.4.92 now available In-Reply-To: Tom Tromey's message of Tue, 27 Jun 1995 00:03:52 MDT. Date: Tue, 27 Jun 1995 10:57:04 MDT From: Brian Berliner > On Tue, 27 Jun 95 00:03:52 MDT, Tom Tromey said: >>>>> "James" == James Kingdon writes: James> Once the beta test is done, the resulting release will replace James> 1.3 on the GNU FTP sites. James> This does not duplicate work which is being done by Brian Berliner James> and/or David "zoo" Zuhn; neither of them has time to make a release. > I'd like to know what this means for the future of CVS. > Is Cyclic CVS now the main line of development? Or is it just a branch > that competes with the Berliner/zoo branch? It is not a branch. Cyclic CVS will become the "official" CVS, probably known as CVS 1.5, once this beta period is complete. It does not compete with what you call the Berliner/zoo branch (what was CVS 1.4 Alpha-2). In fact, CVS 1.4 Alpha-3 (which was never released) looked a heck of alot like Cyclic CVS (without the remote repository stuff). Please evaluate the CVS 1.4.92 release if you have the time to do so and let us know of any problems as soon as possible. Thanks! > I ask because I'm very interested in the long-term future of CVS -- the > PDDB, the "real" client/server implementation, that sort of thing. While > I find Cyclic CVS to be useful (I use it every day), I'm not really > convinced it is the way to go as a long-term solution. The CVS 1.4.92 release has a jointly designed lightweight version of the PDDB. It is not a Per-Directory-Data-Base, but it does handle adding and removing files in a much more robust way than CVS 1.3. Believe me. The CVS 1.4.92 remote repository support is, frankly, not the be-all and end-all of CVS client-server implementations, but it does work and will prove valuable to some set of users NOW. This implementation does not conflict with buiding another client-server version in the future. Somebody... please contribute one! This is free software and benefits greatly from YOUR contributions. Please support the CVS 1.4.92 and subsequent CVS 1.5 releases. Thanks, -Brian From info-cvs-request@prep.ai.mit.edu Mon Jul 3 09:24:04 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA15764 for ; Mon, 3 Jul 1995 09:24:02 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02260; Sat, 1 Jul 95 14:44:41 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA08415; Sat, 1 Jul 1995 16:44:34 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA07406; Sat, 1 Jul 1995 15:32:45 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA07401; Sat, 1 Jul 1995 15:32:44 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA07052; Sat, 1 Jul 1995 16:32:41 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id OAA00388; Sat, 1 Jul 1995 14:32:40 -0700 Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA15454; Sat, 1 Jul 95 17:32:34 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA09863; Sat, 1 Jul 1995 17:32:29 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA14623; Sat, 1 Jul 95 17:32:27 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id RAA14785; Sat, 1 Jul 1995 17:32:27 -0400 Date: Sat, 1 Jul 1995 17:32:27 -0400 Message-Id: <199507012132.RAA14785@kayak.odi.com> To: speakman@ender.iaf.uiowa.edu Cc: info-cvs@prep.ai.mit.edu In-Reply-To: (message from speakman on Thu, 29 Jun 1995 14:30:08 -0500 (CDT)) Subject: Re: problems with import time Reply-To: dgg@odi.com Status: RO > just imported some code to start a new branch, > the date (in *,v) shows some 5 hours in the future. > > now we can't check in anything (until 5 hours into the future) > When we try to commit, there is a commit error from 'ci' > complaining the revision to be committed is of an older date than > the initial revision(imported revision, which is ofcourse dated > 5 hours into the future). > > So what is a solution to this problem , other than waiting for > 5 hours. > > Thanks for all the help, > > speak This sounds to me like you are using a very old version of RCS (On HP maybe?). CVS and RCS (at least in revisions more recent than the Cretaceous), use GMT. "cvs import" writes GMT. If you then use some old version of RCS, which tries to use CDT, you are hosed. Try using "import" on a test file and a plain "ci" (i.e. *not* "cvs ci"). I'll bet your RCS "ci" produces a CDT time. If so, ftp over to ftp.gnu.ai.mit.edu and get RCS 5.6.0.1 or 5.7 and build it. If you try 5.6.0.1 on an HP, be prepared for some Makefile work. From info-cvs-request@prep.ai.mit.edu Mon Jul 3 09:27:38 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA15695 for ; Mon, 3 Jul 1995 09:27:24 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA01079; Sat, 1 Jul 95 12:59:36 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA27311; Sat, 1 Jul 1995 14:59:31 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03878; Sat, 1 Jul 1995 13:56:03 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03873; Sat, 1 Jul 1995 13:56:02 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA26871; Sat, 1 Jul 1995 14:55:59 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id MAA27389; Sat, 1 Jul 1995 12:55:58 -0700 Received: from access.rrinc.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA11836; Sat, 1 Jul 95 15:55:55 EDT Received: (from eric@localhost) by access.rrinc.com (8.6.12/8.6.12) id PAA05104; Sat, 1 Jul 1995 15:55:46 -0400 From: Eric Bloodworth Message-Id: <199507011955.PAA05104@access.rrinc.com> Subject: Re: Libraries, ranlib, and CVS To: woods@most.weird.com Date: Sat, 1 Jul 1995 15:55:46 -0400 (EDT) Cc: eric@rrinc.com, info-cvs@prep.ai.mit.edu In-Reply-To: from "Greg A. Woods" at Jul 1, 95 03:14:00 pm Reply-To: eric@rrinc.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Greg A. Woods wrote: > > [ On Sat, July 1, 1995 at 13:19:53 (-0400), Eric Bloodworth wrote: ] > > Subject: Re: Libraries, ranlib, and CVS > > > > I think this is the attitude of those who deal with small code > > bases or who collaborate over large distances (no shared network drives). > > > > Version control of libraries is a necessity for a tightly knit group who > > deals with a large shared code base. It's not a good idea to have > > everyone compiling their own libraries in this situation > > for several reasons: > > Oh, I'm very well aware of the issue of dealing with various library > revisions, esp. in large code environments (i.e. >5 million lines, or > whatever you might consider "large"). > > However, I don't think CVS is the right tool for doing release > management, esp. of intermediate libraries, in these situations. > > A tool that does help is something like OSF's ODE. I agree that CVS isn't exactly suited to the task. However, you _can_ do it with CVS if you are willing to build some scaffolding with perl scripts or something. CVS may be your only choice if you need something that runs on unix, NT and OS/2. I seem to remember ODE runs only on unix. > > However, good manual procedures and strict release management can take > the place of a complex policy-setting toolset. > > There's *lots* of literature on the subject.... > Phooey. I'm only willing to believe what some people write until my experience contradicts it. My experience is that when you are managing shared code for 11 different platforms, manual procedures break down a lot. You need a tool. > -- > Greg A. Woods > > +1 416 443-1734 VE3TCP robohack!woods > Planix, Inc. ; Secrets of the Weird > Eric ---- Eric D. Bloodworth || Recognition Research, Inc email: eric@rrinc.com || Phone: (703) 231-6500 Fax (703) 231-3568 Phone: (703) 231-4577 || Suite 1200, 1872 Pratt Drive E-mail preferred || Blacksburg VA 24060 ---------------------- Web Page: http://www.rrinc.com From info-cvs-request@prep.ai.mit.edu Mon Jul 3 09:29:12 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA16012 for ; Mon, 3 Jul 1995 09:29:11 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29193; Sat, 1 Jul 95 10:29:39 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA09471; Sat, 1 Jul 1995 12:29:32 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29300; Sat, 1 Jul 1995 11:20:09 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29293; Sat, 1 Jul 1995 11:20:07 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA08306; Sat, 1 Jul 1995 12:20:03 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id KAA16638; Sat, 1 Jul 1995 10:20:04 -0700 Received: from access.rrinc.com ([128.173.242.236]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA06127; Sat, 1 Jul 95 13:20:01 EDT Received: (from eric@localhost) by access.rrinc.com (8.6.12/8.6.12) id NAA02717 for info-cvs@prep.ai.mit.edu; Sat, 1 Jul 1995 13:19:53 -0400 From: Eric Bloodworth Message-Id: <199507011719.NAA02717@access.rrinc.com> Subject: Re: Libraries, ranlib, and CVS To: info-cvs@prep.ai.mit.edu Date: Sat, 1 Jul 1995 13:19:53 -0400 (EDT) In-Reply-To: from "Greg A. Woods" at Jun 30, 95 09:38:00 pm Reply-To: eric@rrinc.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Greg A. Woods wrote: > > [ On Fri, June 30, 1995 at 15:38:23 (-0700), Mike Ekberg wrote: ] > > Subject: Libraries, ranlib, and CVS > > > > Has anyone solved the riddle of how to archive libraries > > w/ CVS? Yes. It is possible with some work. I haven't had your problem with greatly expanding files. So far the expansion for each revision has been minimal. I'm not sure I understand the problem with the libraries being out of date. Perhaps you can give an example? > > Don't! ;-) > > Seriously, why bother? > > (I presume you have source for what's in them, no?) > I think this is the attitude of those who deal with small code bases or who collaborate over large distances (no shared network drives). Version control of libraries is a necessity for a tightly knit group who deals with a large shared code base. It's not a good idea to have everyone compiling their own libraries in this situation for several reasons: 1. It wastes time. (checking out a single library is many times faster than checking out the sources for the library and recompiling them) 2. It wastes space. (everyone will keep a copy of the sources checked out because its too slow to check them out when you need 'em). 3. The control over what is considered tested is in the wrong place. (the person who checks out the source--hope s/he uses the right tag!). 4. It duplicates effort. (Why compile a library multiple times?) > > Oh! Have you done "cvs admin -ko "? > > > BTW, I have CVS 1.3 and RCS 5.6, with GNU diff current. > > Perhaps it's time to upgrade, though if you've fixed all the bugs you've > tripped over in 1.3, perhaps you can wait for the final 1.4? > > > BTW, O'Reilly is spozed to have an SCCS/RCS book out soon. Anyone > > reviewed it, or seen it? > > Yup. > > Not bad, but not a word about CVS -- unless my comments changed that. > > My only quibble with the authors was that they've fallen into the same > trap everyone who ignores the first digit in a version number does -- > i.e. that it can correspond to a "release" so long as it is incremented > just *after* every release. In such a situation tags are redundant, > except for the case where you need CVS magic branches. > > They also spend a lot of time describing a tool somewhat like a limited > CVS, but that works with SCCS as well. Supposedly that tool will be > made available. > > I've not seen the final copy yet though.... > > -- > Greg A. Woods > > +1 416 443-1734 VE3TCP robohack!woods > Planix, Inc. ; Secrets of the Weird > Eric ---- Eric D. Bloodworth || Recognition Research, Inc email: eric@rrinc.com || Phone: (703) 231-6500 Fax (703) 231-3568 Phone: (703) 231-4577 || Suite 1200, 1872 Pratt Drive E-mail preferred || Blacksburg VA 24060 ---------------------- Web Page: http://www.rrinc.com From info-cvs-request@prep.ai.mit.edu Thu Jul 6 12:14:04 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA00013 for ; Thu, 6 Jul 1995 12:13:57 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA08191; Thu, 6 Jul 95 09:05:05 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA23030; Thu, 6 Jul 1995 11:04:58 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13759; Thu, 6 Jul 1995 09:48:59 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA13755; Thu, 6 Jul 1995 09:48:58 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA21350; Thu, 6 Jul 1995 10:48:53 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id IAA25160; Thu, 6 Jul 1995 08:48:50 -0700 Received: from bob.indirect.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA03882; Thu, 6 Jul 95 11:48:40 EDT Received: from bud.indirect.com (radsoft@bud.indirect.com [165.247.1.10]) by bob.indirect.com (8.6.9/8.6.9) with ESMTP id CAA14812; Thu, 6 Jul 1995 02:17:32 -0700 Received: (from radsoft@localhost) by bud.indirect.com (8.6.9/8.6.6) id IAA21920; Thu, 6 Jul 1995 08:48:15 -0700 Date: Thu, 6 Jul 1995 08:48:15 -0700 From: John Goodsen Message-Id: <199507061548.IAA21920@bud.indirect.com> To: info-cvs@prep.ai.mit.edu, sjm@merlin.anu.edu.au Subject: Re: help with bus error and cvs 1.5 Status: RO I've chased down the core dump on cvs checkout and the stack trace shows the bus error happening in a call to time(). This is on Solaris 2.4, sparc 20 compiled with Sun C++. The stack dump has been sent to the cvs developers and I haven't heard back from anyone yet. fwiw... -- John Goodsen -- The Dalmatian Group, Inc. -- jgoodsen@dalmatian.com From info-cvs-request@prep.ai.mit.edu Fri Jul 7 23:14:35 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA01631 for ; Fri, 7 Jul 1995 23:14:32 -0400 Received: from Central.Sun.COM (centralmail1.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA15962; Fri, 7 Jul 95 20:04:53 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA01183; Fri, 7 Jul 1995 22:04:46 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23678; Fri, 7 Jul 1995 20:52:09 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23673; Fri, 7 Jul 1995 20:52:08 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA29623; Fri, 7 Jul 1995 21:52:04 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id TAA13336; Fri, 7 Jul 1995 19:52:04 -0700 Received: from sydney.DIALix.oz.au ([192.203.228.34]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA25733; Fri, 7 Jul 95 22:51:58 EDT Received: from babel.UUCP (babluucp@localhost) by sydney.DIALix.oz.au (8.6.12/8.6.12/DIALix) with UUCP id MAA02815 for prep.ai.mit.edu!info-cvs; Sat, 8 Jul 1995 12:51:55 +1000 Date: Sat, 8 Jul 95 11:57 EST From: del@babel.dialix.oz.au (Del) Subject: CVS and gnats To: info-cvs@prep.ai.mit.edu Message-Id: Status: RO Hi guys, I'm in the process of integrating some gnats (GNU problem tracking system) functionality in to tkCVS (which is a GUI front end to CVS for those who haven't heard about it yet). Yes, I know about tkgnats. I have a copy and have played with it quite a bit. What I'm thinking of doing, as an optional add-on module to tkCVS is producing a bit of "configuration management" functionality by integrating the problem tracking bit with the check-in or tag bits. Here are the options at the moment: a. If you check a file in of a certain module (depending on the contents of the modules file) you must have a valid gnats problem ID to check that in with; or b. Tagging files and modules with certain tags (depending on the contents of a tag-lock file in CVSROOT) will mean that a valid problem ID must be supplied. I imagine that a "build manager" or "SCM manager" will have the authority to turn on and off the must-have-problem-ID flags in tkCVS. This is so that modules in development need not be marked against valid problem IDs, but delivered modules must be. What I'm interested in is hearing from people that use both CVS and gnats (or possibly some other stand-alone problem tracking system, but gnats is the one I will use as the core of this development) so that I can get some idea of: a. What you do in your CM environment about integrating problem tracking and version control. b. What set of requirements I need to pay attention to while developing this add-on. Note that this will not affect the base functionality of tkCVS. It will be an optional package which you may or may not choose to install over the top of tkCVS if you want problem tracking functionality. This won't affect the functionality of tkgnats either -- tkgnats will stay there as it is to track the problems. What I will provide is a simple mapping between problem space and CVS repository maintenance. Also, what I'm not interested in hearing is "Continuus/CCC/ Harvest/someothersystem does it this way and here is the design description for it". I want this to be a freeware product and I don't want to be seen to be ripping off other people's ideas to go in to it. Del -- -------------------------------+------------------------------------- Del | del@babel.dialix.oz.au -------------------------------+------------------------------------- From info-cvs-owner@floss.cyclic.com Wed Jul 19 17:10:17 1995 Received: from floss.cyclic.com (floss.cyclic.com [204.177.235.66]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id RAA23439 for ; Wed, 19 Jul 1995 17:10:16 -0400 Received: (from majordomo@localhost) by floss.cyclic.com (8.6.9/8.6.9) id NAA05345 for info-cvs-outgoing; Wed, 19 Jul 1995 13:56:53 -0500 Received: from totoro.cyclic.com (totoro.cyclic.com [204.177.235.65]) by floss.cyclic.com (8.6.9/8.6.9) with ESMTP id NAA05341 for ; Wed, 19 Jul 1995 13:56:48 -0500 Received: from sydney.DIALix.oz.au (sydney.DIALix.oz.au [192.203.228.34]) by totoro.cyclic.com (8.6.9/8.6.9) with ESMTP id NAA27819 for ; Wed, 19 Jul 1995 13:55:15 -0500 Received: from babel.UUCP (uucp@localhost) by sydney.DIALix.oz.au (8.6.12/8.6.12/DIALix) with UUCP id EAA25785 for cyclic.com!info-cvs; Thu, 20 Jul 1995 04:55:44 +1000 Date: Wed, 19 Jul 95 19:50 EST From: del@babel.dialix.oz.au (Del) Subject: Lock required on tag.c and rtag.c To: info-cvs@cyclic.com Message-Id: Sender: owner-info-cvs@floss.cyclic.com Precedence: bulk Status: RO Hi CVS hackers, Can anyone who has (or is intending to do) minor revisional-type work to src/tag.c and src/rtag.c please hold off for a week or so. I am implementing a facility to have a "taginfo" file that gets searched on tagging functions in he same way that "commitinfo" gets searched on commits. Unfortunately, to do this I have to put in some fairly major pre-operation checks into both tag.c and rtag.c (including building up a linked list of files to be tagged in the same way that commit.c does it) which will mean a fairly major re-write of both of these files. It will be a week or two before I can get my changes checked back in to the repository at cyclic. They will be extensive, and so updates involving a merge will probably fail. Therefore I am requesting that people do not start work on any new mods to these files before I get my stuff checked back in. Del -- -------------------------------+------------------------------------- Del | del@babel.dialix.oz.au -------------------------------+------------------------------------- From kfogel@totoro.cyclic.com Thu Jul 13 00:01:00 1995 Received: from totoro.cyclic.com (totoro.cyclic.com [204.177.235.65]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id AAA21242 for ; Thu, 13 Jul 1995 00:00:58 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by totoro.cyclic.com (8.6.9/8.6.9) with ESMTP id VAA22180 for ; Wed, 12 Jul 1995 21:52:18 -0500 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id TAA13658; Wed, 12 Jul 1995 19:50:54 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA21556; Wed, 12 Jul 1995 21:50:46 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19027; Wed, 12 Jul 1995 20:45:43 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA19022; Wed, 12 Jul 1995 20:45:42 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA21193; Wed, 12 Jul 1995 21:45:38 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id TAA13281; Wed, 12 Jul 1995 19:45:38 -0700 Received: from sydney.DIALix.oz.au by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA14147; Wed, 12 Jul 95 22:45:30 EDT Received: from babel.UUCP (babluucp@localhost) by sydney.DIALix.oz.au (8.6.12/8.6.12/DIALix) with UUCP id MAA08012 for prep.ai.mit.edu!info-cvs; Thu, 13 Jul 1995 12:45:19 +1000 Date: Thu, 13 Jul 95 08:18 EST From: del@babel.dialix.oz.au (Del) Subject: Re: cvs history question To: info-cvs@prep.ai.mit.edu Message-Id: In-Reply-To: Status: RO > As did I. But this means (obviously) that the history file is now > incorrect, since it does not show me checking out said module. > It defeats the purpose of a history file if checking out > individual files or sub directories happens on a semi regular basis. > > So it would seem (to me) that the history command needs to be > changed to accomodate this. Of course, others may disagree. And > it may have been changed in 1.5, I've compiled it, but I haven't > installed it yet. Of course, the basic problem is that "rm" doesn't write to the history file! The history mechanism in CVS is relatively badly designed at the moment and does need a lot of work. 1.5 is not much better. A lot of the entries in the TODO file have got to do with getting the history file to work better. Del -- -------------------------------+------------------------------------- Del | del@babel.dialix.oz.au -------------------------------+------------------------------------- From info-cvs-request@prep.ai.mit.edu Thu Jul 13 06:21:18 1995 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id GAA25926 for ; Thu, 13 Jul 1995 06:21:15 -0400 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id DAA18545; Thu, 13 Jul 1995 03:20:42 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA22570; Thu, 13 Jul 1995 05:20:37 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01053; Thu, 13 Jul 1995 04:13:26 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01048; Thu, 13 Jul 1995 04:13:25 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA22095; Thu, 13 Jul 1995 05:13:23 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id DAA18033; Thu, 13 Jul 1995 03:13:20 -0700 From: gtornblo@senet.abb.se Received: from snex11.senet.abb.se by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA24661; Thu, 13 Jul 95 06:13:09 EDT Received: from localhost by snex11.senet.abb.se; (5.65/1.1.8.2/03Oct94-0154PM) id AA06595; Thu, 13 Jul 1995 12:16:39 +0200 Message-Id: <9507131016.AA06595@snex11.senet.abb.se> To: info-cvs@prep.ai.mit.edu Subject: RE: Why do I get a sticky conflict ? Date: Thu, 13 Jul 95 12:16:38 +0200 X-Mts: smtp Status: RO Thanks for all help I got on this topic. Loren (rittle@comm.mot.com) told me that a conflict like this one is OK: 1 2 <<<<<<< abba 3 bbbbb4 ======= aaaaa3 4 >>>>>>>> 1.1.2.3 5 I.e. to get conflict markers even if A and B did not modify the same lines. Loren writes: >The reason the above output is correct is that changes on consecutive >lines are considered conflicts under RCS 5.7 at least. I did not know that and thought that it was a problem with my installation of diffutils-rcs-cvs. Since then I have installed DIFFUTILS 2.7, RCS 5.7 and CVS 1.5 on a DEC alpha - OSF/1 3.2 , run all CVS and RCS sanity checks (thanks again Loren) and they passed without problems. SUMMARY: - CVS 1.5 with GNU diffutils-2.7 and RCS-5.7 builds and runs successfully on a DEC alpha with OSF/1 3.2 (add this to the INSTALL document if 'you' like) - My suspected error, to get a conflict in this situation is not what I like but obviosuly a RCS behaviour that I will have to live with. Thanks Gunnar From info-cvs-request@prep.ai.mit.edu Wed Jul 12 17:48:53 1995 Received: from totoro.cyclic.com (totoro.cyclic.com [204.177.235.65]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id RAA06052 for ; Wed, 12 Jul 1995 17:48:52 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by totoro.cyclic.com (8.6.9/8.6.9) with ESMTP id MAA20003 for ; Wed, 12 Jul 1995 12:25:48 -0500 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id KAA27927; Wed, 12 Jul 1995 10:21:21 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA14946; Wed, 12 Jul 1995 12:21:11 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06085; Wed, 12 Jul 1995 11:12:17 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06080; Wed, 12 Jul 1995 11:12:14 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA13554; Wed, 12 Jul 1995 12:12:10 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id KAA25505; Wed, 12 Jul 1995 10:12:07 -0700 Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA06907; Wed, 12 Jul 95 13:11:44 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Wed, 12 Jul 95 13:10:55 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Wed, 12 Jul 95 13:10:55 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: Karl Fogel Cc: cyclic-cvs@cyclic.com, info-cvs@prep.ai.mit.edu Subject: Re: mailing list merge In-Reply-To: Karl Fogel's message of "Wed, July 12, 1995 11:28:33 -0500" regarding "mailing list merge" id <199507121628.LAA07402@floss.cyclic.com> References: <199507121628.LAA07402@floss.cyclic.com> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Wed, July 12, 1995 at 11:28:33 (-0500), Karl Fogel wrote: ] > Subject: mailing list merge > > The various CVS mailing lists (*@prep.ai.mit.edu and > *@cyclic.com) are being consolidated into two lists: > > - info-cvs@cyclic.com is like info-cvs@prep.ai.mit.edu, and people in > the latter list will automatically be included in the new one. > The cyclic-cvs@cyclic.com mailing list goes away, and its > members will be moved automatically to info-cvs@cyclic.com. I presume info-cvs@prep.ai.mit.edu will continue be the publicly advertised gateway for this list (even if it just forwards to info-cvs@cyclic.com)? We are talking about a GNU tool here, no? Keeping it at prep will probably make it easy to instantly have it gatewayed to a gnu.cvs newsgroup. > This should be the last, or nearly the last, message sent to > cyclic-cvs@cyclic.com. It will soon start forwarding to > bug-cvs@cyclic.com; but the latter is the preferable address and > cyclic-cvs@cyclic.com should be phased out. You probably don't want to phase it out until the next "major" release of CVS (i.e. CVS-1.6?), when the cvsbug(8) command can be updated.... -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Sat Jul 8 02:42:50 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id CAA32564 for ; Sat, 8 Jul 1995 02:42:50 -0400 Received: from Central.Sun.COM (centralmail1.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21182; Fri, 7 Jul 95 23:35:02 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA26098; Sat, 8 Jul 1995 01:34:55 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28994; Sat, 8 Jul 1995 00:23:28 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28989; Sat, 8 Jul 1995 00:23:26 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA24690; Sat, 8 Jul 1995 01:23:23 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id XAA24660; Fri, 7 Jul 1995 23:23:22 -0700 Received: from seraph.uunet.ca (uunet.ca) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA01183; Sat, 8 Jul 95 02:23:19 EDT Received: from now by mail.uunet.ca with UUCP id <182221-3>; Sat, 8 Jul 1995 02:25:17 -0400 From: Eric Siegerman To: info-cvs@prep.ai.mit.edu Date: Fri, 7 Jul 1995 23:27:45 -0400 Message-Id: <950707232745.22559@now.com> Subject: The (political) future of CVS Status: RO There's a lot of discussion here about how CVS should be enhanced, but the release of 1.5 raises a question about the circumstances under which this might happen. The CVS FAQ (ver. 3.5, as shipped with CVS 1.5), was changed quite recently, mostly to contain a description of '"Cyclic CVS" (CCVS) that can handle remote repositories'. It still talks about CCVS as a branch off from 1.4A2, and gives no indication of any change in this state of affairs. But CCVS has become CVS 1.5 -- including the remote-repository code. I'm confused. What's the state of CCVS as a separate line of development? Is the intent that Cyclic Software, and Jim Blandy in particular, will become the official maintainer for "mainline" CVS, automatically rolling into it any changes made on Cyclic's behalf? Or was the recent merge of Berliner's and Blandy's code streams a one-time event, from which CCVS will immediately begin diverging again? If the former, is there still any point to separate info-cvs and cyclic-cvs mailing lists, or should these be merged as well? Of course, it may well be simply that the FAQ is out of date and needs a good going-over. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont. erics@now.com | | / This fiendish string devised by my student Annie Senghas is a grammatical English sentence: Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo. - Steven Pinker, _The Language Instinct_ From info-cvs-request@prep.ai.mit.edu Sat Jul 8 04:37:05 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA11223 for ; Sat, 8 Jul 1995 04:37:04 -0400 Received: from Central.Sun.COM (centralmail1.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02312; Sat, 8 Jul 95 01:28:59 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA09000; Sat, 8 Jul 1995 03:28:53 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00346; Sat, 8 Jul 1995 02:07:29 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA00341; Sat, 8 Jul 1995 02:07:28 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA06373; Sat, 8 Jul 1995 03:07:24 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id BAA28459; Sat, 8 Jul 1995 01:07:23 -0700 Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA02578; Sat, 8 Jul 95 04:07:19 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id DAA00272; Sat, 8 Jul 1995 03:07:09 -0500 Date: Sat, 8 Jul 1995 03:07:09 -0500 From: Jim Blandy Message-Id: <199507080807.DAA00272@totoro.cyclic.com> To: Eric Siegerman Cc: info-cvs@prep.ai.mit.edu Subject: The (political) future of CVS In-Reply-To: <950707232745.22559@now.com> References: <950707232745.22559@now.com> Gnu-Emacs: featuring the world's first municipal garbage collector! Status: RO The FAQ shouldn't describe Cyclic CVS as a branch separate from CVS 1.5; they are one and the same. (At the time the FAQ was updated, this wasn't clear.) Our intention is for Cyclic CVS to be the main line of CVS development. Cyclic CVS was originally a branch off 1.4A2, but now it is the trunk. We're wondering about the mailing lists too. At the moment, we can't think of any terribly clear semantic distinction between the two, and I've seen hints that people seem to be subscribing to them both at once, suggesting they're not sure of the difference either. :-) So we're leaning towards unioning them. Brian Berliner has already asked me to take over managing info-cvs, so this shouldn't be hard to do. (My guilt gland is flaring up; please don't call it "Blandy's code", since my personal contribution to the CVS 1.5 code is minimal. The remote support was done by Jim Kingdon, with help from others at Cygnus Support. J. T. Conklin contributed many speedups. And others, etcetera.) From info-cvs-request@prep.ai.mit.edu Mon Jul 10 16:03:13 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id QAA13852 for ; Mon, 10 Jul 1995 16:02:59 -0400 Received: from Central.Sun.COM (centralmail1.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00894; Mon, 10 Jul 95 12:50:26 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA27979; Mon, 10 Jul 1995 14:50:20 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03727; Mon, 10 Jul 1995 13:48:10 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA03710; Mon, 10 Jul 1995 13:48:08 -0600 Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA27834; Mon, 10 Jul 1995 14:48:03 -0500 Received: from life.ai.mit.edu by venus.Sun.COM (Sun.COM) id MAA25699; Mon, 10 Jul 1995 12:47:59 -0700 Received: from tss.ca by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA02101; Mon, 10 Jul 95 15:46:31 EDT Received: from ganglion (ganglion.tss.ca) by tss.ca with SMTP id AA11880 (5.65c/IDA-1.4.4 for info-cvs@prep.ai.mit.edu); Mon, 10 Jul 1995 15:47:10 -0400 Received: by ganglion (1.38.193.4/16.2) id AA04117; Mon, 10 Jul 1995 15:46:01 -0400 Date: Mon, 10 Jul 1995 14:29:58 +0500 (EST) From: Brian Onn Sender: Brian Onn Reply-To: Brian Onn Subject: branch problem To: info-cvs@prep.ai.mit.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO I have a problem that I don't know the best way to solve. I created a branch with 'cvs rtag -b branch'. Then I checked out this branch into a new directory with 'cvs co -r branch'. I have been working on this branch, updating the repository with 'cvs update', and adding files with 'cvs add' and then 'cvs commit'. I did not use the '-r branch' option with either of the update/add/commit commands from the branch directory. Everything is fine except for the added files. The updates are visible only in the branch, but the files I added are visible when someone does a 'cvs update' from the main trunk. This is wrong. Any idea why this happened? To fix this, should I modify the repository directory? The files added to the branch should have been placed into the attic, but they weren't. This is cvs 1.3, no patches. I'm also having trouble merging the changes from the trunk into the branch using 'cvs update -j HEAD' from within the branch directory. All this seems to do is print a message like "RCS File: /path/to/repository/..." and create a .# file in the current directory. A diff shows that the .# files are identical to their counterparts, and manual inspection shows that none of the updates from the trunk have been merged into the branch. Thanks for any pointers. Brian. --- Brian A. Onn CTS Development Engineer, Teknekron Software Systems Toronto, Ontario, Canada. From info-cvs-request@prep.ai.mit.edu Tue Jul 11 11:46:34 1995 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id LAA09426 for ; Tue, 11 Jul 1995 11:46:32 -0400 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id IAA17465; Tue, 11 Jul 1995 08:39:14 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA28906; Tue, 11 Jul 1995 10:39:06 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA25710; Tue, 11 Jul 1995 09:24:32 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA25705; Tue, 11 Jul 1995 09:24:30 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA28254; Tue, 11 Jul 1995 10:24:27 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id IAA15147; Tue, 11 Jul 1995 08:24:26 -0700 Received: from tss.ca by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA23264; Tue, 11 Jul 95 11:24:15 EDT Received: from ganglion (ganglion.tss.ca) by tss.ca with SMTP id AA13700 (5.65c/IDA-1.4.4 for info-cvs@prep.ai.mit.edu); Tue, 11 Jul 1995 11:24:37 -0400 Received: by ganglion (1.38.193.4/16.2) id AA10551; Tue, 11 Jul 1995 11:23:29 -0400 Date: Tue, 11 Jul 1995 10:32:01 +0500 (EST) From: Brian Onn Subject: Re: CVS in an heterogenous environment To: info-cvs@prep.ai.mit.edu In-Reply-To: <199507110520.AAA22851@tlsun5a.itg.ti.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I'm not an experienced 1.5 user, but here is what I found out with my brief experiment with it yesterday. I'm an experienced 1.3 user, although not necessarily a user of all it advanced features. On Tue, 11 Jul 1995, Ramamurthy wrote: > 1) I could not fully understand how to use this remote operation > feature. Where can I get some more details on this. If you didn't build it with kerberos support, it uses a simply rsh command from the client machine to the server machine, and expects that the user on the client can execute remote commands on the server without the need to enter a password. Try 'rsh server ls' to see if you have the proper permissions, and if not put the client hostname in you ~/.rhosts file on the server. The command executed on the server is 'cvs server', so your paths have to be setup correctly on the server such that it can find the cvs binary on the server. If you did build it with kerberos support, it expects to find 'cvs' listed in /etc/services and makes a TCP connection to execute a kerberos authorized rcmd command to start a cvs server. > 2) Is it possible that a client can be a DOS/OS2 client and SERVER is > running on UNIX platform. If not can this be set up. Given that it is designed around rsh, I don't think a generic DOS, OS2, or windows client would be possible (some TCP packages for DOS/OS2 do provide a rsh client, but I'd rather see all DOS/OS2/Windows clients use kerberos instead. I don't know if the kerberos client side is available for DOS or OS2. Also, the 1.5 code would need to be ported, since all the usual DOS 8.3 file naming conventions get in your face at every turn. And the code that checks if CVSROOT contains a ':' character to determine if the repository is remote or not would have to change to support local repositories on DOS drives. Not to mention NOVELL Volumes :-) I'd like to see a port to Win/95, since at least that supports long file names and you could have true compatibility with the server side on Unix. If no one is going to do this, I'd be willing to be on the Projects list for this one. > Best Regards, > Ram ( srm@india.ti.com ) Brian. --- Brian A. Onn CTS Development Engineer, Teknekron Software Systems Toronto, Ontario, Canada. From info-cvs-request@prep.ai.mit.edu Tue Jul 11 15:59:01 1995 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id PAA14753 for ; Tue, 11 Jul 1995 15:58:53 -0400 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id MAA11899; Tue, 11 Jul 1995 12:55:53 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA12984; Tue, 11 Jul 1995 14:55:45 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24475; Tue, 11 Jul 1995 13:48:27 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24470; Tue, 11 Jul 1995 13:48:25 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA12560; Tue, 11 Jul 1995 14:48:23 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id MAA10175; Tue, 11 Jul 1995 12:48:11 -0700 Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA08902; Tue, 11 Jul 95 15:48:07 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA00996; Tue, 11 Jul 1995 15:47:57 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA25773; Tue, 11 Jul 95 15:47:40 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id PAA21029; Tue, 11 Jul 1995 15:47:39 -0400 Date: Tue, 11 Jul 1995 15:47:39 -0400 Message-Id: <199507111947.PAA21029@kayak.odi.com> To: berliner@bilge.Central.Sun.COM Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9507111222.AA17260@bilge.Central.Sun.COM> (message from Brian Berliner on Tue, 11 Jul 1995 06:22:43 MDT) Subject: Re: The (political) future of CVS Reply-To: dgg@odi.com Status: RO > > Of course, it may well be simply that the FAQ is out of date and needs a > > good going-over. > > Yep! We do need a volunteer to do this, though. Anyone? I wrote the FAQ for CVS 1.3 a little over two years ago when I was using CVS heavily at Thinking Machines. Last Fall I spent some time testing 1.4A2 and updated the FAQ accordingly. I also incorporated data from 100 or so info-cvs messages I thought were FAQs of some sort. Since then I've made a few minor changes as people request them. I have some suggestions in my mailbox (that I haven't yet dealt with) for changes referring to RCS 5.7 and Cyclic. The FAQ needs updating for CVS 1.5. If someone (from Cyclic?) volunteers to take it over entirely, then I'm willing to incorporate the queued changes I have, hand it over and back off. If no one wants to take it on, then I'll take diffs, suggested changes and proposed additions and add them to the FAQ when I get a few minutes. BTW, unless it has changed, the FSF wants a single individual as the "official maintainer" of CVS, not a company or a group of people. To date that person has been Brian Berliner. Has it changed? In any case, that "official maintainer" should be the one to take applications for the new FAQ maintainer, if there is to be one. From info-cvs-request@prep.ai.mit.edu Tue Jul 11 16:58:28 1995 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id QAA26587 for ; Tue, 11 Jul 1995 16:58:25 -0400 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id NAA25590; Tue, 11 Jul 1995 13:55:55 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA16388; Tue, 11 Jul 1995 15:55:47 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28241; Tue, 11 Jul 1995 14:36:15 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA28236; Tue, 11 Jul 1995 14:36:13 -0600 Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA15344; Tue, 11 Jul 1995 15:36:01 -0500 Received: from life.ai.mit.edu by venus.Sun.COM (Sun.COM) id NAA11071; Tue, 11 Jul 1995 13:35:58 -0700 Received: from uni.ins.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA12194; Tue, 11 Jul 95 16:34:39 EDT Received: from marcbpc.ins.com (marcbpc.ins.com [199.0.193.195]) by uni.ins.com (8.6.12/8.6.12) with SMTP id NAA18658; Tue, 11 Jul 1995 13:34:32 -0700 Date: Tue, 11 Jul 1995 13:34:32 -0700 Message-Id: <199507112034.NAA18658@uni.ins.com> X-Sender: marcb@uni.ins.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Mike Ekberg , info-cvs@prep.ai.mit.edu From: marcb@ins.com (Marc Bernstein) Subject: Re: compex modules examples Status: RO As another example in addition to those described by Mike, I have a module tree like the following: a - ... b - c - d - e (foo, bar) where the letters reperesent directories under cvsroot and foo and bar are files under e. if I want a module that has everything under b i can use bmod b if i want everything under b except foo.c in the e directory I try specialmod b c d e bar This was my understanding of the syntax, but it didn't work. Any suggestions? At 12:45 PM 7/11/95 -0700, Mike Ekberg wrote: >There is one in the examples directory, but may not be "complex" >enough. I'd like to see another one in there that has: > > 1. subdirectories w/ common names, e.g. > foo/bar/include > a/b/include > > 2. more than two levels of hierarchy, see above. > >Generally, the documentation of the modules is not complete enough to >be useful for complex hierarchies. > > >>From info-cvs-request@prep.ai.mit.edu Tue Jul 11 12:32:34 1995 > >>X-Sender: marcb@uni.ins.com > >>To: info-cvs@prep.ai.mit.edu > >>From: marcb@ins.com (Marc Bernstein) > >>Subject: compex modules examples > >> > >>Where can I find examples of complex modules files? > >>######################################### > >># marcb@netcom.com 415 759 7532 # > >># marcb@ins.com 415 254 4254 # > >>######################################### > >> > >> > > ######################################### # marcb@netcom.com 415 759 7532 # # marcb@ins.com 415 254 4254 # ######################################### From info-cvs-ownrr@prep.ai.mit.edu Mon Jul 24 14:48:25 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA31426 for ; Mon, 24 Jul 1995 14:48:17 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA19270; Mon, 24 Jul 95 05:43:54 EDT Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA19237; Mon, 24 Jul 95 05:43:39 EDT Received: (from zoo@localhost) by monad.armadillo.com (8.6.12/8.6.12) id EAA29563 for info-cvs@prep.ai.mit.edu; Mon, 24 Jul 1995 04:45:05 -0500 Date: Mon, 24 Jul 1995 04:45:05 -0500 From: "david d `zoo' zuhn" Message-Id: <199507240945.EAA29563@monad.armadillo.com> To: info-cvs@prep.ai.mit.edu Subject: info-cvs mini-faq (Weekly posting, last modified Thu Jul 6 1995) Status: RO This is an automatically posted mini-FAQ. The "Subject:" header will not change unless the contents of the mini-FAQ change, which I hope will be infrequently. In any case, the format of the Subject will not change. The following questions are answered in this mini-FAQ. Please check to see if your question/concern/problem is answered here before sending mail to the list at large. What is CVS? Where do I find the real full-sized FAQ? What is this mailing list for? What is the current version of CVS and where is it? What does "Too many arguments!" mean? What other sources of information are available? How do I unsubscribe to this list? If you have any questions or comments about this mini-FAQ, please direct them to me and not to the list at large. My email address is 'zoo@armadillo.com'. Please include this $Revision: 1.5 $ number with any comments 1. What is CVS? "CVS" is an acronym for the "Concurrent Versions System". CVS is a "Source Control" or "Revision Control" tool designed to keep track of source changes made by groups of developers working on the same files, allowing them to stay in sync with each other as each individual chooses. 2. Where do I find the real full-sized FAQ? By anonymous ftp to ftp://ftp.odi.com/pub/users/dgg/FAQ.gz Via the World Wide Web at http://www.winternet.com/~zoo/cvs/FAQ.txt If you're new to CVS, or haven't read it lately, please read this FAQ. David Grubbs has done a very nice job of keeping it complete and up to date. 3. What is this mailing list for? This list is for discussion about installing and using CVS. Talk about work on CVS is also welcome, as are enhancements and bugfixes. Bug reports should go to bug-cvs@prep.ai.mit.edu (or use the cvsbug script in the newer CVS release). 4. What is the current version of CVS and where is it? The current officially released version is 1.5 at ftp://prep.ai.mit.edu/pub/gnu/cvs-1.5.tar.gz as well as the usual GNU archive mirror sites. 5. What does "Too many arguments!" mean? CVS 1.4a2 has a cvsinit script that incorrectly sets up the loginfo file, but only if perl is available. If you don't have perl, you won't see this message (I don't have perl installed, which is why my testing didn't catch this bug). If you do have perl, you can apply the patch at the end of this message to your 1.4a2 distribution, or make the same change to your installed loginfo file (add a -f between %s and $CVSROOT). 6. What other sources of information are available? First off, the FAQ (see #2 above). Several WWW sites have information about CVS: http://www.winternet.com/~zoo/cvs/ http://www.loria.fr/~molli/cvs-index.html 7. How do I unsubscribe to this list? Please do NOT send a message to the entire list asking to unsubscribe. You'll only succeed in sending the message to hundreds of people who can't do anything about it. Send mail to info-cvs-request@prep.ai.mit.edu, and ask to be removed. The best way would be to include the text: unsubscribe info-cvs While someday the list may be automated, it is currently handled manually, and Brian is a very busy person. So it might take a while for things to happen. Please don't get frustrated and send mail to the list as a whole. Only Brian can remove you from the list. Appendices: I. The loginfo patch for 1.4a2 *** scratch/loginfo Sun Feb 12 19:51:25 1995 --- examples/loginfo Sun Feb 12 19:51:46 1995 *************** *** 18,20 **** # in addition to the first matching regex or DEFAULT. # ! DEFAULT $CVSROOT/CVSROOT/log.pl %s $CVSROOT/CVSROOT/commitlog --- 18,20 ---- # in addition to the first matching regex or DEFAULT. # ! DEFAULT $CVSROOT/CVSROOT/log.pl %s -f $CVSROOT/CVSROOT/commitlog From info-cvs-ownrr@prep.ai.mit.edu Wed Jul 26 18:12:22 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA21563 for ; Wed, 26 Jul 1995 18:12:22 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA06792; Wed, 26 Jul 95 09:05:23 EDT Received: from cs.umn.edu (mail.cs.umn.edu) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA06779; Wed, 26 Jul 95 09:05:03 EDT Received: from twain.cs.umn.edu (twain.cs.umn.edu [128.101.230.63]) by mail.cs.umn.edu (8.6.11/8.6.6) with ESMTP for From: bmiller@cs.umn.edu (Brad Miller) Received: by twain.cs.umn.edu (8.6.12) id IAA25910; Wed, 26 Jul 1995 08:04:51 -0500 Date: Wed, 26 Jul 1995 08:04:51 -0500 Message-Id: <199507261304.IAA25910@twain.cs.umn.edu> To: info-cvs@prep.ai.mit.edu Subject: Trashed Log?? Status: RO Here's an example of what happens when I try to do a cvs log, on some of the files in my repository. RCS file: /project/neural01/cvs-repository/GroupLens/db/RowsFile.C,v Working file: RowsFile.C head: 1.18 branch: locks: strict access list: symbolic names: release_beta_1: 1.17 design-stable: 1.5 comment leader: " * " keyword substitution: kv total revisions: 18; selected revisions: 18 description: rlog: /project/neural01/cvs-repository/GroupLens/db/RowsFile.C,v:804: \ missing delta log rlog aborted I also sometimes get this: rlog: /project/neural01/cvs-repository/GroupLens/db/db.h,v:559: \ unexpected end to edit script rlog aborted Is there any way to recover the log info from the files? So far I haven't experienced any problems committing changes to these files. I've only had logging problems. I have a feeling this may be due to some NFS problems we were experiencing during a week of heavy development. Prior to the release of cvs-1.5. \Brad PS To the cvs developers: great job on remote cvs! Two years ago a couple of us developed our own version of remote CVS using email as the underlying transport mechanism. It worked great, but it was awfully slow compared to this model. The only benefit to using email, is that it works well for working with people inside firewalls, and it works pretty well when you are in a "seldomly connected" networking environment. Has anyone given any thought about how to make the current version work in either of those environments? ---------------------------------------------------------------------------- Brad Miller | e-mail: bmiller@cs.umn.edu University of Minnesota | phone: (612) 626-8396 Department of Computer Science | www: http://www.cs.umn.edu/users/bmiller EE/CS 5-244 | ---------------------------------------------------------------------------- From info-cvs-ownrr@prep.ai.mit.edu Thu Jul 20 23:18:26 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA10477 for ; Thu, 20 Jul 1995 23:18:20 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA18128; Thu, 20 Jul 95 16:26:42 EDT Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA17274; Thu, 20 Jul 95 16:26:06 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Wed, 19 Jul 95 11:24:35 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Wed, 19 Jul 95 11:24:35 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: cwong@world.std.com (Christopher Wong) Cc: info-cvs@prep.ai.mit.edu Subject: Re: Experience with cvs under SCO Xenix 2.3.4 In-Reply-To: Christopher Wong's message of "Mon, July 17, 1995 21:52:21 -0500" regarding "Experience with cvs under SCO Xenix 2.3.4" id References: Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Mon, July 17, 1995 at 21:52:21 (-0500), Christopher Wong wrote: ] > Subject: Experience with cvs under SCO Xenix 2.3.4 > > The sanity script brings to light the inadequacies of the ancient > Xenix system. Firstly, it uses "ln -s" ... but Xenix does not have > symbolic links. I substituted the "copy -r" command to copy the thing > and get the test going. Secondly, file names like "imported-file1,v" > exceed the Xenix 14 character limit. Wowza! You're brave! BTW, What's "copy -r"? As for 14-char filename limits, there's quite a few places where that'll break things rather badly. I had a peek at porting CVS-1.3 to SysVr3.2 some time ago, but in order to make it work all the temp files, esp. those used for merging, needed major over-haul. I suggested putting them in tmp directories (named after the filename, with files there-in named after the revision-id) under the CVS directory (instead of as '.' files in the current directory), but I don't think that's been implemented (I confess I've never checked the sources). Another possiblity was to hash the names in a similar way that some MS-DOS emulators (eg. VP/ix) do. Supposedly there's a port of CVS-1.4A? to MS-DOS, and it must have had to deal with those issues, though again I've never checked to see if any of those solutions have made their way into the latest UNIX release. Now that my SysVr3.2 machine is languishing in the basement as a testing and porting machine only, I'm not so worried about supporting the software I use day-to-day on it. > Even with that out of the way, cvs fails on "make remotecheck". The > test 14-add-commit-m results in the error message > > Protocol error: uncounted data discarded. > > Does this look familiar to anyone? Thanks. I've never even tried the remote server yet.... ;-( The fact you're trying the remote server functions leads me to warn you that if your server is on a non-xenix platform, resolving the 14-char filename limits will likely be far more complex. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Wed Jul 19 14:14:24 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA22134 for ; Wed, 19 Jul 1995 14:14:22 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA12510; Wed, 19 Jul 95 07:54:50 EDT Received: from minster.cs.york.ac.uk by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA12482; Wed, 19 Jul 95 07:52:26 EDT From: mhw@minster.cs.york.ac.uk Message-Id: >From: mhw@minster.york.ac.uk (Mark H. Wilkinson) Date: Wed, 19 Jul 1995 12:48:33 +0000 In-Reply-To: Alastair Young's message, dated Jul 18, 3:36pm X-Url: http://Dcpu1.cs.york.ac.uk:6666/~mhw/ X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: younga1@kapiti.co.uk, info-cvs@prep.ai.mit.edu Subject: Re: Tag renaming Status: RO Alastair Young wrote: > Subject: Tag renaming > > Hello CVSers, we have a fairly large CVS system and I would like to change > the name of a branch that was recently created (and has a few changes on). > I have a feeling this is not too easy, maybe not even possible. > I've thought about doing it with some kind of awk script directly on the > rcs files, but I hesitate to do such a thing... > > I'd also like to be able to change the name of a 'normal' tag. Normal tags can be renamed quite simply. I use this script to do it: #!/bin/rc fn usage { echo usage: cvstagmv oldtag newtag modules ...>[1=2] exit 2 } ~ $1 () && usage oldtag=$1; shift ~ $1 () && usage newtag=$1; shift ~ $1 () && usage cvs rtag -r$oldtag $newtag $* cvs rtag -a -d $oldtag $* The basic idea is to create a new tag at the same revision as the old one then delete the old one. It fails for branch tags (i.e. if you add the -b option to rtag) because the new tag is treated as a new branch point rather than a new name for the old branch. You should be able to do it directly using cvs admin; something like cvs admin -n: . cvs admin -n . should work (check it first though!). -Mark. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Mark H. Wilkinson : Research student in user University of York, England : interface management systems From info-cvs-ownrr@prep.ai.mit.edu Wed Jul 19 13:09:40 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA19092 for ; Wed, 19 Jul 1995 13:09:37 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA07838; Wed, 19 Jul 95 05:07:15 EDT Received: from slsa02t.stgl.netd.alcatel.de by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA07831; Wed, 19 Jul 95 05:06:21 EDT Received: from slbh01t1.bln.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <10114-0@slsa02t.stgl.netd.alcatel.de>; Wed, 19 Jul 1995 11:06:12 +0200 Received: from slbh04 by bln.sel.alcatel.de (4.1/SMI-4.0/DNI-7.0.1/blume_h-1.2) id AA16754; Wed, 19 Jul 95 11:06:31 +0200 From: Uwe.Graichen@bln.sel.alcatel.de (U. Graichen) Received: by slbh04 (4.1) id AA22995; Wed, 19 Jul 95 11:06:22 +0200 Date: Wed, 19 Jul 95 11:06:22 +0200 Message-Id: <9507190906.AA22995@slbh04> To: info-cvs@prep.ai.mit.edu In-Reply-To: <9507181436.AA05753@kampala.kapiti.co.uk> (message from Alastair Young on Tue, 18 Jul 1995 15:36:32 +0100) Subject: Re: Tag renaming Status: RO >>>>> "A" == Alastair Young writes: A> Hello CVSers, we have a fairly large CVS system and I would A> like to change the name of a branch that was recently created A> (and has a few changes on). I have a feeling this is not too [...] You can do that with the 'cvs admin' command because branch tags are simple RCS labels (one hint: CVS magic branch handling:). Before you start the rename action, please have a lock to the RCS man page (rcs(1) option '-n'). cvs admin -n: file|module cvs tag -d oldtag file|module A> I'd also like to be able to change the name of a 'normal' tag. cvs rtag -r module cvs rtag -d module A> +--------------------------------------------------------+ | A> Alastair Young Tel: +44 1753 573244 | | Kapiti Ltd. Fax: +44 A> 1753 575964 | | Slough | | England Email: A> Alastair.Young@kapiti.co.uk | A> +--------------------------------------------------------+ --uwe +========= Uwe Graichen / ALCATEL SEL AG Berlin ===================+ Email: graichen@bln.sel.alcatel.de ( Expressed opinions which happen to ) correspond with those of my employer Phone: +49 30 7002 3578 ( are still my own. The others are mine. From gnu@ai.mit.edu Wed Jul 19 07:23:33 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id HAA07655 for ; Wed, 19 Jul 1995 07:23:31 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA21554; Tue, 18 Jul 95 20:13:31 EDT Received: from by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AB21414; Tue, 18 Jul 95 20:08:58 EDT Received: by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) id TAA24939; Tue, 18 Jul 1995 19:54:28 -0400 Resent-Date: Tue, 18 Jul 1995 19:54:28 -0400 Resent-Message-Id: <199507182354.TAA24939@gnu-life.ai.mit.edu> Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for gnu id AA13177; Tue, 18 Jul 95 10:24:20 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Tue, 18 Jul 95 10:23:49 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Tue, 18 Jul 95 10:23:49 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) Sender: gnu@prep.ai.mit.edu To: "Stefan Monnier" Cc: CVS Mailing-List Subject: Re: permissions In-Reply-To: Stefan Monnier's message of "Tue, July 18, 1995 13:54:21 +0200" regarding "permissions" id <16901.806068461@liasg7.epfl.ch> References: <16901.806068461@liasg7.epfl.ch> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Resent-From: info-cvs-request@prep.ai.mit.edu Status: RO [ On Tue, July 18, 1995 at 13:54:21 (+0200), Stefan Monnier wrote: ] > Subject: permissions > > But now the problem is that when I check out the directory, it still gets > permissions 755, even though the dir in the repository has 700. I'd agree this is a bug. CVS does seem to adhere to permissions set in the repository for other objects, thus it should for the module directory itself. Perhaps you could run cvsbug to report it? A related feature I'd like to see is an option to 'cvs import' that could be used to force CVS to either completely ignore permissions in the import directory, or to ignore everything but the execute bit on normal files, or to strictly adhere to all permissions. I think the default should be to ignore everything but the execute bit on files. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-owner@floss.cyclic.com Tue Jul 18 10:57:13 1995 Received: from floss.cyclic.com (floss.cyclic.com [204.177.235.66]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id KAA31500 for ; Tue, 18 Jul 1995 10:57:10 -0400 Received: (from majordomo@localhost) by floss.cyclic.com (8.6.9/8.6.9) id GAA32399 for info-cvs-outgoing; Tue, 18 Jul 1995 06:55:20 -0500 Received: from totoro.cyclic.com (totoro.cyclic.com [204.177.235.65]) by floss.cyclic.com (8.6.9/8.6.9) with ESMTP id GAA32395 for ; Tue, 18 Jul 1995 06:55:19 -0500 Received: from liasg7.epfl.ch (liasg7.epfl.ch [128.178.155.44]) by totoro.cyclic.com (8.6.9/8.6.9) with ESMTP id GAA21053 for ; Tue, 18 Jul 1995 06:53:59 -0500 Received: from liasg7.epfl.ch by liasg7.epfl.ch with esmtp (Smail3.1.28.1 #160) id m0sYBEJ-0006FfC; Tue, 18 Jul 95 13:54 MDT From: "Stefan Monnier" To: CVS Mailing-List Subject: permissions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 1995 13:54:21 +0200 Message-ID: <16901.806068461@liasg7.epfl.ch> Sender: owner-info-cvs@floss.cyclic.com Precedence: bulk Status: RO In my CVS repository, I have a private directory that contains information I don't want people to have access to. Hence, this private directory has access right 700. When I added it to my CVS repository, the dir in $CVSROOT got access rights 775. Since it's only done once and it's not easy for CVS to know that the 700 was really because I don't want anybody to see it and not just to protect the checkedout version, I understand that CVS created the dir with 775. So, I manually changed the permissions in the $CVSROOT diretory back to 700. But now the problem is that when I check out the directory, it still gets permissions 755, even though the dir in the repository has 700. You might say that CVS is not supposed to be used for such things, but I still think CVS should be a little bit more careful with permissions. Stefan From info-cvs-owner@floss.cyclic.com Sun Jul 16 07:06:34 1995 Received: from floss.cyclic.com (floss.cyclic.com [204.177.235.66]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id HAA05977 for ; Sun, 16 Jul 1995 07:06:32 -0400 Received: (from majordomo@localhost) by floss.cyclic.com (8.6.9/8.6.9) id AAA27270 for info-cvs-outgoing; Sun, 16 Jul 1995 00:49:04 -0500 Received: from totoro.cyclic.com (totoro.cyclic.com [204.177.235.65]) by floss.cyclic.com (8.6.9/8.6.9) with ESMTP id AAA27266 for ; Sun, 16 Jul 1995 00:49:01 -0500 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by totoro.cyclic.com (8.6.9/8.6.9) with SMTP id AAA09783 for ; Sun, 16 Jul 1995 00:47:58 -0500 Received: from sydney.DIALix.oz.au ([192.203.228.34]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@cyclic.com id AB01910; Sun, 16 Jul 95 01:48:13 EDT Received: from babel.UUCP (uucp@localhost) by sydney.DIALix.oz.au (8.6.12/8.6.12/DIALix) with UUCP id PAA04730; Sun, 16 Jul 1995 15:48:08 +1000 Date: Sun, 16 Jul 95 10:30 EST From: del@babel.dialix.oz.au (Del) Subject: Re: How can I extract the graph of version ancestory from CVS? To: info-cvs@prep.ai.mit.edu Cc: bmb@world.std.com Message-Id: In-Reply-To: <199507142040.AA22098@world.std.com> Sender: owner-info-cvs@floss.cyclic.com Precedence: bulk Status: RO >I'm fuzzy on this whole "branch" thing. I read the FAQ. I read Per's >tutorial and played with 'cvs rlog' and 'cvs history'. I noticed >there was no logging record specifically for branches. It seems to me >that cvs has to assemble some coherent picture of the graph of >branches in order to operate. You may like to use tkCVS for this: Click a file in the directory viewer, then press the "Log Browse" button to see the graphical view of branches. Either that or select a module, in the module browser, then click "File Browse" and there is a hook to the Log Browser in that window. tkCVS: ftp://ftp.aud.alcatel.com/tcl/code/tkcvs.tar.gz >Other possibilities might be an >interactive browser in tkdot a'la Atria Clearcase. The log browser is interactive -- you can click a version and press "View" to view it, or click left one version, click right another version, then press "Diff". Working in a directory you can also click a branch and press "Merge". What's tkdot? I didn't see it in the tcl FAQ. Del -- -------------------------------+------------------------------------- Del | del@babel.dialix.oz.au -------------------------------+------------------------------------- From info-cvs-request@prep.ai.mit.edu Tue Jul 11 10:48:45 1995 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id KAA27472 for ; Tue, 11 Jul 1995 10:48:40 -0400 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id HAA08844; Tue, 11 Jul 1995 07:40:48 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA25715; Tue, 11 Jul 1995 09:40:39 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA20073; Tue, 11 Jul 1995 08:28:54 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA20068; Tue, 11 Jul 1995 08:28:53 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA25034; Tue, 11 Jul 1995 09:28:50 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id HAA07134; Tue, 11 Jul 1995 07:28:46 -0700 Received: from uu.psi.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA19594; Tue, 11 Jul 95 10:28:38 EDT Received: from flash.UUCP by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA14795 for ; Tue, 11 Jul 95 10:15:32 -0400 Received: from hermes by sgc.com (4.1/SMI-4.1) id AA21811; Tue, 11 Jul 95 10:08:02 EDT Received: from goliath.sgc.com by hermes (4.1/SMI-4.1) id AA01167; Tue, 11 Jul 95 10:08:15 EDT Date: Tue, 11 Jul 95 10:08:15 EDT From: fschmidt@hermes.sgc.com (Fred Schmidt) Message-Id: <9507111408.AA01167@hermes> To: info-cvs@prep.ai.mit.edu Subject: question -- 3rd party software. Status: RO ----- Begin Included Message ----- >From fschmidt Mon Jul 10 18:30:34 1995 To: awasser Subject: question -- 3rd party software. Content-Length: 786 This is a dumb question, but OK, so I get a new version of cvs [or whatever] and I want to install it. Do I just blindly run the install script? Or do I have to "un-install" the old stuff first? Presumably, the install script (for the first time I installed cvs) copied files to /usr/bin, /usr/local/bin, or some similar directory /usr/lib, /usr/local/lib, or some similar directory /usr//man /usr// etc. Presumably, cvs's install script would be smart enough to know that it's upgrading itself.... ....but this does leave the question of how you "uninstall" things in the gnu world? Presumably you'd do this when you run out of disk space and decide that you really never used anyway. Any thoughts or suggestions? Fred ----- End Included Message ----- From info-cvs-request@prep.ai.mit.edu Tue Jul 11 11:15:24 1995 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id LAA07020 for ; Tue, 11 Jul 1995 11:15:18 -0400 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id IAA12991; Tue, 11 Jul 1995 08:08:52 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA27191; Tue, 11 Jul 1995 10:08:45 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA22952; Tue, 11 Jul 1995 09:01:54 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA22947; Tue, 11 Jul 1995 09:01:52 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA26831; Tue, 11 Jul 1995 10:01:46 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id IAA11960; Tue, 11 Jul 1995 08:01:33 -0700 Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA21437; Tue, 11 Jul 95 11:01:28 EDT Received: from monad.armadillo.com (monad.armadillo.com [199.199.0.1]) by monad.armadillo.com (8.6.12/8.6.12) with ESMTP id KAA27846; Tue, 11 Jul 1995 10:02:53 -0500 Message-Id: <199507111502.KAA27846@monad.armadillo.com> From: "david d `zoo' zuhn" Organization: armadillo zoo software -- +1 500 DOS BITES (really) To: fschmidt@hermes.sgc.com (Fred Schmidt) Cc: info-cvs@prep.ai.mit.edu Subject: Re: question -- 3rd party software. In-Reply-To: Your message of "Tue, 11 Jul 1995 10:08:15 EDT." <9507111408.AA01167@hermes> X-Punishment: I will not cut corners X-Face: %!tyIp?0S{n$hE,?."A+J$fssraipD3^/d_NA`Wahj*IIo3,Ct3Rqs;9N7p]\ +n*Ajj#2O~ lwLE\Fw;>)+;3{9Ce65N78mY&jYrn\,;h12=O(aq}JC2`p@v&jM !^"g"+!4z$^Z^b(PMOx\cninzBHwvW2cO.>21\^~8F^H5j%1;L/05\tU8TL8*K c=Ri\/MTnI9d*X!79n;x#.mVNfw"Ys=-,u0bMQ.+}g2]]\lewsO7au{amX>X72 T*[<%33[aoFUfi~lwO3e!ukPCsKg1h,G3/ZuL}7`;P(WP:674J.\kv+x-xY Date: Tue, 11 Jul 1995 10:02:52 -0500 Sender: zoo@armadillo.com Status: RO Software package management is something that's not addressed very well in the Unix world. Most GNU software is supposed to have a 'make uninstall' target in the Makefile, but that means you have to have the source for the old version around, and then configure it just to deinstall it. CVS (and most other GNU packages) don't know when they're updating themselves. You just have to keep track of what's where. You usually don't have to uninstall anything, but sometimes you run into situations where older header files are still around but the current .a file doesn't have the support around. I just keep track (sort of) of what's where, and nuke things by hand when I decide that I need the disk space. I also try to keep things as isolated as possible, but not to the point of using something like Depot. From info-cvs-request@prep.ai.mit.edu Tue Jul 11 08:44:35 1995 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id IAA31077 for ; Tue, 11 Jul 1995 08:44:34 -0400 Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id FAA24008; Tue, 11 Jul 1995 05:35:20 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA21234; Tue, 11 Jul 1995 07:35:14 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14538; Tue, 11 Jul 1995 06:23:04 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14533; Tue, 11 Jul 1995 06:23:02 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA20887; Tue, 11 Jul 1995 07:22:59 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id FAA23167; Tue, 11 Jul 1995 05:22:58 -0700 Received: from mercury.Sun.COM by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13191; Tue, 11 Jul 95 08:22:53 EDT Received: from Central.Sun.COM by mercury.Sun.COM (Sun.COM) id FAA23142; Tue, 11 Jul 1995 05:22:47 -0700 Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA20877; Tue, 11 Jul 1995 07:22:44 -0500 Received: from bilge.Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA14526; Tue, 11 Jul 1995 06:22:44 -0600 Received: from bilge (localhost) by bilge.Central.Sun.COM (5.x/SMI-SVR4) id AA17260; Tue, 11 Jul 1995 06:22:44 -0600 Message-Id: <9507111222.AA17260@bilge.Central.Sun.COM> To: Eric Siegerman Cc: info-cvs@prep.ai.mit.edu Subject: Re: The (political) future of CVS In-Reply-To: Eric Siegerman's message of Fri, 07 Jul 1995 23:27:45 EDT. Date: Tue, 11 Jul 1995 06:22:43 MDT From: Brian Berliner Status: RO > On Fri, 7 Jul 1995 23:27:45 -0400, Eric Siegerman said: > The CVS FAQ (ver. 3.5, as shipped with CVS 1.5), was changed quite > recently, mostly to contain a description of '"Cyclic CVS" (CCVS) that > can handle remote repositories'. It still talks about CCVS as a branch > off from 1.4A2, and gives no indication of any change in this state of > affairs. But CCVS has become CVS 1.5 -- including the remote-repository > code. I'm confused. CVS 1.5 is the "official" CVS release. It is the merger of the CVS 1.4 effort and the Cyclic CVS effort. Personally, I think the "Cyclic" tag needs to be dropped so that people aren't confused. It is my hope that the next version that is shipped (CVS 1.6?) will only mention "Cyclic" when discussing the historical changes of CVS. > What's the state of CCVS as a separate line of development? Is the > intent that Cyclic Software, and Jim Blandy in particular, will become > the official maintainer for "mainline" CVS, automatically rolling into it > any changes made on Cyclic's behalf? Or was the recent merge of > Berliner's and Blandy's code streams a one-time event, from which CCVS > will immediately begin diverging again? Again, I want to see "CCVS" go away. It is just CVS. They are one and the same -- a single line of development. > If the former, is there still any point to separate info-cvs and > cyclic-cvs mailing lists, or should these be merged as well? The folks at cyclic.com have graciously offered to take over the handling of the info-cvs mailing list. This transition should happen in the next week or two. When that happens, I don't think there is a need to have a cyclic-cvs mailing list as well. They should both be merged somehow. > Of course, it may well be simply that the FAQ is out of date and needs a > good going-over. Yep! We do need a volunteer to do this, though. Anyone? -Brian From info-cvs-request@prep.ai.mit.edu Mon Jul 10 13:47:58 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA23948 for ; Mon, 10 Jul 1995 13:47:55 -0400 Received: from Central.Sun.COM (centralmail1.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA19624; Mon, 10 Jul 95 10:35:39 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA20305; Mon, 10 Jul 1995 12:35:31 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23964; Mon, 10 Jul 1995 11:25:37 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23957; Mon, 10 Jul 1995 11:25:35 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA19688; Mon, 10 Jul 1995 12:25:31 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id KAA16263; Mon, 10 Jul 1995 10:25:29 -0700 Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA23544; Mon, 10 Jul 95 13:25:21 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id MAA08865; Mon, 10 Jul 1995 12:24:39 -0500 Date: Mon, 10 Jul 1995 12:24:39 -0500 From: Jim Blandy Message-Id: <199507101724.MAA08865@totoro.cyclic.com> To: sharons@juliet.ll.mit.edu ( Sharon Stanfill ) Cc: info-cvs@prep.ai.mit.edu Subject: cvs 1.5 vs cvs 1.4a2 In-Reply-To: <9507101413.AA00468@silvius> References: <9507101413.AA00468@silvius> Amphibian: eft Status: RO >So, what is the difference between 1.4a2 and 1.5? We >are currently under 1.4a2. What will happen if I replace it >with 1.5? Check out the NEWS file distributed with CVS 1.5. From info-cvs-ownrr@prep.ai.mit.edu Thu Jul 27 15:50:19 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA20755 for ; Thu, 27 Jul 1995 15:50:17 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA19381; Thu, 27 Jul 95 09:08:20 EDT Received: from cs.umn.edu (mail.cs.umn.edu) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA19367; Thu, 27 Jul 95 09:08:06 EDT Received: from twain.cs.umn.edu (twain.cs.umn.edu [128.101.230.63]) by mail.cs.umn.edu (8.6.11/8.6.6) with ESMTP From: bmiller@cs.umn.edu (Brad Miller) Received: by twain.cs.umn.edu (8.6.12) id IAA27834; Thu, 27 Jul 1995 08:07:42 -0500 Date: Thu, 27 Jul 1995 08:07:42 -0500 Message-Id: <199507271307.IAA27834@twain.cs.umn.edu> To: Tom Tromey , bmiller@ai.mit.edu (Brad Miller), info-cvs@prep.ai.mit.edu In-Reply-To: Tom Tromey's message of Wed, 26 Jul 95 16:54:19 MDT Subject: Re: Trashed Log?? References: <199507261304.IAA25910@twain.cs.umn.edu> <9507262254.AA02068@cambric> Status: RO >>>>> "Tom" == Tom Tromey writes: In article <9507262254.AA02068@cambric> Tom Tromey writes: >>>>> "Brad" == Brad Miller writes: Brad> Two years ago a couple of us developed our own version of remote Brad> CVS using email as the underlying transport mechanism. It Brad> worked great, but it was awfully slow compared to this model. Brad> The only benefit to using email, is that it works well for Brad> working with people inside firewalls, and it works pretty well Brad> when you are in a "seldomly connected" networking environment. Brad> Has anyone given any thought about how to make the current Brad> version work in either of those environments? Tom> I'd be curious to hear how this handled conflicts. What we did was use a grapevine like approach to replicate copies of the repository on each of our machines. (This was our quarter project for a grad level distributed systems course) In order to actually commit something to the repository we required that you obtained a token for the file you wanted to commit. Generally, tokens just floated among the users, staying with the last user to successfully commit that file. Once you got the token, you were guaranteed to have the latest version of that file in your repository, and so conflicts could all be handled locally. There were three of us working on this project, each of us had a linux box at home, and we had mail connections between each, and our sun accounts at school. We were able to successfully use the system to maintain our source towards the end of the project. I also used it between home and school to keep other files (.emacs, INBOX, etc) in sync. If you want more info about how we did the token stuff, I can give you a copy of our final report. \Brad ---------------------------------------------------------------------------- Brad Miller | e-mail: bmiller@cs.umn.edu University of Minnesota | phone: (612) 626-8396 Department of Computer Science | www: http://www.cs.umn.edu/users/bmiller EE/CS 5-244 | ---------------------------------------------------------------------------- From info-cvs-ownrr@prep.ai.mit.edu Thu Jul 27 03:51:23 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id DAA11039 for ; Thu, 27 Jul 1995 03:51:23 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA28483; Wed, 26 Jul 95 21:05:45 EDT Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA28461; Wed, 26 Jul 95 21:05:22 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA02027; Wed, 26 Jul 95 18:09:20 PDT Date: Wed, 26 Jul 95 18:09:20 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9507270109.AA02027@sander.sander.cupertino.ca.us> To: info-cvs@prep.ai.mit.edu, letr2@soleil.serma.cea.fr Subject: Re: message from CVS Status: RO letr2@soleil.serma.cea.fr (stagiaire - LETR/IA) wrote: >What does the message from CVS "move away ; it is in the way" mean ? It usually means that CVS is trying to check out a file, but found one by the same name already present in the filesystem. This can happen if two people share their work, and one person copies a file to his CVS directory rather than check it out. When "cvs update" is run later, this message indicates that the file is not under CVS control but wants to be. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-request@prep.ai.mit.edu Wed Jul 5 23:10:12 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA13619 for ; Wed, 5 Jul 1995 23:10:11 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA20583; Tue, 4 Jul 95 14:54:41 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA29941; Tue, 4 Jul 1995 16:54:36 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06615; Tue, 4 Jul 1995 15:45:14 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06611; Tue, 4 Jul 1995 15:45:13 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA29863; Tue, 4 Jul 1995 16:45:10 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id OAA24557; Tue, 4 Jul 1995 14:45:05 -0700 Received: from aeneas.MIT.EDU by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA14615; Tue, 4 Jul 95 17:45:03 EDT Received: from [199.166.211.6] by aeneas.MIT.EDU (5.61/4.7) id AA01380; Tue, 4 Jul 95 17:45:00 EDT Received: by nereide.silverrun.com (5.x/SMI-SVR4) id AA08089; Tue, 4 Jul 1995 17:46:33 -0400 Date: Tue, 4 Jul 1995 17:46:33 -0400 From: alainp@nereide.ai.mit.edu (Alain Pilote) Message-Id: <9507042146.AA08089@nereide.silverrun.com> To: info-cvs@prep.ai.mit.edu Subject: CVS bug on Solaris 2.4 Reply-To: alain.pilote@silverrun.com X-Sun-Charset: ISO-8859-1 Status: RO Hi, I have install cvs1.4A2, on a SPARCstation 5 with Solaris 2.4 compiled whith SPARCompiler C3.0.1, and when I try to "cvs co -A mydir" cvs began to do it and dumped core after the first checkouted file. I have make the following changes that solve this problem. File: getdate.y line: before: after: 902 (void)time(&ftz.time); ftz.time = time(&(ftz.time)); 904 if (! (tm = gmtime (&ftz.time))) if (! (tm = gmtime (&(ftz.time)))) 908 if (! (tm = localtime (&ftz.time))) if (! (tm = localtime (&(ftz.time)))) Regards Alain Pilote | CSA RECHERCHE LTIE Inginieur Logiciel | 100-445 St-Jean Baptiste Software Engenieer | Quibec (Quibec) | Canada G2E 5N7 | til: (418) 877-1717 | 1-800-361-0528 | Fax: (418) 877-2827 E-mail: alain.pilote@silverrun.com From info-cvs-request@prep.ai.mit.edu Mon Jul 3 15:10:57 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA28132 for ; Mon, 3 Jul 1995 15:10:55 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA04989; Mon, 3 Jul 95 12:09:14 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA12994; Mon, 3 Jul 1995 14:09:09 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01819; Mon, 3 Jul 1995 12:55:43 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA01815; Mon, 3 Jul 1995 12:55:42 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA12745; Mon, 3 Jul 1995 13:55:38 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id LAA05254; Mon, 3 Jul 1995 11:55:31 -0700 Received: from sydney.DIALix.oz.au ([192.203.228.34]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA08405; Mon, 3 Jul 95 14:55:22 EDT Received: from babel.UUCP (uucp@localhost) by sydney.DIALix.oz.au (8.6.12/8.6.12/DIALix) with UUCP id EAA29035 for prep.ai.mit.edu!info-cvs; Tue, 4 Jul 1995 04:55:19 +1000 Date: Mon, 3 Jul 95 22:13 EST From: del@babel.dialix.oz.au (Del) Subject: Re: CVS & import scripts To: cvs@babel.dialix.oz.au Message-Id: In-Reply-To: Status: RO >ATTENTION CVS HACKERS: What I'm thinking of doing is adding a "-B" >option to "cvs import" that resets the default branch to the vendor >branch on imported files. This should save at least one pass over the >tree (and eliminate one more use of "cvs admin"). Does this sound OK? I'd like to see this thought out some more. We've tried to implement it here, but: a. Where you have made changes that have not been incorporated by the vendor, you want to keep your own version as the default, rather than the vendor's. b. Where a new vendor version is supplied, often the easiest way to pick this up is with a "merge to head" or "merge to new branch off head". c. Where all of the local changes have been shipped to the vendor and re-incorporated, you almost certainly want the default branch re-set to the vendor branch. cases a. and c. are easily detectable. b. almost always requires manual intervention. This should be selectable on a file-by-file basis (perhaps with a -i (--interactive) option), or done with brute force based on a selectable default. Del -- -------------------------------+------------------------------------- Del | del@babel.dialix.oz.au -------------------------------+------------------------------------- From info-cvs-request@prep.ai.mit.edu Wed Jul 5 23:26:30 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA03688 for ; Wed, 5 Jul 1995 23:26:29 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA12048; Mon, 3 Jul 95 17:24:25 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA16661; Mon, 3 Jul 1995 19:24:19 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA07952; Mon, 3 Jul 1995 18:14:02 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA07948; Mon, 3 Jul 1995 18:14:01 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA16531; Mon, 3 Jul 1995 19:13:56 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id RAA23040; Mon, 3 Jul 1995 17:13:53 -0700 Received: from most.weird.com ([204.92.254.2]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA29084; Mon, 3 Jul 95 20:13:46 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Mon, 3 Jul 95 20:11:05 -0400 (EDT) (/\##/\ Smail3.1.30.12.0 #30.18 built 2-jul-95) Message-Id: Date: Mon, 3 Jul 95 20:11:05 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: del@babel.dialix.oz.au (Del) Cc: cvs@babel.dialix.oz.au, info-cvs@prep.ai.mit.edu Subject: Re: CVS & import scripts In-Reply-To: del@babel.dialix.oz.au's message of "Mon, July 3, 1995 22:13 EST" regarding "Re: CVS & import scripts " id References: Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [[ I apologise in advance if you recieve this message twice. I'm not sure if the mailbox is an alias for , or not, so I'm sending to both places. In the interests of clarity, I'd suggest that users not target mail to a local alias that simply forwards to the main list.... ]] [ On Mon, July 3, 1995 at 22:13 (EST), del@babel.dialix.oz.au wrote: ] > Subject: Re: CVS & import scripts > > >ATTENTION CVS HACKERS: What I'm thinking of doing is adding a "-B" > >option to "cvs import" that resets the default branch to the vendor > >branch on imported files. This should save at least one pass over the > >tree (and eliminate one more use of "cvs admin"). Does this sound OK? > > I'd like to see this thought out some more. We've tried to implement > it here, but: Ah, indeed, though I have thought quite a bit about this on my own... > a. Where you have made changes that have not been incorporated > by the vendor, you want to keep your own version as the default, > rather than the vendor's. Since I always create a patch file consisting of my own local changes since the last vendor release, I can simply apply that and any changes that conflict in some way with the new vendor version will be rejected. I can then manually repair the conflict if indeed they have made un-related changes to the same hunks of code. > b. Where a new vendor version is supplied, often the easiest way > to pick this up is with a "merge to head" or "merge to new > branch off head". Huh?????? The problem I always encountered before I stopped using the "merge" format of catching up to vendor differences was that I couldn't reliably separate my changes from the vendor's changes, esp. on a module-wide basis (i.e. with "cvs rdiff -rVENDOR-LATEST -rMY-LATEST module"). Once I began always reverting to the vendor version, then re-applying my local changes with patch, everything became crystal clear. > c. Where all of the local changes have been shipped to the vendor > and re-incorporated, you almost certainly want the default > branch re-set to the vendor branch. That's what "cvs admin -bVENDOR" does, and what I always do following an import, thus the desire for "cvs import -B". Again the local patches will simply be rejected (or potentially flagged for reversal if patch is particularly fond of them), and thus easily removed. I.e. use of patch(1) to merge local patches into new vendor releases takes care of all the above cases with the least amount of surprise. The only issue I've not yet figured out how to handle, and exists as an issue quite separate from how local changes are merged in existing files, is how to deal with locally added new files that are then adopted by the vendor. My proposed minimalist PDDB would work around this problem neatly, but without changing the way CVS deals with the Attic files, I see no solution. What I currently do is start another completely new module (I actually make sure the old one is released from everywhere and re-name it, thus keeping the current version in a module of the same name). -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From lechner Fri Jun 30 17:19:59 1995 Received: (from lechner@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id RAA23368; Fri, 30 Jun 1995 17:19:59 -0400 From: Bob Lechner Message-Id: <199506302119.RAA23368@jupiter.cs.uml.edu> Subject: Beta test release CVS 1.4.93 now available (FYAction?) To: oneill Date: Fri, 30 Jun 1995 17:19:59 -0400 (EDT) Cc: lechner, buford, grinstein, haim, stu, canning X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1512 Status: RO Brian: I recall your previous remark: I do NOT support alpha-test software. to my earlier message: Message-Id: <199504111305.JAA27795@jupiter.cs.uml.edu> Subject: Re: cvs version 1.4A2 - a possible candidate for jupiter? (ALl cvs-info feedback indicates v1.4 is as reliable as 1.3 - and it works on alpha machines. >From your upgrade message, it looks like my SwEng classes will need to port 20K lines of C/C++/X11/Motif to alpha platforms soon - I hope we have at least a year to do so. We use cvs extensively right now and it should be upgraded also. --------------------------------------------------------------- [New] Forwarded message: >From info-cvs-request@prep.ai.mit.edu Thu Jun 29 02:12:11 1995 Date: Thu, 29 Jun 1995 01:57:23 -0400 From: James Kingdon Message-Id: <199506290557.BAA32377@harvey.cyclic.com> To: info-cvs@prep.ai.mit.edu Subject: Beta test release CVS 1.4.93 now available The differences from the previous release include fixing the fnmatch problem discussed here and miscellaneous other minor fixes. The network problems we had been having with ftp.cyclic.com have been fixed, but just in case I put the release both of the following places: ftp://ftp.cyclic.com/pub/cvs/cvs-1.4.93.tar.gz ftp://alpha.gnu.ai.mit.edu/gnu/cvs-1.4.93.tar.gz As usual, success reports to me (please do this, if things work on a platform and it isn't mentioned in the INSTALL file for a recent (1.4.90 or later) cvs version), and failure reports to cyclic-cvs@cyclic.com. From info-cvs-request@prep.ai.mit.edu Mon Jul 3 09:55:47 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA17612 for ; Mon, 3 Jul 1995 09:55:44 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB11313; Fri, 30 Jun 95 21:14:35 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA11097; Fri, 30 Jun 1995 23:14:29 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06274; Fri, 30 Jun 1995 22:12:31 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA06269; Fri, 30 Jun 1995 22:12:30 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA10776; Fri, 30 Jun 1995 23:12:26 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id VAA22878; Fri, 30 Jun 1995 21:12:17 -0700 Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA17325; Sat, 1 Jul 95 00:12:11 EDT Received: by most.weird.com via sendmail with stdio for info-cvs@prep.ai.mit.edu (/\##/\ Smail3.1.29.5.0.1 #29.2 built 4-apr-95) id ; Sat, 1 Jul 95 00:11 EDT Message-Id: Date: Sat, 1 Jul 95 00:11 EDT From: woods@most.weird.com (Greg A. Woods) To: "Simon J. Gerraty" Cc: current-users@netbsd.org, info-cvs@prep.ai.mit.edu Subject: Re: CVS & import scripts In-Reply-To: Simon J. Gerraty's message of "Sat, June 17, 1995 06:01:12 -0400" regarding "Re: CVS & import scripts " id <199506171001.UAA11173@zen.void.oz.au> References: <199506170712.CAA15167@slip-2-4.ots.utexas.edu> <199506171001.UAA11173@zen.void.oz.au> Reply-To: woods@planix.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Sat, June 17, 1995 at 06:01:12 (-0400), Simon J. Gerraty wrote: ] > To: current-users@NetBSD.ORG > Subject: Re: CVS & import scripts > >[in some scripts posted as a shar file....] > XI use "-I! " as otherise some files that you need (like > Xbin/csh/USD.doc/csh.a) will be ignored.. The space after the ! is > Xneeded. Hmmm.... Which version of CVS are you using, and which patches have you applied? Certainly CVS-1.4A2 doesn't have this problem, assuming you use the correct syntax: -I ! I.e. if you put a space between the option letter and the option argument is necessary, you won't need a trailing space. (Yes, I agree that it's terribly confusing to have CVS conform to POSIX command-line argument syntax, *except* where RCS options "show through". > Xcd /d2/tmp > Xcvs checkout -jNetBSD:yesterday -jNetBSD usr.src > /tmp/merge.out 2>&1 > X > XYou can then go find all the files with conflicts. > XEither grep '^C' /tmp/merge.out or find usr.src -name '.#*' -print > XGo edit them to resolce the conflicts. This is usually obvious. > X > XWhen happy. > X > Xcd /d2/tmp/usr.src > Xcvs commit -m"merged local changes with NetBSD-950508" > Xcd .. > Xrm -rf usr.src I find it much safer and easier to use tags and the patch(1) command. I've posted something similar to this procedure in the past to the info-cvs mailing list, but I don't think it's in the FAQ or documentation (yet): # assume last time round the vendor tag was "NetBSD-950427" # and I ftp'd the 950603 tar files of -current # tag the current state of local stuff.... cd /usr/src # my current working sources checked out cvs tag local-950427 . cd /ftp.d/NetBSD-current/tar_files/usr/src cvs import -I ! 'netbsd-current as of 950603' NetBSD NetBSD NetBSD-950603 # this step is a bit heavy, and only necessary if you want to be # really pedantic and only move the default branch back on true # current files (i.e. not on locally modified but out-dated files) cd /var/tmp cvs co -r NetBSD-950603 NetBSD cd NetBSD cvs admin -bNetBSD . >/dev/null # WARNING: no space after the '-b' cd .. cvs release -d NetBSD # # OTHERWISE you can just do this: cd /usr/src cvs admin -bNetBSD . >/dev/null # WARNING: no space after the '-b' # now update the working tree to 950603 -current cd /usr/src cvs update -A -ko . | tee ../update-950603 2>&1 # then make a patch file of the local changes.... cd /usr cvs rdiff -c -ko -r NetBSD-950427 -r local-950427 NetBSD > patch-950427 # and re-apply it/them cd src patch -p2 -s < ../patch-950427 # if there are any conflicts.... find . -name '*.rej' -print > ../patch-950427.rejects vi `cat ../patch-950427.rejects` # you get the idea.... cvs commit . # etc.... # and for good measure cvs tag post-950603 . I find this far safer than the rcsmerge done by "cvs co -jXXX:yesterday -jXXX module", since you get all the conflicts in a separate file, not merged into the working file. I also trust patch(1) more for some reason, though I'm not sure why that is.... > XFinally, you should occasionally make sure you remove old files. There's a much easier and safer way to do this. Just before you apply the local patches (or at least before they are committed), do this: cd /usr/src # the "-n" is obviously *very* important! cvs -nq tag -F NetBSD-950603 . | awk '{print $2}' > ../removed-950603 for $file in `cat ../removed-950603` ; do if [ `cvs rlog -h $file | fgrep branch:` = 'branch: 1.1.1' ] ; then cvs rm -f $file echo $file >> ../really-removed-950603 fi done cvs ci -m 'removed prior to NetBSD-950603' `cat ../really-removed-950603` I.e. this will out-date files which didn't get the most recent vendor release tag, so long as they have a vendor branch. If they don't have a vendor branch, they are locally added files. NOTE: I've not yet done this on the NetBSD tree, though I've done it several times on CVS, BIND, Smail-3, and a few smaller things. The one flaw I've found in this approach is that if the vendor adds a file you've previously added locally it's impossible to keep the old local revisions, even with Cyclic-CVS' "death" support. You have to completely remove the old local ",v" file from the repository before you do the import with the vendor's file. ATTENTION CVS HACKERS: What I'm thinking of doing is adding a "-B" option to "cvs import" that resets the default branch to the vendor branch on imported files. This should save at least one pass over the tree (and eliminate one more use of "cvs admin"). Does this sound OK? -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-request@prep.ai.mit.edu Tue Jun 27 14:12:40 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA07301 for ; Tue, 27 Jun 1995 14:12:39 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14976; Tue, 27 Jun 95 11:01:26 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA15950; Tue, 27 Jun 1995 13:01:18 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24699; Tue, 27 Jun 1995 11:47:57 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA24695; Tue, 27 Jun 1995 11:47:56 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA15136; Tue, 27 Jun 1995 12:47:52 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id KAA16825; Tue, 27 Jun 1995 10:47:51 -0700 Received: from kelvin.aspentec.com by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA21842; Tue, 27 Jun 95 13:47:49 EDT Received: from yoda.aspentec.com by kelvin.aspentec.com (MX V4.1 AXP) with SMTP; Tue, 27 Jun 1995 12:11:38 EDT Date: Tue, 27 Jun 1995 12:10:26 -0400 (EDT) From: Nilesh Patel/ATHQ To: info-cvs@prep.ai.mit.edu Subject: Aegis: More info?? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO Hi, I was wondering from where one can obtain more information about the Aegis environment. The CVS FAQ says the following. Any starting pointers are greatly appreciated. Nilesh ====================================================================== 1C.6 How does CVS differ from Aegis? Aegis appears to be a policy-setting tool that allows you to use other sub-programs (make, RCS, etc.) to implement pieces of the imposed policy. The initial document seems to say that most Unix tools are inadequate for use under Aegis. It is not really similar to CVS and requires a different mindset. [[Need more info here.]] ======================================================================= From info-cvs-request@prep.ai.mit.edu Tue Jun 27 14:23:45 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA00752 for ; Tue, 27 Jun 1995 14:23:44 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA17269; Tue, 27 Jun 95 11:18:12 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA17327; Tue, 27 Jun 1995 13:18:02 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA25836; Tue, 27 Jun 1995 12:12:35 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA25832; Tue, 27 Jun 1995 12:12:34 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA16879; Tue, 27 Jun 1995 13:12:25 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id LAA20451; Tue, 27 Jun 1995 11:12:25 -0700 Received: from teloseng.com (frog.teloseng.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA23471; Tue, 27 Jun 95 14:12:19 EDT Received: from baloo.teloseng.com by teloseng.com with SMTP (5.65/1.2-eef) id AA14480; Tue, 27 Jun 95 11:12:14 -0700 Received: by baloo.teloseng.com (5.65) id AA11590; Tue, 27 Jun 95 11:12:12 -0700 Message-Id: <9506271812.AA11590@baloo.teloseng.com> From: wolfe@teloseng.com (Peter Wolfe) To: nilesh@aspentec.com, info-cvs@prep.ai.mit.edu Subject: Aegis: More info?? X-Mailer: ScoMail 1.0 Date: Tue, 27 Jun 1995 11:12:11 -0700 (PDT) Status: RO > > I was wondering from where one can obtain more information > about the Aegis environment. The CVS FAQ says the following. >From the Configuration Management Frequently Asked Questions: Aegis is available via anonymous FTP to Northern Arizona University at: Host: ftp.nau.edu (134.114.64.90) Directory: /pub/Aegis File: aegis.2.2.README A blurb about it File: aegis.2.2.tar.gz The complete source File: aegis.2.2.ps.gz The User Guide --- Peter Wolfe wolfe@teloseng.com Telos Engineering Limited From info-cvs-request@prep.ai.mit.edu Mon Jun 26 19:23:53 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA07436 for ; Mon, 26 Jun 1995 19:23:51 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA26266; Mon, 26 Jun 95 16:16:05 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA15134; Mon, 26 Jun 1995 18:15:58 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA16499; Mon, 26 Jun 1995 16:59:53 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA16495; Mon, 26 Jun 1995 16:59:52 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA14253; Mon, 26 Jun 1995 17:59:31 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id PAA07460; Mon, 26 Jun 1995 15:59:22 -0700 Received: from relay3.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA02437; Mon, 26 Jun 95 18:59:17 EDT Received: from uucp6.UU.NET by relay3.UU.NET with SMTP id QQyvvv09870; Mon, 26 Jun 1995 18:59:15 -0400 Received: from almserv.UUCP by uucp6.UU.NET with UUCP/RMAIL ; Mon, 26 Jun 1995 18:59:15 -0400 Received: from mammoth.fnma.com by fnma.COM (4.1/SMI-4.1) id AA10166; Mon, 26 Jun 95 18:54:53 EDT Received: by mammoth.fnma.com (5.0/SMI-SVR4) id AA10134; Mon, 26 Jun 1995 18:54:51 -0400 Date: Mon, 26 Jun 1995 18:54:51 -0400 From: sxupjb@fnma.com (Phillip Beiler) Message-Id: <9506262254.AA10134@mammoth.fnma.com> To: uunet!cs.purdue.edu!rcs-bugs@uunet.uu.net Cc: uunet!prep.ai.mit.edu!info-cvs@uunet.uu.net Subject: RCS 5.7 released In-Reply-To: <9506161935.AA01052@light.twinsun.com> References: <9506161935.AA01052@light.twinsun.com> Organization: Fannie Mae Status: RO NeXT Dude... When you get a chance.... Thanks Phil Paul Eggert writes: > RCS version 5.7 is now available as > . > Most changes are to fix bugs and improve portability. > RCS now conforms to GNU configuration standards and to Posix 1003.1b-1993. > > Here is a brief summary of user-visible changes since RCS 5.6. > > New options: > `-kb' supports binary files. > `-T' preserves the modification time of RCS files. > `-V' prints the version number. > `-zLT' causes RCS to use local time in working files and logs. > `rcsclean -n' outputs what rcsclean would do, without actually doing it. > `rlog -N' omits symbolic names. > There is a new keyword `Name'. > Inserted log lines now have the same prefix as the preceding `$Log' line. > > Please report problems and direct all questions to: > > rcs-bugs@cs.purdue.edu -- ----------------------------------------------------------------------------- Phil Beiler Federal National Mortgage Association pbeiler@fnma.com Advanced Technologies (202) 752-3667 Washington, D.C. 20016 ----------------------------------------------------------------------------- From info-cvs-request@prep.ai.mit.edu Thu Jul 6 13:47:00 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA03334 for ; Thu, 6 Jul 1995 13:46:54 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA15479; Thu, 6 Jul 95 10:34:52 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA02690; Thu, 6 Jul 1995 12:34:45 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA22253; Thu, 6 Jul 1995 11:28:10 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA22249; Thu, 6 Jul 1995 11:28:09 -0600 Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA02376; Thu, 6 Jul 1995 12:28:03 -0500 Received: from life.ai.mit.edu by venus.Sun.COM (Sun.COM) id KAA26533; Thu, 6 Jul 1995 10:28:01 -0700 Received: from tss.ca by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA09721; Thu, 6 Jul 95 13:26:39 EDT Received: from ganglion (ganglion.tss.ca) by tss.ca with SMTP id AA04022 (5.65c/IDA-1.4.4 for info-cvs@prep.ai.mit.edu); Thu, 6 Jul 1995 13:27:23 -0400 Received: by ganglion (1.38.193.4/16.2) id AA01187; Thu, 6 Jul 1995 13:26:12 -0400 Date: Thu, 6 Jul 1995 13:10:12 +0500 (EST) From: Brian Onn Sender: Brian Onn Reply-To: Brian Onn Subject: questions on branching To: info-cvs@prep.ai.mit.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Status: RO This is my first attempt at using branches, and am seeing some unusual behaviour. I have a couple of files that I added to a branch, then did a cvs add and cvs commit on each of them. When I did a cvs update on my main trunk copy, these new files (from the branch) were updated from the repository and are now a part of my working copy of the main trunk. This seemed wrong, so I read the FAQ, and 3A.2 and 3A.3 says that files added to a branch should have been placed in the Attic. They aren't, they are in the main area of the repository. In my branch working copy, a cvs status shows that all the files that originally branched from the trunk have a sticky tag associated with them, but that the new files have no sticky tag. Is this why they didn't go into the Attic like they should have? Am I supposed to run cvs tag -b on these new files before doing cvs add? Since other developers are working on the trunk, I don't want these files to appear when they do cvs update. Thanks, Brian. --- Brian A. Onn CTS Development Engineer, Teknekron Software Systems Toronto, Ontario, Canada. From info-cvs-request@prep.ai.mit.edu Thu Jul 6 04:22:00 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA21532 for ; Thu, 6 Jul 1995 04:21:59 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA14006; Thu, 6 Jul 95 01:10:05 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA16392; Thu, 6 Jul 1995 03:09:58 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29222; Thu, 6 Jul 1995 01:32:39 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA29218; Thu, 6 Jul 1995 01:32:38 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA13966; Thu, 6 Jul 1995 02:32:30 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id AAA21038; Thu, 6 Jul 1995 00:32:28 -0700 From: gtornblo@senet.abb.se Received: from snex11.senet.abb.se ([138.221.106.11]) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA15366; Thu, 6 Jul 95 03:32:19 EDT Received: from localhost by snex11.senet.abb.se; (5.65/1.1.8.2/03Oct94-0154PM) id AA03522; Thu, 6 Jul 1995 09:36:01 +0200 Message-Id: <9507060736.AA03522@snex11.senet.abb.se> To: info-cvs@prep.ai.mit.edu Cc: gtornblo@senet.abb.se Subject: Why do I get a sticky conflict ? Date: Thu, 06 Jul 95 09:35:58 +0200 X-Mts: smtp Status: RO When two developers (A and B) are woking on the same branch, CVS will refuse to commit a file revision made by developer A if developer B has committed a revision after developer A's last commit Example: file a.c revision 1.1.2.3 checked out by A and B developer A changes line 3 from "C " to "xxxC" then commits the file, creating revision 1.1.2.4 developer B changes line 5 from "HIST" to "yyyHIST" then tries to commit but is blocked because the file is not up to date Now developer B runs cvs update and he gets the normal printout telling that merge is made between revision 1.1.2.3 and 1.1.2.4 but for some strange reason this result in a sticky conflict looking like this: <<<<<< HIST ====== yyyHIST >>>>>> 1.1.2.4 why ? This kind of conflicts should occur only is A and B modifies the same line. (as described in CVS FAQ section 3P.6) Did anyone else experience this behaviour ? I use CVS 1.4A2 on a DEC alpha running OSF/1 version 3.0 Thanks Gunnar Tornblom From info-cvs-request@prep.ai.mit.edu Thu Jul 6 02:41:29 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id CAA17855 for ; Thu, 6 Jul 1995 02:41:28 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA07829; Wed, 5 Jul 95 23:34:43 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA10010; Thu, 6 Jul 1995 01:34:36 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27620; Thu, 6 Jul 1995 00:18:01 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA27616; Thu, 6 Jul 1995 00:18:00 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA08852; Thu, 6 Jul 1995 01:17:56 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id XAA16355; Wed, 5 Jul 1995 23:17:47 -0700 Received: from xenon.daimi.aau.dk by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA13703; Thu, 6 Jul 95 02:17:39 EDT Received: (from lynbech@localhost) by xenon.daimi.aau.dk (8.6.11/8.6.11) id GAA06933; Thu, 6 Jul 1995 06:16:29 GMT Date: Thu, 6 Jul 1995 06:16:29 GMT From: Christian Lynbech Message-Id: <199507060616.GAA06933@xenon.daimi.aau.dk> To: yotam_medini@tmai.com (Yotam Medini) Cc: info-cvs@prep.ai.mit.edu Subject: pcl-cvs needs elib 0.07, but I see only 0.06 In-Reply-To: <9507060053.AA28093@mailserver.tmai.com> References: <9507060053.AA28093@mailserver.tmai.com> Comments: Hyperbole mail buttons accepted, v03.19.01. Status: RO Try the site `ftp.lysator.liu.se' in `pub/emacs'. ------------------------------------------------------------------------------ Christian Lynbech (R0.33) | Hit the philistines three times over the phone: +45 8942 3217 | head with the Elisp reference manual. email: lynbech@daimi.aau.dk | - petonic@hal.com (Michael A. Petonic) ------------------------------------------------------------------------------ From info-cvs-request@prep.ai.mit.edu Tue Jun 27 13:56:32 1995 Received: from Sun.COM (Sun.COM [192.9.9.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA22234 for ; Tue, 27 Jun 1995 13:56:26 -0400 Received: from Central.Sun.COM (central.Central.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AB12863; Tue, 27 Jun 95 10:46:36 PDT Received: from rmtc.Central.Sun.COM by Central.Sun.COM (5.x/SMI-5.3) id AA15007; Tue, 27 Jun 1995 12:46:20 -0500 Received: by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23408; Tue, 27 Jun 1995 11:30:13 -0600 Received: from Central.Sun.COM by rmtc.Central.Sun.COM (5.x/SMI-SVR4) id AA23404; Tue, 27 Jun 1995 11:30:11 -0600 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Central.Sun.COM (5.x/SMI-5.3) id AA13828; Tue, 27 Jun 1995 12:30:07 -0500 Received: from life.ai.mit.edu by mercury.Sun.COM (Sun.COM) id KAA08018; Tue, 27 Jun 1995 10:30:07 -0700 Received: from devnull (devnull.mpd.tandem.com) by life.ai.mit.edu (4.1/AI-4.10) for info-cvs@rmtc.central.sun.com id AA21250; Tue, 27 Jun 95 13:30:03 EDT Received: from rolex.mpd.tandem.com by devnull (8.6.8/8.6.6) id MAA25956; Tue, 27 Jun 1995 12:29:51 -0500 Received: from infan (infan.mpd.tandem.com) by rolex.mpd.tandem.com (4.1/TSS2.1) id AA22181; Tue, 27 Jun 95 12:29:59 CDT Received: by infan (940816.SGI.8.6.9/930416.SGI.AUTO) for info-cvs@prep.ai.mit.edu id MAA11944; Tue, 27 Jun 1995 12:29:34 -0700 From: infan@mpd.tandem.com (Infan Cheong) Message-Id: <199506271929.MAA11944@infan> Subject: duplicate key and NULL value problems - SOLVED To: info-cvs@prep.ai.mit.edu Date: Tue, 27 Jun 1995 12:29:32 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: RO Hi. I sent a message to this mailing list last week asking for help on how to solve the "duplicate key" and "NULL value" problems from my modules file. After looking into the CVS source code, I found out why cvs was complaining about my modules file. cvs was written in such a way that no spaces are allowed after the line continuation indicator "\" and after the last key on a multiple line aliases definition. My modules file passed through mkmodules without any complain after the white spaces were deleted. Thank you very much for attention. Infan Cheong (Tandem Computers) From info-cvs-ownrr@prep.ai.mit.edu Thu Jul 27 18:03:30 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA27639 for ; Thu, 27 Jul 1995 18:03:29 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA22021; Thu, 27 Jul 95 09:54:43 EDT Received: from noao.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA22014; Thu, 27 Jul 95 09:54:33 EDT Received: from ctiole (ctiole.ctio.noao.edu) by noao.edu (4.1/SAG-Noao.G102) id AA24169; Thu, 27 Jul 95 06:53:31 MST; for info-cvs@prep.ai.mit.edu Received: by ctiole (4.1/JBH.4) id AA01243; Thu, 27 Jul 95 09:53:26 CST Date: Thu, 27 Jul 95 09:53:26 CST From: webb@ctiole.ctio.noao.edu (gary webb x240) Message-Id: <9507271353.AA01243@ctiole> To: tammo+@cmu.edu, info-cvs@prep.ai.mit.edu Subject: cvs'ing binaries Status: RO Tammo Spalink writes > > Hi, this is probably a simple question... > > I am running cvs on IRIX 5.3, and I am trying to put a library file (a > .a file) into the cvs database. I am having a problem however when I > check out a new copy of it some header information on the file is > screwed up or somethign and I get a "bad magic number" error. I also > tried to do this with a .tar file and it failed with a bad black count > or somthing similar. Is there some prcess CVS is using to store the > files that could be scambling some of these fields? > > Thanks, > Tammo > Sounds like you forgot to add a -ko switch. Try cvs update -ko .a in the directory with the corrupted file, and see if it fixes it. Under rev 1.5 there is a -kb switch as well, but since I am still using 1.4A2, I cannot tell you more about that. Gary Lee Webb From info-cvs-ownrr@prep.ai.mit.edu Thu Jul 27 23:01:16 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA05383 for ; Thu, 27 Jul 1995 23:01:11 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA27444; Thu, 27 Jul 95 20:09:44 EDT Received: from metro.ucc.su.OZ.AU by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA27422; Thu, 27 Jul 95 20:09:14 EDT Received: from mama.research.canon.oz.au by metro.ucc.su.OZ.AU with MHSnet id AA28449 (5.65c/IDA-1.4.4 for info-cvs@prep.ai.mit.edu); Fri, 28 Jul 1995 10:08:18 +1000 Received: from miles.research.canon.oz.au (miles.research.canon.com.au) by mama.research.canon.oz.au with SMTP id AA07939 (5.65c8/IDA-1.5); Fri, 28 Jul 1995 10:01:40 +1000 Received: by miles.research.canon.oz.au (NX5.67d/NX3.0S) id AA18409; Fri, 28 Jul 95 10:01:38 +1000 From: Graham Stoney Message-Id: <9507280001.AA18409@miles.research.canon.oz.au> Subject: Re: cvs'ing binaries To: webb@ctiole.ctio.noao.edu (gary webb x240) Date: Fri, 28 Jul 1995 10:01:37 +1000 (GMT+1000) Cc: tammo+@cmu.edu, info-cvs@prep.ai.mit.edu In-Reply-To: <9507271353.AA01243@ctiole> from "gary webb x240" at Jul 27, 95 09:53:26 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1635 Status: RO Tammo Spalink writes > Hi, this is probably a simple question... > > I am running cvs on IRIX 5.3, and I am trying to put a library file (a > .a file) into the cvs database. I am having a problem however when I > check out a new copy of it some header information on the file is > screwed up or somethign and I get a "bad magic number" error. I also > tried to do this with a .tar file and it failed with a bad black count > or somthing similar. Is there some prcess CVS is using to store the > files that could be scambling some of these fields? gary webb x240 writes: > Sounds like you forgot to add a -ko switch. Try > > cvs update -ko .a > > in the directory with the corrupted file, and see if it fixes it. > Under rev 1.5 there is a -kb switch as well, but since I am still using > 1.4A2, I cannot tell you more about that. Actually, since the file is a binary, it would be better to set the default keyword substitution so that other people who check it out don't need to bother with the -ko (or -kb, if you're using cvs 1.5 and rcs 5.7, which is better since it will prevent merges happening if two people try to modify it at once). In other words: cvs rcs -ko .a That won't change the already checked out copy though; for that, do the update too, as Gary suggests. It would be nice if rcs could determine automatically when a file is "binary" and set the default keyword substitution accordingly; something along the lines of perl's -B file test operator would probably be OK. It's not foolproof, but would certainly save a great many rcs and cvs users from a lot of grief. regards, Graham From info-cvs-ownrr@prep.ai.mit.edu Thu Jul 27 22:37:19 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA06130 for ; Thu, 27 Jul 1995 22:37:18 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA26347; Thu, 27 Jul 95 19:49:11 EDT Received: from motgate.mot.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA26340; Thu, 27 Jul 95 19:48:58 EDT Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.6.11/8.6.10/MOT-3.7) with ESMTP id SAA26597 for ; Thu, 27 Jul 1995 18:48:57 -0500 Received: from motsat.sat.mot.com (motsat.sat.mot.com [192.111.236.254]) by pobox.mot.com (8.6.11/8.6.10/MOT-3.7) with SMTP id SAA13714 for ; Thu, 27 Jul 1995 18:48:56 -0500 Received: from pluto.sat.mot.com by motsat.sat.mot.com with SMTP id AA26789 (5.65c/IDA-1.4.4 for ); Thu, 27 Jul 1995 16:50:36 -0700 Received: by pluto.sat.mot.com (5.x/SMI-SVR4) id AA11873; Thu, 27 Jul 1995 16:50:13 -0700 Date: Thu, 27 Jul 1995 16:50:13 -0700 From: goodse_j@pluto.sat.mot.com (John Goodsen) Message-Id: <9507272350.AA11873@pluto.sat.mot.com> To: Johnny Tang Cc: info-cvs@prep.ai.mit.edu Subject: cvs'ing binaries (fwd) In-Reply-To: <9507271402.AA22297@life.ai.mit.edu> References: <9507271402.AA22297@life.ai.mit.edu> Status: RO > > > > > Hi, this is probably a simple question... > > > > I am running cvs on IRIX 5.3, and I am trying to put a library file (a > > .a file) into the cvs database. I am having a problem however when I > > check out a new copy of it some header information on the file is > > screwed up or somethign and I get a "bad magic number" error. I also > > tried to do this with a .tar file and it failed with a bad black count > > or somthing similar. Is there some prcess CVS is using to store the > > files that could be scambling some of these fields? > > On solaris 2.4, we had problems with binaries files in the repository until I recompiled rcs to use the proper DIFFLAGS = -an by default, so that it would handle binaries. Now cvs 1.5 is working just fine with binaries. hope this helps -- John Goodsen Currently On-Site: Rapid Engineering Specialist Motorola Satellite Communications The Dalmatian Group, Inc. Chandler, AZ jgoodsen@dalmatian.com Today's Weather: Extremely Hotly http://www.indirect.com/www/radsoft/jgoodsen.html From info-cvs-ownrr@prep.ai.mit.edu Mon Jul 31 11:34:39 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA17506 for ; Mon, 31 Jul 1995 11:34:38 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA08120; Mon, 31 Jul 95 05:43:52 EDT Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA08111; Mon, 31 Jul 95 05:43:36 EDT Received: (from zoo@localhost) by monad.armadillo.com (8.6.12/8.6.12) id EAA27193 for info-cvs@prep.ai.mit.edu; Mon, 31 Jul 1995 04:45:03 -0500 Date: Mon, 31 Jul 1995 04:45:03 -0500 From: "david d `zoo' zuhn" Message-Id: <199507310945.EAA27193@monad.armadillo.com> To: info-cvs@prep.ai.mit.edu Subject: info-cvs mini-faq (Weekly posting, last modified Mon Jul 24 1995) Status: RO This is an automatically posted mini-FAQ. The "Subject:" header will not change unless the contents of the mini-FAQ change, which I hope will be infrequently. In any case, the format of the Subject will not change. The following questions are answered in this mini-FAQ. Please check to see if your question/concern/problem is answered here before sending mail to the list at large. What is CVS? Where do I find the real full-sized FAQ? What is this mailing list for? What is the current version of CVS and where is it? What does "Too many arguments!" mean? What other sources of information are available? How do I unsubscribe to this list? If you have any questions or comments about this mini-FAQ, please direct them to me and not to the list at large. My email address is 'zoo@armadillo.com'. Please include this $Revision: 1.6 $ number with any comments 1. What is CVS? "CVS" is an acronym for the "Concurrent Versions System". CVS is a "Source Control" or "Revision Control" tool designed to keep track of source changes made by groups of developers working on the same files, allowing them to stay in sync with each other as each individual chooses. 2. Where do I find the real full-sized FAQ? By anonymous ftp to ftp://ftp.odi.com/pub/users/dgg/FAQ.gz Via the World Wide Web at http://www.winternet.com/~zoo/cvs/FAQ.txt If you're new to CVS, or haven't read it lately, please read this FAQ. Though the information in it is still nearly all relevant, David Grubbs (dgg@odi.com) is in the process of catching up on recent 1.5 (and soon 1.6) changes. Suggestions for addition/modification are welcome. 3. What is this mailing list for? This list is for discussion about installing and using CVS. Talk about work on CVS is also welcome, as are enhancements and bugfixes. Bug reports should go to bug-cvs@prep.ai.mit.edu (or use the cvsbug script in the newer CVS release). 4. What is the current version of CVS and where is it? The current officially released version is 1.5 at ftp://prep.ai.mit.edu/pub/gnu/cvs-1.5.tar.gz as well as the usual GNU archive mirror sites. 5. What does "Too many arguments!" mean? CVS 1.4a2 has a cvsinit script that incorrectly sets up the loginfo file, but only if perl is available. If you don't have perl, you won't see this message (I don't have perl installed, which is why my testing didn't catch this bug). If you do have perl, you can apply the patch at the end of this message to your 1.4a2 distribution, or make the same change to your installed loginfo file (add a -f between %s and $CVSROOT). 6. What other sources of information are available? First off, the FAQ (see #2 above). Several WWW sites have information about CVS: http://www.winternet.com/~zoo/cvs/ http://www.loria.fr/~molli/cvs-index.html 7. How do I unsubscribe to this list? Please do NOT send a message to the entire list asking to unsubscribe. You'll only succeed in sending the message to hundreds of people who can't do anything about it. Send mail to info-cvs-request@prep.ai.mit.edu, and ask to be removed. The best way would be to include the text: unsubscribe info-cvs While someday the list may be automated, it is currently handled manually, and Brian is a very busy person. So it might take a while for things to happen. Please don't get frustrated and send mail to the list as a whole. Only Brian can remove you from the list. Appendices: I. The loginfo patch for 1.4a2 *** scratch/loginfo Sun Feb 12 19:51:25 1995 --- examples/loginfo Sun Feb 12 19:51:46 1995 *************** *** 18,20 **** # in addition to the first matching regex or DEFAULT. # ! DEFAULT $CVSROOT/CVSROOT/log.pl %s $CVSROOT/CVSROOT/commitlog --- 18,20 ---- # in addition to the first matching regex or DEFAULT. # ! DEFAULT $CVSROOT/CVSROOT/log.pl %s -f $CVSROOT/CVSROOT/commitlog From info-cvs-ownrr@prep.ai.mit.edu Sat Jul 29 10:20:59 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA21587 for ; Sat, 29 Jul 1995 10:20:54 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA05615; Thu, 27 Jul 95 23:16:10 EDT Received: from metro.ucc.su.OZ.AU by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA05510; Thu, 27 Jul 95 23:12:55 EDT Received: by metro.ucc.su.OZ.AU id AA17883 (5.65c/IDA-1.4.4 for info-cvs@prep.ai.mit.edu); Fri, 28 Jul 1995 13:12:50 +1000 Received: from csdc_12.toshiba.oz.au by toshiba.tic.oz.au (4.1) id AA13648; Fri, 28 Jul 95 12:01:20 EST Received: by csdc_12.toshiba.oz.au (5.0/SMI-SVR4) id AA00628; Fri, 28 Jul 1995 13:12:54 --1000 Date: Fri, 28 Jul 1995 13:12:54 --1000 From: johnc%mailhost@toshiba.tic.oz.au (John Creasey) Message-Id: <9507280312.AA00628@csdc_12.toshiba.oz.au> To: info-cvs@prep.ai.mit.edu Subject: Can you make cvs do locking X-Sun-Charset: US-ASCII Content-Length: 511 Status: RO We also use cvs for binary files by enabling the -ko option. Unfortunately we regularly come unstuck when two people edit the same version of the file. Is there a way we can make cvs do locking for binary files only? regards, John Creasey. ------------------------------------------------------------------------- John Creasey (johnc@toshiba.tic.oz.au) Phone: 61-2-393-1755 Toshiba International Corporation Pty Ltd Fax : 61-2-418-7791 Private Bag 29, Lane Cove, NSW 2066, Australia From info-cvs-ownrr@prep.ai.mit.edu Sat Jul 29 10:23:55 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA20545 for ; Sat, 29 Jul 1995 10:23:54 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA21804; Fri, 28 Jul 95 07:21:42 EDT Received: from dayton.saic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA21797; Fri, 28 Jul 95 07:21:30 EDT Received: from llcoolj.dayton.saic.com.noname (llcoolj.dayton.SAIC.COM [139.121.26.6]) by dayton.saic.com (8.6.9/8.6.5) with SMTP id HAA07987 for ; Fri, 28 Jul 1995 07:22:47 -0400 Received: by llcoolj.dayton.saic.com.noname (4.1/SMI-4.1) id AA24344; Fri, 28 Jul 95 07:19:06 EDT Date: Fri, 28 Jul 95 07:19:06 EDT Message-Id: <9507281119.AA24344@llcoolj.dayton.saic.com.noname> From: Mike Sutton To: info-cvs@prep.ai.mit.edu Subject: cvs'ing soft links Status: RO I resolved hadling symblolic links by creating two files. One contains records with the real file name and the link name. The second file is a shell script that reads the first and creates the links. Mike Sutton | "I went mad for awhile, did me SAIC | no end of good" -Ford Prefect Beavercreek, OH | Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 2 03:58:11 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id DAA07759 for ; Wed, 2 Aug 1995 03:58:10 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA08797; Tue, 1 Aug 95 16:40:40 EDT Received: from europe.std.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA08518; Tue, 1 Aug 95 16:35:44 EDT Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id QAA19338; Tue, 1 Aug 1995 16:35:27 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA12167; Tue, 1 Aug 1995 16:35:22 -0400 Date: Tue, 1 Aug 1995 16:35:22 -0400 From: bmb@world.std.com (Brian Bartholomew) Message-Id: <199508012035.AA12167@world.std.com> To: info-cvs@prep.ai.mit.edu, north@research.att.com, rouilj@cs.umb.edu, ceder@signum.se Subject: Re: How can I extract the graph of version ancestory from CVS? Status: RO (Note: I am not on the info-cvs mailing list.) I have more informed questions to ask about cvs's branching now. These questions are predicated on the following statements being true. If they aren't true, please tell me: You can check out any arbitrary non-empty set of files, perhaps using multiple cvs co commands. You can tag any set of files you can check out. The set of files marked by two tags need not intersect. Tags need have no relation to each other. Questions: I type a 'cvs co' command, make modifications, get interrupted, and forget what I had checked out. How can I tell what I started with in my sandbox? The answer I'm looking for is a minimal set of checkout commands expressed with tags instead of revision numbers where possible like 'cvs co -r kernel1' or 'cvs co -r HEAD as of 19950401'. I am keeping track of 1,000 files of kernel source code. I have a vendor branch that I imported the code into that I commit vendor patches onto from time to time. I committed screend and jukebox changes separately onto the main branch, and tagged them. Then I merged in the vendor patches to the main branch, producing a working kernel, which I tagged. Suppose I get a new kernel patch but I've forgotten the details of where to apply it. How can I rediscover the logical structure I've built in the repository? How do I discover the directed graph information that would let me draw the picture below? Assume that the set of files covered by each tag are very similar but not identical, because most commits add a few files: (tag) (tag) /- vendor - patch1 -\- patch2 -\ / \ \ (branch) (join) (join) / \ \ main /- screend - juke ------ kernel1 --- kernel2 (tag) (tag) (tag) (tag) Another member of the League for Programming Freedom (LPF) lpf@uunet.uu.net ------------------------------------------------------------------------------- Brian Bartholomew - bmb@world.std.com - Recent arrival to the Boston area From lechner Mon Jul 31 16:04:13 1995 Received: (from lechner@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id QAA30544; Mon, 31 Jul 1995 16:04:11 -0400 From: Bob Lechner Message-Id: <199507312004.QAA30544@jupiter.cs.uml.edu> Subject: Re: rcs build on sable or ... To: lechner@jupiter.cs.uml.edu (Bob Lechner) Date: Mon, 31 Jul 1995 16:04:11 -0400 (EDT) Cc: faculty In-Reply-To: <199507281902.PAA29113@jupiter.cs.uml.edu> from "Bob Lechner" at Jul 28, 95 03:02:39 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 694 Status: RO > > info-cvs had this comment re: rcs and cvs. > Do you know if this was done on sable and elsewhere? > > On solaris 2.4, we had problems with binaries files in the repository > until I recompiled rcs to use the proper DIFFLAGS = -an by default, so > that it would handle binaries. Now cvs 1.5 is working just fine with > binaries. > Brian - You asked why worry about Solaris? I agree. However, building rcs with DIFFLAGS = -an may be a generic option that affects alpha and mips as well. In particular, it seems to affect repository acceptance of binary files. Although I have no need for binary support at present, I may in the future. I don;t know if others need it. Bob Lechner From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 3 10:34:48 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA04813 for ; Thu, 3 Aug 1995 10:34:47 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA19985; Thu, 3 Aug 95 03:02:04 EDT Received: from liasg9.epfl.ch by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA19978; Thu, 3 Aug 95 03:01:50 EDT Received: from lia.di.epfl.ch by liasg9.epfl.ch with esmtp (Smail3.1.28.1 #160) id m0sduHn-0002QQC; Thu, 3 Aug 95 09:01 MDT From: "Stefan Monnier" To: Stefan Monnier Cc: CVS Mailing-List Subject: Re: update and new files In-Reply-To: jimb's message of Wed, 02 Aug 1995 14:26:57 CDT. <199508021926.OAA22392@totoro.cyclic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Aug 1995 09:01:41 +0200 Message-Id: <19779.807433301@lia.di.epfl.ch> Sender: monnier@lia.di.epfl.ch Status: RO Jim Blandy wrote: > You need to say "cvs update -d". > > I couldn't say if it was a bug or not. I can't think of a situation > where -d is inappropriate, and I'd be surprised if such situations > were so dangerous or common that -d shouldn't be the default behavior. Looks like the problem is just that you might have checkedout only part of the directory structure. In which case "cvs update -d" will not only add the new directories but also the ones you didn't checkout. Since the reason why some subdirectories where not checkedout is generally because of some module's definition in the modules file, it looks like the necessity of "-d" as well as the problem posed by "-d" comes from the fact that CVS doesn't keep track of "how this directory has been checkedout". If it did, it could filter out the unwanted subdirs while still adding the newly created subdirs. > But I leave this issue to the CVS sages. Well, so do I ! Stefan From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 4 02:13:22 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id CAA06196 for ; Fri, 4 Aug 1995 02:13:22 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA24429; Wed, 2 Aug 95 10:10:04 EDT Received: from liasg9.epfl.ch by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA24384; Wed, 2 Aug 95 10:09:42 EDT Received: from lia.di.epfl.ch by liasg9.epfl.ch with esmtp (Smail3.1.28.1 #160) id m0sdeUL-0002QQC; Wed, 2 Aug 95 16:09 MDT From: "Stefan Monnier" To: CVS Mailing-List Subject: update and new files Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Aug 1995 16:09:35 +0200 Message-Id: <17819.807372575@lia.di.epfl.ch> Sender: monnier@lia.di.epfl.ch Status: RO It looks like addition of directories is not propagated by 'cvs update'. That is, if you add a directory with "cvs add some-directory", a subsequent 'cvs update' will not create the corresponding directory. Am I doing something wrong ? Or is it a bug ? Or is it a feature ? Stefan PS: it is with cvs-1.5 From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 3 18:27:52 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA13100 for ; Thu, 3 Aug 1995 18:27:51 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA02181; Thu, 3 Aug 95 09:58:04 EDT Received: from relay1.pipex.net by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA02163; Thu, 3 Aug 95 09:57:30 EDT Received: from mithras.kapiti.co.uk by flow.pipex.net with SMTP (PP); Thu, 3 Aug 1995 14:56:16 +0100 Received: from kampala.kapiti.co.uk by mithras.kapiti.co.uk (4.1/SMI-4.1) id AA00593; Thu, 3 Aug 95 14:53:51 BST Received: by kampala.kapiti.co.uk (5.65/DEC-Ultrix/4.3) id AA08045; Thu, 3 Aug 1995 14:53:49 +0100 Message-Id: <9508031353.AA08045@kampala.kapiti.co.uk> To: info-cvs@prep.ai.mit.edu Reply-To: younga1@kapiti.co.uk Subject: CVS 1.5 in WinNT Date: Thu, 03 Aug 1995 14:53:48 +0100 From: Alastair Young Status: RO We have a real need to get CVS working on our NT boxes accessing the repository on a unix machine (a sun). This could either be done using NFS (Beame and Whiteside NFS client) or with remote CVS. I would prefer remote CVS since we wouldn't have to buy lots on NFS packages (at huge cost). The NT versions that I have seen are modified to work with FAT file systems - we use NTFS, and it has to work with a unix repository anyway. Right now I'm thinking of porting CVS 1.5 from scratch, just enough to make the remote cvs client side work. The question is, has anyone already done this / is doing it / done this already? Is there something special needed on the NT machine to get remote cvs client side working? (Did I hear 'kerberos' , or rsh ???) I suppose I'll also need RCS (though I'm hoping I can do without if its restricted to cvs client) and gnu diff, are ftp.cdrom.com:/pub/cica/nt/gr564s.zip ftp.cdrom.com:/pub/cica/nt/gd25s.zip ok for NTFS ? +--------------------------------------------------------+ | Alastair Young Tel: +44 1753 573244 | | Kapiti Ltd. Fax: +44 1753 575964 | | Slough | | England Email: Alastair.Young@kapiti.co.uk | +--------------------------------------------------------+ From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 4 02:13:22 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id CAA06196 for ; Fri, 4 Aug 1995 02:13:22 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA24429; Wed, 2 Aug 95 10:10:04 EDT Received: from liasg9.epfl.ch by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA24384; Wed, 2 Aug 95 10:09:42 EDT Received: from lia.di.epfl.ch by liasg9.epfl.ch with esmtp (Smail3.1.28.1 #160) id m0sdeUL-0002QQC; Wed, 2 Aug 95 16:09 MDT From: "Stefan Monnier" To: CVS Mailing-List Subject: update and new files Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Aug 1995 16:09:35 +0200 Message-Id: <17819.807372575@lia.di.epfl.ch> Sender: monnier@lia.di.epfl.ch Status: RO It looks like addition of directories is not propagated by 'cvs update'. That is, if you add a directory with "cvs add some-directory", a subsequent 'cvs update' will not create the corresponding directory. Am I doing something wrong ? Or is it a bug ? Or is it a feature ? Stefan PS: it is with cvs-1.5 From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 4 05:06:27 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id FAA23953 for ; Fri, 4 Aug 1995 05:06:26 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA06826; Thu, 3 Aug 95 11:16:43 EDT Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA06780; Thu, 3 Aug 95 11:16:14 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Thu, 3 Aug 95 11:15:08 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Thu, 3 Aug 95 11:15:08 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: "Stefan Monnier" Cc: CVS Mailing-List Subject: Re: update and new files In-Reply-To: Stefan Monnier's message of "Thu, August 3, 1995 09:01:41 +0200" regarding "Re: update and new files " id <19779.807433301@lia.di.epfl.ch> References: <199508021926.OAA22392@totoro.cyclic.com> <19779.807433301@lia.di.epfl.ch> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Thu, August 3, 1995 at 09:01:41 (+0200), Stefan Monnier wrote: ] > Subject: Re: update and new files > > Looks like the problem is just that you might have checkedout only part of the > directory structure. In which case "cvs update -d" will not only add the new > directories but also the ones you didn't checkout. Since the reason why some > subdirectories where not checkedout is generally because of some module's > definition in the modules file, it looks like the necessity of "-d" as well as > the problem posed by "-d" comes from the fact that CVS doesn't keep track of > "how this directory has been checkedout". If it did, it could filter out the > unwanted subdirs while still adding the newly created subdirs. I actually went so far as to send-pr this, but I must admit I *didn't* RTFM. :-( Now that I know the "work-around", I think "-d" should indeed be the default, and perhaps "-D" should do what the default now does. I sent the original bug report because even with in-depth knowledge of CVS internals, the current behaviour suprised the hell out of me. Mind you, without either forcing folks to pay more attention to the "structure" of their code -- and thus force them to make it fit the current model of modules; or seriously enhancing the modules support; there may be lots of folks who have to rely on the current default behaviour. Perhaps we should ask the question of current users: Does the current behaviour surprise you, or do you require it? -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 4 04:12:27 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA21095 for ; Fri, 4 Aug 1995 04:12:26 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA06892; Thu, 3 Aug 95 11:18:08 EDT Received: from noao.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA06881; Thu, 3 Aug 95 11:17:58 EDT Received: from ctiole (ctiole.ctio.noao.edu) by noao.edu (4.1/SAG-Noao.G102) id AA11653; Thu, 3 Aug 95 08:17:52 MST; for info-cvs@prep.ai.mit.edu Received: by ctiole (4.1/JBH.4) id AA05471; Thu, 3 Aug 95 11:17:48 CST Date: Thu, 3 Aug 95 11:17:48 CST From: webb@ctiole.ctio.noao.edu (gary webb x240) Message-Id: <9508031517.AA05471@ctiole> To: info-cvs@prep.ai.mit.edu Subject: Re: update and new files Status: RO Stefan Monnier wrote: > > Jim Blandy wrote: > > You need to say "cvs update -d". > > > > I couldn't say if it was a bug or not. I can't think of a situation > > where -d is inappropriate, and I'd be surprised if such situations > > were so dangerous or common that -d shouldn't be the default behavior. > > Looks like the problem is just that you might have checkedout only part of the > directory structure. In which case "cvs update -d" will not only add the new > directories but also the ones you didn't checkout. Since the reason why some > subdirectories where not checkedout is generally because of some module's > definition in the modules file, it looks like the necessity of "-d" as well as > the problem posed by "-d" comes from the fact that CVS doesn't keep track of > "how this directory has been checkedout". If it did, it could filter out the > unwanted subdirs while still adding the newly created subdirs. > > > But I leave this issue to the CVS sages. > > Well, so do I ! > > > Stefan > > Agreed. Which is why we only use "cvs update -d" at CTIO for a module we have completely checked out. If the directory is only partially checked out, it is better to add any new sub-directories and then update them explicitly to get their contents. Which puts the onus on the writer: anyone who adds a new sub-directory within a shared directory must e-mail the project members and advertise it -- e.g., "I have just added directory X/Y/Z to the CVS repository. Interested users should cd X/Y; mkdir Z; cvs add Z; cd Z; cvs update -d". Perhaps the last four commands can safely be combined into a specific update, e.g., "cd X/Y; cvs update -d Z". I do not know (having not tried it), but I do know that I have users that would get upset if directory X/Y/Q suddenly appeared as well as Z. Gary From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 4 05:06:37 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id FAA12947 for ; Fri, 4 Aug 1995 05:06:36 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA16015; Thu, 3 Aug 95 13:46:02 EDT Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA15947; Thu, 3 Aug 95 13:45:13 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id MAA25908; Thu, 3 Aug 1995 12:45:04 -0500 Date: Thu, 3 Aug 1995 12:45:04 -0500 From: Jim Blandy Message-Id: <199508031745.MAA25908@totoro.cyclic.com> To: younga1@kapiti.co.uk Cc: info-cvs@prep.ai.mit.edu Subject: CVS 1.5 in WinNT In-Reply-To: <9508031353.AA08045@kampala.kapiti.co.uk> References: <9508031353.AA08045@kampala.kapiti.co.uk> Tomato: mauve Status: RO >We have a real need to get CVS working on our NT boxes accessing the >repository on a unix machine (a sun). This could either be done using >NFS (Beame and Whiteside NFS client) or with remote CVS. I would >prefer remote CVS since we wouldn't have to buy lots on NFS packages >(at huge cost). > >Right now I'm thinking of porting CVS 1.5 from scratch, just enough to >make the remote cvs client side work. The question is, has anyone >already done this / is doing it / done this already? Cyclic is doing a Windows NT/Visual C++ port of the CVS client at the moment. It's not hard, but not trivial either. NT's POSIX support is notoriously poor. From info-cvs-ownrr@prep.ai.mit.edu Sun Aug 6 15:03:40 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA03756 for ; Sun, 6 Aug 1995 15:03:37 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA15116; Sat, 5 Aug 95 23:42:30 EDT Received: from sydney.DIALix.oz.au by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA14346; Sat, 5 Aug 95 23:30:07 EDT Received: from babel.UUCP (babluucp@localhost) by sydney.DIALix.oz.au (8.6.12/8.6.12/DIALix) with UUCP id MAA22550; Sun, 6 Aug 1995 12:43:53 +1000 Date: Sun, 6 Aug 95 10:46 EST From: del@babel.dialix.oz.au (Del) Subject: Re: A couple of questions on CVS To: joel@loc3.tandem.com Cc: info-cvs@prep.ai.mit.edu Message-Id: In-Reply-To: <9508032003.AA02805@oscar.loc3.tandem.com> Status: RO >2. I noticed in the docs that you can set cvs to send out mail when >an 'rtag' is done but not when a 'tag' is done. This seems a little >non-intuitive, since they both have approximately the same effect. >I'd like to send mail on both occasions? Ideas? Does 1.5 handle this? I just put some patches in to CVS 1.5 at Cyclic to do this. Should be out in the next version, or whatever local versions cyclic have available for ftp. Del -- -------------------------------+------------------------------------- Del | del@babel.dialix.oz.au -------------------------------+------------------------------------- From info-cvs-ownrr@prep.ai.mit.edu Sun Aug 6 13:47:57 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA19539 for ; Sun, 6 Aug 1995 13:47:55 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA14306; Sat, 5 Aug 95 23:23:51 EDT Received: from sydney.DIALix.oz.au by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA14298; Sat, 5 Aug 95 23:22:57 EDT Received: from babel.UUCP (babluucp@localhost) by sydney.DIALix.oz.au (8.6.12/8.6.12/DIALix) with UUCP id MAA22721 for prep.ai.mit.edu!info-cvs; Sun, 6 Aug 1995 12:45:09 +1000 Date: Sun, 6 Aug 95 10:58 EST From: del@babel.dialix.oz.au (Del) Subject: Re: A couple of questions on CVS To: info-cvs@prep.ai.mit.edu Message-Id: In-Reply-To: <9508041749.AA21236@etnibsd.UUCP> Status: RO >> 1. Along the lines of the recent thread on 'cvs update -d': is there >> any way to make '-d' the default behavior of cvs, either through >> environment variable or CVSROOT files? Yes, there is. Use a ".cvsrc" file in your home directory. I think this is documented in the CVS 1.5 FAQ in the source distribution. >Perhaps cvs should follow the example of RCS. From the ci man page: Except that CVS would need a separate CVSINIT variable for each command, hence the .cvsrc file used instead. This allows you to specify per- command default options. Del -- -------------------------------+------------------------------------- Del | del@babel.dialix.oz.au -------------------------------+------------------------------------- From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 04:10:53 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA14447 for ; Sat, 5 Aug 1995 04:10:44 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA16659; Fri, 4 Aug 95 11:18:00 EDT Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA16640; Fri, 4 Aug 95 11:17:30 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Fri, 4 Aug 95 11:15:32 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Fri, 4 Aug 95 11:15:32 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: "Joel A. Fine" Cc: info-cvs@prep.ai.mit.edu Subject: Re: A couple of questions on CVS In-Reply-To: Joel A. Fine's message of "Thu, August 3, 1995 13:03:58 -0700" regarding "A couple of questions on CVS" id <9508032003.AA02805@oscar.loc3.tandem.com> References: <9508032003.AA02805@oscar.loc3.tandem.com> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Thu, August 3, 1995 at 13:03:58 (-0700), Joel A. Fine wrote: ] > Subject: A couple of questions on CVS > > 2. I noticed in the docs that you can set cvs to send out mail when > an 'rtag' is done but not when a 'tag' is done. This seems a little > non-intuitive, since they both have approximately the same effect. > I'd like to send mail on both occasions? Ideas? Does 1.5 handle this? I've thought somewhat about a 'taginfo' file (ala commitinfo), but haven't implemented it yet -- maybe for 1.6. I think there's been some cleanup in 1.5 or more recent that will now make easier to implement. > 3. When I automatically send mail on an 'rtag' event, my mail program > isn't told what options were supplied to the 'rtag' command. This means > that the deletion of a tag looks identical to the creation of a tag, > since the same program is called, with the same args, in either case. Good point. I was even thinking of this for commitinfo. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 04:47:00 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA26930 for ; Sat, 5 Aug 1995 04:46:59 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA29008; Fri, 4 Aug 95 14:41:21 EDT Received: from relay3.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA28992; Fri, 4 Aug 95 14:41:04 EDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzbje23483; Fri, 4 Aug 1995 14:39:40 -0400 Received: from etnibsd.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Fri, 4 Aug 1995 14:39:42 -0400 Received: by etnibsd.UUCP (4.1/SMI-4.1(VSH)) id AA21236; Fri, 4 Aug 95 13:49:46 EDT From: etnibsd!vsh@uunet.uu.net (Steve Harris) Message-Id: <9508041749.AA21236@etnibsd.UUCP> Subject: Re: A couple of questions on CVS To: uunet!loc3.tandem.com!joel@uunet.uu.net (Joel A. Fine) Date: Fri, 4 Aug 1995 13:49:46 -0400 (EDT) Cc: uunet!prep.ai.mit.edu!info-cvs@uunet.uu.net In-Reply-To: <9508032003.AA02805@oscar.loc3.tandem.com> from "Joel A. Fine" at Aug 3, 95 01:03:58 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 728 Status: RO Joel A. Fine writes: > > Hi all, > > A couple of questions on cvs: > > 1. Along the lines of the recent thread on 'cvs update -d': is there > any way to make '-d' the default behavior of cvs, either through > environment variable or CVSROOT files? Perhaps cvs should follow the example of RCS. From the ci man page: > ENVIRONMENT > RCSINIT > options prepended to the argument list, separated by > spaces. A backslash escapes spaces within an option. > The RCSINIT options are prepended to the argument lists > of most RCS commands. Useful RCSINIT options include > -q, -V, and -x. -- Steve Harris - Eaton Corp. - Beverly, MA - vsh%etnibsd@uunet.uu.net From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 21:46:28 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id VAA30587 for ; Sat, 5 Aug 1995 21:46:28 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA18143; Fri, 4 Aug 95 18:21:32 EDT Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA18131; Fri, 4 Aug 95 18:19:54 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id QAA04913; Fri, 4 Aug 1995 16:23:25 -0500 Date: Fri, 4 Aug 1995 16:23:25 -0500 From: Jim Blandy Message-Id: <199508042123.QAA04913@totoro.cyclic.com> To: etnibsd!vsh@uunet.uu.net (Steve Harris) Cc: info-cvs@prep.ai.mit.edu Subject: Re: A couple of questions on CVS In-Reply-To: <9508041749.AA21236@etnibsd.UUCP> References: <9508032003.AA02805@oscar.loc3.tandem.com> <9508041749.AA21236@etnibsd.UUCP> X-Windows: Dissatisfaction guaranteed. Status: RO >> 1. Along the lines of the recent thread on 'cvs update -d': is there >> any way to make '-d' the default behavior of cvs, either through >> environment variable or CVSROOT files? > >Perhaps cvs should follow the example of RCS. From the ci man page: Check out the manual's description of the .cvsrc file. I believe a line like "update -d" there will do what you want. From lechner@cs.uml.edu Fri Aug 4 23:45:31 1995 Received: from rigel.cs.uml.edu (rigel.cs.uml.edu [129.63.32.26]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id XAA30782; Fri, 4 Aug 1995 23:45:30 -0400 From: Bob Lechner Received: (lechner@localhost) by rigel.cs.uml.edu (8.6.9/8.6.9) id XAA05238; Fri, 4 Aug 1995 23:45:29 -0400 Message-Id: <199508050345.XAA05238@rigel.cs.uml.edu> Subject: Re:cdif repository. I'll try http.Do you have cdif-94-10-12.tar.uu (stev) To: ernst@isi.com (Johannes Ernst) Date: Fri, 4 Aug 1995 23:45:28 -0400 (EDT) Cc: lechner@cs.uml.edu (Bob Lechner) In-Reply-To: <199508050138.SAA25258@hardrock.isi.com> from "Johannes Ernst" at Aug 4, 95 06:38:58 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 881 Status: RO > I guess I can answer it with one sentence: > Do not use ftp. Do use http. > > There will be a STEV intermediate version within the next couple of > weeks, it will go to FZI/Germany because they will provide > an editor what is fine with me. > OK thanks. Re:cdif repository, I'll try http. How will that overcome the overprotection? I have (from you last year)) stev_jernst.25oct94.cut.uu which uudecoded OK to cdif-94-10-12.tar.uu if you can use it and don't have a copy: -rw-r----- 1 lechner fac 48350 Aug 4 23:34 cdif-94-10-12.tar.uu -rw-r----- 1 lechner fac 66656 May 13 02:49 stev_jernst.25oct94.cut.uu Unfortunately it won't untar: rigel(83)> tar tf cdif-94-10-12.tar.uu tar tf cdif-94-10-12.tar.uu tar: Directory checksum error, possible file name: sh1CC7uhXH0!C#JH1bEmP3hTQqcH0Jb\C$ X(1CF ... ... From info-cvs-ownrr@prep.ai.mit.edu Mon Aug 7 22:41:46 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA19893 for ; Mon, 7 Aug 1995 22:41:46 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA01230; Mon, 7 Aug 95 14:55:01 EDT Received: from suntan.tandem.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA01217; Mon, 7 Aug 95 14:54:42 EDT Received: from adm.loc3.tandem.com by suntan.tandem.com (8.6.12/suntan5.950313) for id LAA23848; Mon, 7 Aug 1995 11:43:53 -0700 Received: from oscar.loc3.tandem.com by adm.loc3.tandem.com (4.1/6main.940209) id AA12010; Mon, 7 Aug 95 11:43:52 PDT Received: by oscar.loc3.tandem.com (4.1/6leaf.940209) id AA15785; Mon, 7 Aug 95 11:43:54 PDT Message-Id: <9508071843.AA15785@oscar.loc3.tandem.com> To: info-cvs@prep.ai.mit.edu Subject: Sending out mail on commits: how to send only 1 msg? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 07 Aug 1995 11:43:53 -0700 From: "Joel A. Fine" Status: RO Hi all, I've configured my CVS installation to send out mail whenever a commit occurs. The only way I know to do that sends out one message for each directory in the hierarchy that has one or more modified files. Unfortunately, the way my group has structured its code, each person is responsible for one file in each of about 60 sub-directories. That is, one person is responsible for all the "*.v" files in the 60 sub-dirs, and another person writes the "*.dcs" files. When a commit occurs, many if not all of the 60 files have typically been modified. This results in up to 60 mail-messages being sent out, since CVS doesn't package the 'commit' command into a single mail-sending event, but rather hands off each sub-dir to the mail-sending script. Is there a way to change CVS' behavior so that the single 'cvs commit' command results in a single mail message? [I'm running cvs-1.5, SunOS 4.1.3.] - Joel Joel Fine joel@everest.tandem.com fine_joel@tandem.com From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 14:21:02 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA27989 for ; Sat, 5 Aug 1995 14:21:02 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA29772; Fri, 4 Aug 95 03:26:48 EDT Received: from slsa02t.stgl.netd.alcatel.de by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA29764; Fri, 4 Aug 95 03:26:18 EDT Received: from slbh01t1.bln.sel.alcatel.de by slsa02t.stgl.netd.alcatel.de with SMTP (PP) id <15153-0@slsa02t.stgl.netd.alcatel.de>; Fri, 4 Aug 1995 09:26:06 +0200 Received: from slbh04 by bln.sel.alcatel.de (4.1/SMI-4.0/DNI-7.0.1/blume_h-1.2) id AA11936; Fri, 4 Aug 95 09:26:34 +0200 From: Uwe.Graichen@bln.sel.alcatel.de (U. Graichen) Received: by slbh04 (4.1) id AA17061; Fri, 4 Aug 95 09:26:31 +0200 Date: Fri, 4 Aug 95 09:26:31 +0200 Message-Id: <9508040726.AA17061@slbh04> To: info-cvs@prep.ai.mit.edu In-Reply-To: <9508031145.AA25058@life.ai.mit.edu> (gdt@bbn.com) Subject: Re: update and new files Status: RO >>>>> gdt@bbn.com writes: gdt> From: Jim Blandy gdt> I couldn't say if it was a bug or not. I can't think of a situation gdt> where -d is inappropriate, and I'd be surprised if such situations gdt> were so dangerous or common that -d shouldn't be the default behavior. gdt> Sometimes -d is inappropriate. [...] gdt> notice that the new directories exist. I would argue that the "don't gdt> update" behavior should still be obtainable. gdt> Greg Troxel I agree with this statement, and the description of the CVS usage by Greg shows one important reason to hold the current behaviour (at least to provide it with an option for a new release). We use CVS for some modules in a similar way. CVS modules are composed of a subset of files from one or more directories (program and libraries). The programs are provided to the users in one target directory (e.g. /special/bin, /special/etc ...) but developed by different developers and/or at different locations. An update in one development sand-box must not check out all files and directories contained in the archive directory/ies. I provide a small shell script to 'cancel files from the current sand-box' for our developers additional. The next simple update should not bring back the cancelled files, except it is requested by the user. If i will update the target sand-box where the programs are provided then i use the additional option to update all and everything. IMHO, it's not a bug. -- uwe +============================================================================+ Email: graichen@bln.sel.alcatel.de ( Expressed opinions which happen to ) correspond with those of my employer Phone: +49 30 7002 3578 ( are still my own. The others are mine. From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 02:21:10 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id CAA12681 for ; Sat, 5 Aug 1995 02:21:10 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA12638; Fri, 4 Aug 95 10:09:13 EDT Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA12610; Fri, 4 Aug 95 10:09:00 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA18498; Fri, 4 Aug 1995 10:08:52 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA13203; Fri, 4 Aug 95 10:08:50 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id KAA25091; Fri, 4 Aug 1995 10:08:49 -0400 Date: Fri, 4 Aug 1995 10:08:49 -0400 Message-Id: <199508041408.KAA25091@kayak.odi.com> To: tammo+@cmu.edu Cc: info-cvs@prep.ai.mit.edu In-Reply-To: (message from Tammo Spalink on Thu, 3 Aug 1995 14:57:05 -0400 (EDT)) Subject: Re: reocurring lock Reply-To: dgg@odi.com Status: RO > Can a directory be set up in such a way to have cvs commit lock it and > then wait for its own lock? > > What I tried: > someone here was having trouble commiting stuff waiting for a lock that > she had. I had her run cvs admin -U , then ran cvs commit > again. Thius changed nothing. Then I copy her directory into a > checkout of mine and try to commit. Now when I commit it does not work > because it is waiting for my lock on the directory. Something wierd is > going on here... > > Any suggestions appreciated, > > Tammo CVS Directory locks and RCS file locks are unrelated. "cvs admin" manipulates the RCS locks. You are being blocked by a CVS directory lock that is just a filename (something like "#cvs.lock" or "#cvs.wfl". You'll have to remove the lock file by hand. From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 02:20:30 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id CAA31424 for ; Sat, 5 Aug 1995 02:20:29 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA14247; Fri, 4 Aug 95 10:35:19 EDT Received: from beach.sctc.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA14215; Fri, 4 Aug 95 10:34:25 EDT Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id JAA09174; Fri, 4 Aug 1995 09:39:05 -0500 Received: from spirit.sctc.com (spirit.sctc.com [172.17.192.76]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id JAA09170; Fri, 4 Aug 1995 09:39:04 -0500 Received: from dagobah.sctc.com (dagobah.sctc.com [172.17.192.121]) by spirit.sctc.com (8.6.12/8.6.10) with ESMTP id JAA19771; Fri, 4 Aug 1995 09:34:16 -0500 Received: (from koster@localhost) by dagobah.sctc.com (8.6.12/8.6.9) id JAA01659; Fri, 4 Aug 1995 09:34:13 -0500 From: Kirby Koster Message-Id: <199508041434.JAA01659@dagobah.sctc.com> Subject: Re: reocurring lock To: tammo+@cmu.edu (Tammo Spalink) Date: Fri, 4 Aug 1995 09:34:12 -0500 (CDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: from "Tammo Spalink" at Aug 3, 95 02:57:05 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1145 Status: RO > Can a directory be set up in such a way to have cvs commit lock it and > then wait for its own lock? > > What I tried: > someone here was having trouble commiting stuff waiting for a lock that > she had. I had her run cvs admin -U , then ran cvs commit > again. Thius changed nothing. Then I copy her directory into a > checkout of mine and try to commit. Now when I commit it does not work > because it is waiting for my lock on the directory. Something wierd is > going on here... I think I noticed this yesterday too. It appeared to me that the commit was creating an additional lock everytime it kicked up the message about waiting for a lock. Then when the original conflicting lock was removed the commit was waiting on it's own original lock. I had about 8 lockfiles created when I finally removed them all and the commit continued on it's merry way. This was with cvs 1.5 under bsd 4.4. If this happens to you again I'd suggest checking the repository for #.lockfiles and remove them if they look ok ... i.e. they are all owned by the person trying to do the commit. Kirby --- Kirby Koster, kkoster@sctc.com From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 03:30:52 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id DAA05751 for ; Sat, 5 Aug 1995 03:27:32 -0400 Received: from life.ai.mit.edu by ulowell.uml.edu with SMTP id AA25126 (5.67b/IDA-1.5 for ); Sat, 5 Aug 1995 03:27:30 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA15981; Fri, 4 Aug 95 11:04:49 EDT Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA15959; Fri, 4 Aug 95 11:04:27 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Fri, 4 Aug 95 11:03:28 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Fri, 4 Aug 95 11:03:28 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: Paige Niederer Cc: CVS Mail List Subject: Re: exclude files in tag? In-Reply-To: Paige Niederer's message of "Wed, August 2, 1995 10:57:24 -0600" regarding "exclude files in tag?" id References: Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Wed, August 2, 1995 at 10:57:24 (-0600), Paige Niederer wrote: ] > Subject: exclude files in tag? > > How can I tag a module but leave out a file or two from the tag? If I > remove the file from my working directory and then tag what's left, will > that do it? Why not just remove the tag from the necessary files after you've tagged them? -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 04:26:21 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA03697 for ; Sat, 5 Aug 1995 04:26:21 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA19799; Fri, 4 Aug 95 12:07:43 EDT Received: from bou.shl.com (dilbert.bou.shl.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA19784; Fri, 4 Aug 95 12:07:23 EDT Received: from butthead by bou.shl.com (NX5.67e/NX3.0Ma) id AA11892; Fri, 4 Aug 95 10:01:43 -0600 Message-Id: <9508041601.AA11892@bou.shl.com> Received: by butthead.bou.shl.com (NX5.67e/NX3.0X) id AA00546; Fri, 4 Aug 95 09:54:36 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Vince DeMarco Date: Fri, 4 Aug 95 09:54:16 -0700 To: Dominik Westner Subject: Re: remote cvs and cvswrappers Cc: info-cvs@prep.ai.mit.edu References: <9508031819.AA21956@iws103.MPPMU.MPG.DE> Status: RO >I have problems using cvswrappers remotely. > >While everything is working fine when doing a local checkout of a >wrapped directory, a remote checkout fails. I don't get a directory >with some files in it, but just a corrupted file with the name of >the directory. > >I tried to remote checkin a directory and it gets wrapped perfectely. >I can checkout this directory local again with no problems. > >Any hints??? This is going to need to be fixed. The problem is that the unexpand script gets run on the server and nothing gets sent accross to the client. I haven't tryed this but put a .cvswrappers file in your home directory, and use that. vince From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 5 04:26:21 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id EAA03697 for ; Sat, 5 Aug 1995 04:26:21 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA19799; Fri, 4 Aug 95 12:07:43 EDT Received: from bou.shl.com (dilbert.bou.shl.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA19784; Fri, 4 Aug 95 12:07:23 EDT Received: from butthead by bou.shl.com (NX5.67e/NX3.0Ma) id AA11892; Fri, 4 Aug 95 10:01:43 -0600 Message-Id: <9508041601.AA11892@bou.shl.com> Received: by butthead.bou.shl.com (NX5.67e/NX3.0X) id AA00546; Fri, 4 Aug 95 09:54:36 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Vince DeMarco Date: Fri, 4 Aug 95 09:54:16 -0700 To: Dominik Westner Subject: Re: remote cvs and cvswrappers Cc: info-cvs@prep.ai.mit.edu References: <9508031819.AA21956@iws103.MPPMU.MPG.DE> Status: RO >I have problems using cvswrappers remotely. > >While everything is working fine when doing a local checkout of a >wrapped directory, a remote checkout fails. I don't get a directory >with some files in it, but just a corrupted file with the name of >the directory. > >I tried to remote checkin a directory and it gets wrapped perfectely. >I can checkout this directory local again with no problems. > >Any hints??? This is going to need to be fixed. The problem is that the unexpand script gets run on the server and nothing gets sent accross to the client. I haven't tryed this but put a .cvswrappers file in your home directory, and use that. vince From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 9 11:30:33 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id LAA06398 for ; Wed, 9 Aug 1995 11:30:32 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA16050; Wed, 9 Aug 95 00:37:56 EDT Received: from metro.ucc.su.OZ.AU by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA16043; Wed, 9 Aug 95 00:37:30 EDT Received: from mama.research.canon.oz.au by metro.ucc.su.OZ.AU with MHSnet id AA16779 (5.65c/IDA-1.4.4 for info-cvs@prep.ai.mit.edu); Wed, 9 Aug 1995 14:35:40 +1000 Received: from miles.research.canon.oz.au (miles.research.canon.com.au) by mama.research.canon.oz.au with SMTP id AA16553 (5.65c8/IDA-1.5); Wed, 9 Aug 1995 13:25:26 +1000 Received: by miles.research.canon.oz.au (NX5.67d/NX3.0S) id AA04386; Wed, 9 Aug 95 13:25:20 +1000 From: Graham Stoney Message-Id: <9508090325.AA04386@miles.research.canon.oz.au> Subject: Re: Is rcs-5.7 reliable? To: kevin@aimnet.com (Kevin Dalley) Date: Wed, 9 Aug 1995 13:25:18 +1000 (GMT+1000) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <199508081612.JAA14991@aplysia.iway.aimnet.com> from "Kevin Dalley" at Aug 8, 95 09:12:45 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 443 Status: RO Kevin Dalley writes: > Is rcs-5.7 reliable? So far, I have discovered only one bug in > rcs-5.7. Are there other bugs? It's not really a bug, but one catch with rcs-5.7 is that the date expansion in $Log messages has changed very slightly. This means that any patches generated by rcsdiff under rcs-5.7 won't apply cleanly to sources containing the $Log keyword which have been checked out under previous versions of rcs. Regards, Graham From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 8 22:36:44 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA00782 for ; Tue, 8 Aug 1995 22:36:43 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA04774; Tue, 8 Aug 95 13:40:44 EDT Received: from sheba.sequoiap.com (sequoiap.vip.best.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA04759; Tue, 8 Aug 95 13:40:11 EDT Received: from blob.best.net (blob.best.net [204.156.128.88]) by shell1.best.com (8.6.12/8.6.5) with ESMTP id KAA22469 for ; Tue, 8 Aug 1995 10:26:36 -0700 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by blob.best.net (8.6.12/8.6.5) with SMTP id KAA14344 for ; Tue, 8 Aug 1995 10:26:32 -0700 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA11311; Tue, 8 Aug 95 04:02:23 EDT Received: from ntigate.rich.nt.com (ntigate.nt.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA11301; Tue, 8 Aug 95 04:02:12 EDT Received: from nmiss1.miss.nt.com by ntigate.rich.nt.com with SMTP (PP); Tue, 8 Aug 1995 03:01:48 -0500 Message-Id: Date: 8 Aug 1995 09:04:10 U From: Richard Avery Subject: Re: [Q]- RCS 5.7 & HPUX Ins To: Info CVS , Tom Tromey X-Mailer: Mail*Link SMTP-QM 3.0.2 GM Source-Info: From (or Sender) name not authenticated. Status: RO Reply to: RE>>[Q]- RCS 5.7 & HPUX Install Damned fin guess! I replaced /bin/sh on the first line of the file with /bin/ksh and configure now completes OK! Looks like sh must have been interpereting part of the sed command. I will gather up the info and mail rcs-bugs later today! Thanks for all your help, Richard. -------------------------------------- Date: 8/8/95 4:03 To: Richard Avery From: Tom Tromey ----- E X T E R N A L L Y O R I G I N A T E D M E S S A G E ----- This line: ../config.status: /][: not found makes me think you are actually seeing a bug in sh, not in configure, or sed. But I can't be sure. You could try digging through config.status to see where the problem actually occurs. Like: sh -x ./config.status and then try to find the offending line. Is HP/UX one of the systems that has multiple versions of sh? You might try "sh5" (or whatever the alternate is called). Or maybe "ksh". This is all just a guess on my part. Tom -- tromey@drip.colorado.edu Member, League for Programming Freedom Sadism and farce are always inexplicably linked. -- Alexander Theroux ------------------ RFC822 Header Follows ------------------ Received: by nnsgq02.lon40.nt.com with SMTP;8 Aug 1995 00:01:42 U Received: from ntigate.rich.nt.com by nrtpm9c1.rtp.nt.com with SMTP (1.38.193.4/16.2) id AA25221; Mon, 7 Aug 95 18:58:55 -0400 Received: from boulder.Colorado.EDU by ntigate.rich.nt.com with Internet SMTP (PP); Mon, 7 Aug 1995 17:54:31 -0500 Received: from hemlock. (hemlock.Colorado.EDU [128.138.232.50]) by boulder.Colorado.EDU (8.6.12/8.6.12/UnixOps) with SMTP id QAA06279; Mon, 7 Aug 1995 16:53:54 -0600 Original-Received: by hemlock. (cu.generic.890828) Pp-Warning: Illegal Received field on preceding line Received: by cambric id ; Mon, 7 Aug 95 16:55:00 MDT Date: Mon, 7 Aug 95 16:55:00 MDT Message-Id: <9508072255.AA02783@cambric> From: Tom Tromey To: Richard Avery Subject: Re: [Q]- RCS 5.7 & HPUX Install In-Reply-To: References: X-Zippy: Content: 80% POLYESTER, 20% DACRON.. The waitress's UNIFORM sheds TARTAR SAUCE like an 8'' by 10'' GLOSSY.. X-Attribution: Tom From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 8 07:45:32 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id HAA14811 for ; Tue, 8 Aug 1995 07:45:30 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA05361; Mon, 7 Aug 95 23:41:40 EDT Received: from most.weird.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA05354; Mon, 7 Aug 95 23:41:23 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Mon, 7 Aug 95 23:37:09 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Mon, 7 Aug 95 23:37:09 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: "Joel A. Fine" Cc: info-cvs@prep.ai.mit.edu Subject: Re: Sending out mail on commits: how to send only 1 msg? In-Reply-To: Joel A. Fine's message of "Mon, August 7, 1995 11:43:53 -0700" regarding "Sending out mail on commits: how to send only 1 msg?" id <9508071843.AA15785@oscar.loc3.tandem.com> References: <9508071843.AA15785@oscar.loc3.tandem.com> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Mon, August 7, 1995 at 11:43:53 (-0700), Joel A. Fine wrote: ] > Subject: Sending out mail on commits: how to send only 1 msg? > > I've configured my CVS installation to send out mail whenever a commit > occurs. The only way I know to do that sends out one message for each > directory in the hierarchy that has one or more modified files. Check out the perl scripts 'commit_prep' and 'log_accum'. They should be installed in the repository CVSROOT module by cvsinit. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 8 23:08:32 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA04984 for ; Tue, 8 Aug 1995 23:08:30 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA05095; Tue, 8 Aug 95 13:50:34 EDT Received: from matrix.ajlc.waterloo.on.ca (tlill.kwic.net) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA05087; Tue, 8 Aug 95 13:50:20 EDT Received: from matrix.ajlc.waterloo.on.ca (localhost.ajlc.waterloo.on.ca [127.0.0.1]) by matrix.ajlc.waterloo.on.ca (8.6.12/8.6.9) with ESMTP id RAA18010 for ; Tue, 8 Aug 1995 17:49:38 GMT Message-Id: <199508081749.RAA18010@matrix.ajlc.waterloo.on.ca> To: info-cvs@prep.ai.mit.edu Subject: Sanity checks Reply-To: Tony.Lill@ajlc.waterloo.on.ca Return-Receipt-To: Tony.Lill@ajlc.waterloo.on.ca X-Face: ;-=i^Y0]L/#H Status: RO What are the plans for the sanity checks? Are we going to keep expanding the shell script, or do we move on to something like DejaGnu? I want to expand the test to do things like adding some binary files to each test, adding various file lengths, etc. and wedging these sorts of global changes into sanity.sh is almost as much work as re-writing it. -- Tony Lill, Tony.Lill@AJLC.Waterloo.ON.CA President, A. J. Lill Consultants (519) 241 2461 539 Grand Valley Dr., Cambridge, Ont. fax/data (519) 650 3571 -------------------- http://tlill.kwic.net/ -------------------- "Welcome to All Things UNIX, where if it's not UNIX, it's CRAP!" From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 8 23:57:05 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA07363 for ; Tue, 8 Aug 1995 23:57:05 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA07469; Tue, 8 Aug 95 14:34:06 EDT Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA07448; Tue, 8 Aug 95 14:33:47 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id NAA09983; Tue, 8 Aug 1995 13:33:46 -0500 Date: Tue, 8 Aug 1995 13:33:46 -0500 From: Jim Blandy Message-Id: <199508081833.NAA09983@totoro.cyclic.com> To: info-cvs@prep.ai.mit.edu Subject: Sanity checks In-Reply-To: <199508081749.RAA18010@matrix.ajlc.waterloo.on.ca> References: <199508081749.RAA18010@matrix.ajlc.waterloo.on.ca> Tomato: mauve Status: RO Tony Lill writes: >What are the plans for the sanity checks? Are we going to keep >expanding the shell script, or do we move on to something like >DejaGnu? I assume that "we" means "the CVS user community." So you're asking a decentralized, anarchistically managed group of people what its plans are. :-) If the CVS user community concocts a cleaned-up, reliable test suite that covers at least what sanity.sh covers, then Cyclic Software would be happy to distribute it. At the moment, Cyclic itself doesn't have funding to undertake the project. From lechner Wed Aug 9 16:57:58 1995 Received: (from lechner@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id QAA30695; Wed, 9 Aug 1995 16:57:54 -0400 From: Bob Lechner Message-Id: <199508092057.QAA30695@jupiter.cs.uml.edu> Subject: Double-mailings since yesterday from info-cvs To: info-cvs-request@prep.ai.mit.edu Date: Wed, 9 Aug 1995 16:57:54 -0400 (EDT) Cc: lechner X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 356 Status: RO I seem to get duplicate messages now - from info-cvs only. The only difference I observe is that one of the messages has this additional line: "Source-Info: From (or Sender) name not authenticated." If this is peculiar to my address, the only reason I can see is that I sent my first message to this list a few days ago. Bob Lechner lechner@cs.uml.edu From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 19 07:19:46 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id HAA28699 for ; Sat, 19 Aug 1995 07:19:41 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA18730; Sat, 19 Aug 95 02:08:02 EDT Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA18718; Sat, 19 Aug 95 02:07:52 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id BAA21085; Sat, 19 Aug 1995 01:07:43 -0500 Date: Sat, 19 Aug 1995 01:07:43 -0500 From: Jim Blandy Message-Id: <199508190607.BAA21085@totoro.cyclic.com> To: "Preston L.Bannister" Cc: CVS Info List Subject: CVS 1.5 ported to Windows NT? In-Reply-To: <199508190411.XAA20651@totoro.cyclic.com> References: <9508190309.AA12105@mdcsc.ca.mdis.com> <199508190411.XAA20651@totoro.cyclic.com> Amphibian: newt Status: RO You asked: >>Before I get started merging the 1.4A2 port of CVS to Windows NT into 1.5, >>has someone already done this?? I replied (and forgot to CC info-cvs): >We have already merged MHI's 1.4A2 port, and are testing it. The port >will be in the next release. I should mention that we're only testing the case in which the repository resides on another host, and Windows NT is just running the CVS client. That's all our customer wanted to pay for. Oh well. But I certainly haven't gone out of my way to break the non-remote code. Once I get around to merging it back into the main CVS tree, the Windows NT port will appear in the nightly snapshots in ftp://ftp.cyclic.com/pub/cvs. If you were to snarf the snapshot and get it working non-remotely under Windows NT, and submit clean patches, we'd love to apply them, time permitting. From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 19 01:51:42 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id BAA24971 for ; Sat, 19 Aug 1995 01:51:37 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA19773; Fri, 18 Aug 95 16:41:25 EDT Received: from mail.think.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA19761; Fri, 18 Aug 95 16:41:07 EDT Received: from Think.COM by mail.think.com; Fri, 18 Aug 95 16:40:55 -0400 Received: from firewall-04.NVidia.COM (firewall.nvidia.com) by Early-Bird.Think.COM; Fri, 18 Aug 95 16:40:51 EDT Received: from thelma.NVidia.COM (thelma.nvidia.com [10.1.4.37]) by firewall-04.NVidia.COM (8.6.10/8.6.4) with ESMTP id NAA04927; Fri, 18 Aug 1995 13:35:21 -0700 Received: from vygr.NVidia.COM (vygr.nvidia.com [10.1.8.9]) by thelma.NVidia.COM (8.6.9/8.6.4) with ESMTP id NAA05446; Fri, 18 Aug 1995 13:39:12 -0700 From: Mike Ekberg Received: (mae@localhost) by vygr.NVidia.COM (8.6.9/8.6.4) id NAA27300; Fri, 18 Aug 1995 13:41:39 -0700 Date: Fri, 18 Aug 1995 13:41:39 -0700 Message-Id: <199508182041.NAA27300@vygr.NVidia.COM> To: dougw@think.com, dianem@think.com Subject: Re: is there a way to do a CVS "clean". Cc: cvs-info-ext@think.com, languages@think.com Status: RO Woudn't it be better to write your makefiles to do this, then call the top level, which calls the next level, and so on hierarchically. Then each directories makefile gets to decide what to "clean". Here is what I did: non-leaf dir makefile: BUILD_DIRS = mystdlib vh2ch dispatch standVerilog clean: @true Clean: clean @echo "!!!Cleaning $(HERE) Tree!!!, ^C to halt!" @sleep 5 @for dir in $(BUILD_DIRS); do \ (cd $$dir; make Clean); \ done leaf dir makefile: Clean: clean clean: rm -f *.o >>From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 18 12:24:56 1995 >>From: Diane Meirowitz >>To: dougw@think.com >>Cc: cvs-info-ext@think.com, languages@think.com >>Subject: is there a way to do a CVS "clean". >> >> From: Douglas Wiedemann >> Date: Fri, 18 Aug 95 13:11:52 EDT >> >> >> Howdy, >> >> If we have a large directory tree under CVS control, can the CVS user >> run something which goes through their checked out tree and deletes >> all files not under CVS control? This would be very useful for those >> applications where lots of clutter files or log files are routinely >> generated. Note that this would be a little different than doing a >> commit; rm *; checkout, because it would not disturb the repository. >> >> Thanks, >> Doug Wiedemann >> >> >>I could write a script to do it, if you want. >> >> Diane >> From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 18 03:27:22 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id DAA08263 for ; Fri, 18 Aug 1995 03:27:21 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA12437; Fri, 18 Aug 95 00:22:47 EDT Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA12426; Fri, 18 Aug 95 00:22:24 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Fri, 18 Aug 95 00:22:27 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Fri, 18 Aug 95 00:22:27 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: bmb@world.std.com (Brian Bartholomew) Cc: info-cvs@prep.ai.mit.edu, rouilj@cs.umb.edu Subject: Re: How to add file on vendor branch and merge it into main branch? In-Reply-To: Brian Bartholomew's message of "Thu, August 17, 1995 14:40:45 -0400" regarding "How to add file on vendor branch and merge it into main branch?" id <199508171840.AA05251@world.std.com> References: <199508171840.AA05251@world.std.com> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Thu, August 17, 1995 at 14:40:45 (-0400), Brian Bartholomew wrote: ] > Subject: How to add file on vendor branch and merge it into main branch? > > Note: I am not on the info-cvs mailing list. I will summarize. > > I'm using cvs 1.3. I want to add a file on the vendor branch that's > part of a vendor patch, and then merge the vendor branch changes If it's part of the vendor's new release, just use 'cvs import' You can checkout the previous vendor release, and apply the new patch to it, then use 'cvs import -I ! -I CVS [...]', or unpack the old release if you have it, then apply the patch and use 'cvs import [....]' If you were missing a file on the vendor import, and want to add it in, you can use something like this wee script from right within a working directory (I use this for a slightly odd module, but you'll get the idea): #! /bin/sh : # # newfile.sh - check in a new file # #ident "@(#)cf:$Id: newfile.sh,v 1.1 1995/08/08 04:03:59 woods Exp $" TMPDIR="${TMPDIR:-/tmp}" ; export TMPDIR LOCAL="${LOCAL:-/local}" GNU="${GNU:-/local/gnu}" PATH="/usr/5bin:/usr/bin:/usr/ucb:$LOCAL/bin:$GNU/bin" export PATH argv0="`basename $0`" CFDIR="`dirname $0`" NEWFILE="$1" expr "`id`" : '^uid=0(root)' >/dev/null && { echo "$argv0: ERROR: you must NOT be root!"; exit 1; } echo "Please enter a description for the file: \c" read DESCRIPTION VENDOR="SunOS" VENDORRELEASE="SunOS-4_1_4" VENDOR_DESC="SunOS 4.1.4 Distribution" cvs add -m "$DESCRIPTION" $NEWFILE || exit 1 cvs commit -m "Initial revision" $NEWFILE || exit 1 cvs commit -r1.1.1.1 -m "$VENDOR_DESC" $NEWFILE || exit 1 cvs admin -b1.1.1 -N${VENDOR}:1.1.1 -N${VENDORRELEASE}:1.1.1.1 $NEWFILE || exit 1 cvs update -A $NEWFILE exit $? -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 18 12:12:50 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA01092 for ; Fri, 18 Aug 1995 12:12:48 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA22005; Fri, 18 Aug 95 08:18:15 EDT Received: from dayton.saic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA21939; Fri, 18 Aug 95 08:17:43 EDT Received: from llcoolj.dayton.saic.com.noname (llcoolj.dayton.SAIC.COM [139.121.26.6]) by dayton.saic.com (8.6.9/8.6.5) with SMTP id IAA20642; Fri, 18 Aug 1995 08:19:33 -0400 Received: by llcoolj.dayton.saic.com.noname (4.1/SMI-4.1) id AA04350; Fri, 18 Aug 95 08:18:46 EDT Date: Fri, 18 Aug 95 08:18:46 EDT Message-Id: <9508181218.AA04350@llcoolj.dayton.saic.com.noname> From: Mike Sutton To: info-cvs@prep.ai.mit.edu, bmb@world.std.com In-Reply-To: <199508171840.AA05251@world.std.com> (bmb@world.std.com) Subject: Re: How to add file on vendor branch and merge it into main branch? Status: RO >>>>> "Brian" == Brian Bartholomew writes: Brian> Note: I am not on the info-cvs mailing list. I will summarize. Brian> I'm using cvs 1.3. I want to add a file on the vendor branch Brian> that's part of a vendor patch, and then merge the vendor branch Brian> changes including the new file onto the main branch. I can Brian> manage to get the new file to check out on either the vendor Brian> branch or the main branch, but not both. I get funky messages Brian> from the 'cvs co -j' so I'm probably doing it wrong. When I Brian> run the script it looks like this: Here is what I have done successfully. I have a program called reslister. I recently (within the last 2 weeks) upgraded from v5.2 to v5.3 of the reslister program. I made modifications to the v5.2 distribution that I wanted to incorporate into v5.3. Here is what I did. cd reslister cvs import reslister TAE V5_2 # checked in as 1.1.1.1 cd .. rm -rf reslister cvs co reslister [made my changes] cvs ci -m 'my mods to v5.2' # checked in as 1.2 cd .. cvs release -d reslister # or use rm -rf reslister cd reslister5.3 cvs import reslister TAE V5_3 # checked in as 1.1.1.2 cd .. cvs co -j1.1.1.1 -j1.1.1.2 reslister The last checkout will do the merging. I was able to resolve the conflicts in about 20 minutes. Mike Sutton | Life is hard when you're SAIC | home-pageless. Beavercreek, OH | Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 18 13:04:57 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA13520 for ; Fri, 18 Aug 1995 13:04:57 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA24727; Fri, 18 Aug 95 09:22:37 EDT Received: from harvey.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA24720; Fri, 18 Aug 95 09:22:27 EDT Received: (from kingdon@localhost) by harvey.cyclic.com (8.6.9/8.6.9) id JAA01725; Fri, 18 Aug 1995 09:25:48 -0400 Date: Fri, 18 Aug 1995 09:25:48 -0400 From: Jim Kingdon Message-Id: <199508181325.JAA01725@harvey.cyclic.com> To: info-cvs@prep.ai.mit.edu In-Reply-To: <18835.808727208@liasun1.epfl.ch> (stefan.monnier@epfl.ch) Subject: Re: Cyclic vs. RCVS Status: RO > In any case, if you want a remote repository, the best is to use a good > distributed filesystem, like AFS (or now DFS). Why should cvs (or rcvs) > people reinvent the wheel ? The cvs 1.5 protocol is more efficient of network bandwidth and also has the following property: The server never has to have any CVS locks in place while it is waiting for communication with the client. This makes things robust in the face of flaky networks. From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 19 00:21:20 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id AAA00042 for ; Sat, 19 Aug 1995 00:21:11 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA08618; Fri, 18 Aug 95 13:29:07 EDT Received: from caddy.arnet.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA08590; Fri, 18 Aug 95 13:28:48 EDT Subject: Re: Cyclic vs. RCVS To: info-cvs@prep.ai.mit.edu Date: Fri, 18 Aug 1995 12:26:09 -0500 (CDT) From: Robert Lipe In-Reply-To: <199508181325.JAA01725@harvey.cyclic.com> from "Jim Kingdon" at Aug 18, 95 09:25:48 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 648 Message-Id: <9508181226.aa07720@caddy.arnet.com> Status: RO > > In any case, if you want a remote repository, the best is to use a good > > distributed filesystem, like AFS (or now DFS). Why should cvs (or rcvs) > > people reinvent the wheel ? > > The cvs 1.5 protocol is more efficient of network bandwidth and also > has the following property: This is absolutely true. If you've ever tried any CVS operation when the filesystem was NFS mounted over a 56K line or [ gasp ] a v.32 modem PPP line, you realize it's quite painful. The CVS 1.5 protocol seems to be much less terrible. In fairness, I've never tried AFS across a modem, but filesystem code generally isn't optimized for modem use. RJL From info-cvs-ownrr@prep.ai.mit.edu Sat Aug 19 07:39:39 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id HAA29021 for ; Sat, 19 Aug 1995 07:39:38 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA19164; Sat, 19 Aug 95 02:43:06 EDT Received: from boulder.Colorado.EDU by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA19154; Sat, 19 Aug 95 02:42:54 EDT Received: from hemlock. (hemlock.Colorado.EDU [128.138.232.50]) by boulder.Colorado.EDU (8.6.12/8.6.12/UnixOps) with SMTP id AAA06967; Sat, 19 Aug 1995 00:42:52 -0600 Received: by hemlock. (cu.generic.890828) Received: by cambric id ; Sat, 19 Aug 95 00:43:57 MDT Date: Sat, 19 Aug 95 00:43:57 MDT Message-Id: <9508190643.AA00162@cambric> From: Tom Tromey To: kanupan@sag.gmeds.com (Narasimha Kanuparthy) Cc: info-cvs@prep.ai.mit.edu Subject: Re: cvs1.5 & firewalls In-Reply-To: <9508181559.AA22026@icad26.Saginaw> References: <9508181559.AA22026@icad26.Saginaw> X-Zippy: I left my WALLET in the BATHROOM!! X-Attribution: Tom Status: RO >>>>> "Narasimha" == Narasimha Kanuparthy writes: Narasimha> Does CVS1.5 have the remote support across firewalls? What Narasimha> are the alternatives if 'rsh' across firewalls is not Narasimha> allowed? Can one use 'telnet'? There isn't any particular support for firewalls. With stock 1.5 you have two choices for remote access: * Use rsh. * Use kerberos. I've written patches that allow explicit user/password authentication. In this case the cvs server does the authentication using the password file; the password is sent in clear over the net. I suppose your sysadmin might not allow this either, depending on his precise policies. I probably posted my patches to the list. Check the archives. (If not, I can try to regenerate them if you are interested) If you really need a telnet connection, consider writing a program to use in place of "rsh" that uses expect to drive telnet. I believe 1.5 has an environment variable you can set to tell cvs which program to use instead of "rsh". Tom -- tromey@drip.colorado.edu Member, League for Programming Freedom "He contacted the highest order of computers remaining, the one at Cal Tech." --Philip K. Dick, 1981 _The Divine Invasion_, p. 105 From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 17 19:55:44 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA09883 for ; Thu, 17 Aug 1995 19:55:43 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA07668; Thu, 17 Aug 95 14:41:13 EDT Received: from europe.std.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA07638; Thu, 17 Aug 95 14:40:53 EDT Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id OAA07423; Thu, 17 Aug 1995 14:40:47 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA05251; Thu, 17 Aug 1995 14:40:45 -0400 Date: Thu, 17 Aug 1995 14:40:45 -0400 From: bmb@world.std.com (Brian Bartholomew) Message-Id: <199508171840.AA05251@world.std.com> To: info-cvs@prep.ai.mit.edu, rouilj@cs.umb.edu Subject: How to add file on vendor branch and merge it into main branch? Status: RO Note: I am not on the info-cvs mailing list. I will summarize. I'm using cvs 1.3. I want to add a file on the vendor branch that's part of a vendor patch, and then merge the vendor branch changes including the new file onto the main branch. I can manage to get the new file to check out on either the vendor branch or the main branch, but not both. I get funky messages from the 'cvs co -j' so I'm probably doing it wrong. When I run the script it looks like this: + cvs co foo cvs checkout: Updating foo >> U foo/addedonmain >> U foo/oldfile + echo ===== Main branch checkout, does not have file addedonvendor + cd .. + rm -rf try2 + mkdir -p try2 + cd try2 + cvs co -r vendorbranchbranch foo cvs checkout: Updating foo >> U foo/addedonvendor >> U foo/oldfile + echo ===== Vendor branch checkout, does not have file addedonmain Another member of the League for Programming Freedom (LPF) lpf@uunet.uu.net ------------------------------------------------------------------------------- Brian Bartholomew - bmb@world.std.com - Recent arrival to the Boston area ----- #!/bin/sh -xe TOP=$HOME/bb-cvs-test CVSROOT=$TOP/repository ; export CVSROOT # Make repository rm -rf $CVSROOT mkdir -p $CVSROOT cvsinit cd $CVSROOT/CVSROOT co -l modules echo "foo foo" >> modules ci -u -mfoo modules cd ../.. # Import something rm -rf import mkdir -p import cd import echo oldfile > oldfile cvs import -mbar foo vendorbranchbranch vendorbranchfirstinstance cd .. # Add and modify something on the vendor branch rm -rf work mkdir -p work cd work cvs co -r vendorbranchbranch foo cd foo echo newcontents > oldfile echo foo > addedonvendor cvscheck cvs add addedonvendor # # First one goes into attic, is checked out with vendor branch, is # not checked out with main branch. Second one doesn't go into # attic, is not checked out with vendorbranch, is checked out with # main branch. What I *want* is checked out on vendor branch, merged # into main branch, and then checked out on main branch too. # cvs commit -mbaz -r vendorbranchbranch ###cvs commit -mbaz # cd ../.. # Add and modify something on the main branch rm -rf work2 mkdir -p work2 cd work2 cvs co foo cd foo echo addedonmain > addedonmain cvscheck cvs add addedonmain cvs commit -mwork2 cd ../.. # See what we have on the main branch rm -rf try1 mkdir -p try1 cd try1 cvs co foo echo "===== Main branch checkout, does not have file addedonvendor" > /dev/null cd .. # See what we have on the vendor branch rm -rf try2 mkdir -p try2 cd try2 cvs co -r vendorbranchbranch foo echo "===== Vendor branch checkout, does not have file addedonmain" > /dev/null cd .. # Commentary echo "===== Now try merging the vendor branch into the main branch," > /dev/null echo "===== and note that file addedonvendor is not subsequently" > /dev/null echo "===== checked out with the main branch. Also try a cvs diff" > /dev/null echo "===== between vendor branch and main branch and note that" > /dev/null echo "===== neither addedonvendor or addedonmain is mentioned." > /dev/null From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 16 15:09:21 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id PAA09224 for ; Wed, 16 Aug 1995 15:09:04 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA14449; Wed, 16 Aug 95 10:01:20 EDT Received: from astro.Princeton.EDU by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA14438; Wed, 16 Aug 95 10:01:12 EDT Received: from babayaga (rhl@babayaga [128.112.24.20]) by astro.Princeton.EDU (8.6.12/8.6.12) with SMTP id KAA13371 for ; Wed, 16 Aug 1995 10:01:11 -0400 From: Robert Lupton the Good Received: by babayaga (931110.SGI/Astro_Client) id AA19646; Wed, 16 Aug 95 10:01:10 -0400 Date: Wed, 16 Aug 95 10:01:10 -0400 Message-Id: <9508161401.AA19646@babayaga> To: info-cvs@prep.ai.mit.edu Subject: rcvs v. cvs 1.5 Status: RO A large astrophysics collaboration that I am involved in have been using rcvs for a couple of years (or is it longer now?). We haven't yet had a chance to investigate the new client/server implementation, but we shall as soon as time permits. Our experience of rcvs has been that it's reasonably solid (earlier releases weren't; it was pretty easy to lose work), but also terribly frustratingly slow. We've tried to work from Princeton to Batavia (Il; near Chicago) using the internet and there are times when you just cannot. Note that both sites are major academic sites, and reasonably close to the backbone. We've had trouble with permissions, but that may be partly due to our use of a pseudo account (called cvs) to handle connections to the remote (master) repository. Some of this may be the generic problems (at least in 1.3) of setgid conflictig with access(). Using the checkin-control features is a bit of a mess, as the perl script that we use has to be present and updated on the local machine. This would be easier now that all files in CVSROOT are checked out. The rcvs code isn't especially clean (at least, last time that I worked on it it wasn't). It's hard to control network activity via popen(), rsh, and rdist. I (and I speak for myself only here) would like to see the cvs 1.5 client/server architecture adopted, with such work done as needed to make it efficient. When you have to wait a Long Time for a cvs log or cvs diff (for which rcvs forces a repository update) or an update (for which rcvs must force an update) you care about efficiency! Robert -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert Lupton rhl@astro.princeton.edu (609) 466 2431 (Home) (609) 258 3811 (Work) SM mailing lists: SM-request@astro.princeton.edu You can't beat SM (You may have mis-interpreted the previous line. It isn't _that_) From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 16 10:03:43 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id KAA19873 for ; Wed, 16 Aug 1995 10:03:40 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA05365; Wed, 16 Aug 95 06:27:36 EDT Received: from arl-img-5.compuserve.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA05358; Wed, 16 Aug 95 06:27:24 EDT Received: by arl-img-5.compuserve.com (8.6.10/5.950515) id GAA28693; Wed, 16 Aug 1995 06:27:22 -0400 Date: 16 Aug 95 06:25:59 EDT From: To: , Subject: Re: OS2 version for CVS?????? Message-Id: <950816102558_702420.204300_BHD53-38@CompuServe.COM> Status: RO > Does anyone know if there is an OS2 version for CVS??? If so, where > could I find it. Yep, from the FAQ: --------------- Pasted from FAQ --------------- 4H.2 I use OS/2 and/or DOS. Is there anything I need to know? You can share RCS files between Unix and DOS while avoiding the MS-DOS file name limits by setting your RCSINIT environment variable to '-x/,v'. New RCS files will be created without the standard ",v" suffix, though files ending in ",v" will still be found if there is no matching file in the same directory without the ",v". Erik van Linstee offers an OS/2 and a DOS port of CVS 1.3 in: ftp.informatik.tu-muenchen.de:/pub/comp/os/os2/gnu/devtools or ftp.rrzn.uni-hannover.de:/pub/os2-local The files are named: cvs13p?[bs].zip Where the ? stands for the patch level (currently 8) and the b is for the binaries, the s for the sources. There are three binaries. An OS/2 only one (32-bit), a DOS only one (16-bit) and an EMX one that runs on both (32-bit). There are many differences between the Unix and the DOS versions of CVS. Read the material that comes with the DOS version before using it. [[Updates?]]. ------------- End Quote -------------- We're using it (actually a newer version) and there seem to be no major problems. Recommended! Jim Hughes From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 15 21:42:35 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id VAA14234 for ; Tue, 15 Aug 1995 21:42:34 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA29948; Tue, 15 Aug 95 16:32:42 EDT Received: from rocky.sri.MT.net (sri.MT.net) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA29932; Tue, 15 Aug 95 16:32:18 EDT Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id OAA09486; Tue, 15 Aug 1995 14:34:17 -0600 Date: Tue, 15 Aug 1995 14:34:17 -0600 Message-Id: <199508152034.OAA09486@rocky.sri.MT.net> To: Noel Cragg Cc: info-cvs@prep.ai.mit.edu Subject: Re: Cyclic vs. RCVS In-Reply-To: <199508151629.MAA23383@virtual.office.com> References: <199508151629.MAA23383@virtual.office.com> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Status: RO > Neat! The Stanford folks have taken an entirely different approach to > remote repositories. > > In short: instead of doing operations directly with a remote > repository (as Cyclic does), RCVS makes a local copy of the repository > to operate on. That is, the two repositories are synchronized before > before each cvs directive (co, add, remove) is processed. Here is a > sample execution for checkout: > > 1) copy remote repository to client (they do it efficiently using > rdist) When I first looked at SLAC's version, this was my biggest problem. I understand that it's much nicer to use already existing tools, but rdist was too much of a security hole. The pros to the above approach is that it allows remote sites at the end of links to 'update' their tree on a regular basis but still gives them the speed of a local repository when they are off the net. > 2) do "cvs checkout" locally > > for add: > > 1) check remote for file being added (rdist again) > 2) do "cvs add" locally > 3) synch repositories (rdist clone -> master) A fast network is a neccesity for this case. The opportunity for conflict is much higher than in the current RCVS setup. > for update: > > 1) synch repositories (master -> clone) > 2) do "cvs update" locally > > Very clean. > > Also not so good in various ways: > > * 100% more disk space necessary than Cyclic Which isn't always a bad thing if you've got the disk space to burn. > * high network bandwidth (no compression, send all *,v files) This is the #1 problem IMHO. It *requires* a fast network, and if you don't have one there is opportunity for conflicts. Almost a year ago I was able to complete hose up my test repository by doing modifications to the master and remote site at the same time. The remote site was at the end of a 56K link running about 80% full. > I like the cleanliness of the setup, but I think that Cyclic CVS is > probably faster and more efficient. I'll try and run a few tests > later today to back up that gut feeling. If it were possible to combine the two approaches it would be a big win IMHO, but unfortunately the time I had alloted to look into this many moons ago keep slipping away. Nate From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 15 17:56:44 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA30190 for ; Tue, 15 Aug 1995 17:56:43 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA14979; Tue, 15 Aug 95 12:37:19 EDT Received: from virtual.office.com (welcome.vo.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA14969; Tue, 15 Aug 95 12:37:11 EDT Received: (from noel@localhost) by virtual.office.com (8.6.12/8.6.12) id MAA23383; Tue, 15 Aug 1995 12:29:29 -0400 Date: Tue, 15 Aug 1995 12:29:29 -0400 From: Noel Cragg Message-Id: <199508151629.MAA23383@virtual.office.com> To: info-cvs@prep.ai.mit.edu Subject: Cyclic vs. RCVS Status: RO Neat! The Stanford folks have taken an entirely different approach to remote repositories. In short: instead of doing operations directly with a remote repository (as Cyclic does), RCVS makes a local copy of the repository to operate on. That is, the two repositories are synchronized before before each cvs directive (co, add, remove) is processed. Here is a sample execution for checkout: 1) copy remote repository to client (they do it efficiently using rdist) 2) do "cvs checkout" locally for add: 1) check remote for file being added (rdist again) 2) do "cvs add" locally 3) synch repositories (rdist clone -> master) for update: 1) synch repositories (master -> clone) 2) do "cvs update" locally Very clean. Also not so good in various ways: * 100% more disk space necessary than Cyclic * high network bandwidth (no compression, send all *,v files) * based on cvs-1.3 I can't speak to the locking mechanism, as I don't know everything about the Cyclic package (I know, read the source!). There is an excellent set of transparencies in the rcvs-doc directory (rcvs-trans.ps) which should give everyone a nice overview of how this stuff works. I made diffs of cvs-1.3 and rcvs-1.3; the only substantial mods are in the addition of 4 (rcvs_*.c) source files. The rest of the code is mostly unchanged. I like the cleanliness of the setup, but I think that Cyclic CVS is probably faster and more efficient. I'll try and run a few tests later today to back up that gut feeling. From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 15 12:22:05 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id MAA13609 for ; Tue, 15 Aug 1995 12:22:02 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA01566; Tue, 15 Aug 95 08:21:03 EDT Received: from ileaf.com (ileaf.prospect.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA01558; Tue, 15 Aug 95 08:20:49 EDT Received: from leafusa.UUCP by ileaf.com (4.1/SMI-4.1) id AA23294; Tue, 15 Aug 95 08:20:28 EDT Received: from owl.hq.ileaf.com by HQ.Ileaf.COM (4.1/SMI-4.0-leafusa) for info-cvs@prep.ai.mit.edu id AA23631; Tue, 15 Aug 95 08:14:14 EDT Received: by owl.hq.ileaf.com (4.1/SMI-4.0-hq) for info-cvs@prep.ai.mit.edu id AA09270; Tue, 15 Aug 95 08:14:13 EDT Date: Tue, 15 Aug 95 08:14:13 EDT From: karl@owl.hq.ileaf.com (Karl Berry) Message-Id: <9508151214.AA09270@owl.hq.ileaf.com> To: info-cvs@prep.ai.mit.edu Subject: [gnu.misc.discuss] Re: Distributed RCS? Status: RO Just noticed this on gnu.misc.discuss. Some words of comparison in any updated FAQ and/or some integration of code in future cvs releases would probably be in order ... Newsgroups: gnu.misc.discuss From: pfkeb@hpkaon.SLAC.Stanford.EDU (Paul F. Kunz) Subject: Re: Distributed RCS? Message-ID: Sender: news@unixhub.SLAC.Stanford.EDU Reply-To: Paul_Kunz@slac.stanford.edu Organization: Stanford Linear Accelerator Center References: <409saf$i6h@nz12.rz.uni-karlsruhe.de> Date: Fri, 11 Aug 1995 04:29:53 GMT Lines: 24 >>>>> On 9 Aug 1995 08:40:47 GMT, burke@ira.uka.de (Wolfgang Burke) said: > Hi, we are performing a project with files residing on two different > sites. We want to manage our files with RCS. The current procedure > to change a remote file is very tedious, since we have to check it > out on the remote site, ftp it from there, perform the change, ftp > it back and check it in. We are looking for a distributed version > of RCS or some other software control system. Does anybody have > similar problems? How do you solve them? We built a distributed RCS, but then abandonned it when we moved to CVS (a RCS compatible superset). Now we've invented distributed CVS which is used by quite a number of sites. In fact, our CVS repository (directory tree of RCS ,v files) here is routinely accessed and updated by sites on your continent including your university. Check out... ftp://ftp.slac.stanford.edu/pub/sources/rcvs-NN.tar.Z -- Paul F. Kunz Paul_Kunz@slac.stanford.edu (NeXT mail ok) Stanford Linear Accelerator Center, Stanford University Voice: (415) 926-2884 (NeXT) Fax: (415) 926-3587 From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 22 17:17:43 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA31279 for ; Tue, 22 Aug 1995 17:17:40 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA26862; Tue, 22 Aug 95 13:04:31 EDT Received: from omdnsx1.om-inc.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA26842; Tue, 22 Aug 95 13:04:03 EDT Received: from OM01s02.om-inc.com by omdnsx1.om-inc.com (AIX 3.2/UCB 5.64/4.03) id AA03254; Tue, 22 Aug 1995 13:00:22 -0400 Received: by OM01s02.om-inc.com (4.1/SMI-4.1) id AA08278; Tue, 22 Aug 95 13:00:24 EDT Date: Tue, 22 Aug 95 13:00:24 EDT From: onn@om01s02.om-inc.com (Brian Onn - Teknekron) Message-Id: <9508221700.AA08278@OM01s02.om-inc.com> To: kanupan@sag.gmeds.com (Narasimha Kanuparthy) Cc: info-cvs@prep.ai.mit.edu Reply-To: onn@tss.com (Brian Onn) Precedence: junk Subject: Re: cvs1.5 & firewalls In-Reply-To: <9508190643.AA00162@cambric> References: <9508181559.AA22026@icad26.Saginaw> <9508190643.AA00162@cambric> Status: RO >>>>> "Tom" == Tom Tromey writes: Tom> There isn't any particular support for firewalls. Tom> With stock 1.5 you have two choices for remote access: Tom> * Use rsh. * Use kerberos. Tom> I've written patches that allow explicit user/password Tom> authentication. In this case the cvs server does the Tom> authentication using the password file; the password is sent Tom> in clear over the net. I suppose your sysadmin might not Tom> allow this either, depending on his precise policies. Tom's patches are what I chose to use to get through our firewall. I am constantly on-site at a client and need access to the CVS repository that sits behind our firewall. Our firewall is an application level firewall using the TIS toolkit, so I can plug a PCVS (password based CVS) connection to a specific CVS server inside the firewall, and only permit connections from a specific IP address for added security. The cleartext password is the only drawback, but is acceptable risk given my needs. To make this easier to swallow for a sysadmin, the password I chose is unique and useless directly on the firewall. Brian. From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 22 07:13:06 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id HAA30512 for ; Tue, 22 Aug 1995 07:13:05 -0400 Date: Tue, 22 Aug 1995 07:13:05 -0400 From: info-cvs-ownrr@prep.ai.mit.edu Message-Id: <199508221113.HAA30512@jupiter.cs.uml.edu> Apparently-To: Status: RO > However, there are ports to VMS, OS/2, and MS-DOS on the horizon. > We'd very much like to have a single source tree that can be > configured and built for all these platforms, instead of separate > versions. So the code does need to be parameterized somehow. The proper place to convert "/" to "\", if necessary, is at the lowest level, right before accessing the file. Some C libraries (I believe including all the ones for MS-DOS) already do it. But if not, one could write a small wrapper around fopen which would make the transformation. From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 22 06:48:35 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id GAA00257 for ; Tue, 22 Aug 1995 06:48:34 -0400 Date: Tue, 22 Aug 1995 06:48:34 -0400 From: info-cvs-ownrr@prep.ai.mit.edu Message-Id: <199508221048.GAA00257@jupiter.cs.uml.edu> Apparently-To: Status: RO Preston L.Bannister says: >Ok, I'm impatient. Hey, that's great! :-) Please check out the partial 1.5 port in ftp://ftp.cyclic.com/pub/cvs/windows-nt. >I was looking at all the places "/" was replaced in the code, and wondering >if that was really the right idea. DOS (and Windows NT) is perfectly happy >using "/" or "\" was a directory separator. It is only some of the DOS >command line utilities that get confused using "/" as a directory separator. This is true if one plans only to be concerned with Windows NT. However, there are ports to VMS, OS/2, and MS-DOS on the horizon. We'd very much like to have a single source tree that can be configured and built for all these platforms, instead of separate versions. So the code does need to be parameterized somehow. From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 22 13:44:25 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA29457 for ; Tue, 22 Aug 1995 13:44:25 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA14036; Tue, 22 Aug 95 09:00:50 EDT Received: from mail.dialogic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA14022; Tue, 22 Aug 95 09:00:35 EDT Received: from dns.dialogic.com by mail.dialogic.com with smtp (Smail3.1.29.1 #1) id m0skstR-000IixC; Tue, 22 Aug 95 08:57 EDT Received: from gigantor (gigantor.dialogic.com) by dns.dialogic.com (5.0/SMI-SVR4) id AA04229; Tue, 22 Aug 1995 08:43:06 +0500 Date: Tue, 22 Aug 1995 08:43:06 +0500 Message-Id: <9508221243.AA04229@dns.dialogic.com> X-Sender: lachacg@mercury X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: info-cvs@prep.ai.mit.edu From: Gerry Lachac Subject: Re: CVS 1.5 ported to Windows NT? Content-Length: 0 Status: RO > Still, it is possible to support CVS on DOS, compiled as a 32-bit >> application, if shorter filenames are used [for CVS control files] While we're on the subject of CVS DOS/NT support, I thought of annother issue. What about LF --> CR/LF conversion? This is probably an RCS issue actually, but in a shared NT/DOS/Unix CVS repository, it would be nice if when you checked/out/in source, a conversion to the target machine format (if necessary) would be done. (i.e. the repository is always stored in one format and the target machine's binaries translate to the native format while checking out and the standard format when checking in.) -gerry =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= EMAIL: G.Lachac@dialogic.com * USMAIL: Dialogic Corp. * Quis custodiet ipsos custodes. 1515 Route 10 Parsippany,NJ * PHONE: (201)993-3000 ext 6193 * From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 22 18:39:36 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA31109 for ; Tue, 22 Aug 1995 18:39:34 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA28638; Tue, 22 Aug 95 13:38:32 EDT Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA28630; Tue, 22 Aug 95 13:38:23 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id MAA28834; Tue, 22 Aug 1995 12:38:16 -0500 Date: Tue, 22 Aug 1995 12:38:16 -0500 From: Jim Blandy Message-Id: <199508221738.MAA28834@totoro.cyclic.com> To: info-cvs@prep.ai.mit.edu Subject: Re: CVS 1.5 ported to Windows NT? In-Reply-To: <9508221243.AA04229@dns.dialogic.com> References: <9508221243.AA04229@dns.dialogic.com> X-Windows: Dissatisfaction guaranteed. Status: RO Gerry Lachac asks: >What about LF --> CR/LF conversion? This is probably an RCS issue actually, >but in a shared NT/DOS/Unix CVS repository, it would be nice if when you >checked/out/in source, a conversion to the target machine format (if >necessary) would be done. The NT CVS client port does CRLF/LF conversion. All files are transmitted in canonical (LF) form, and client and server are responsible for making any conversions necessary at their end. At the moment, the NT port converts all files. Ideally, the user should be able to mark files as binary (i.e. with cvs admin -kb) and have CVS leave them alone; we hope a future contract will allow us to implement this feature. From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 22 20:25:03 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA04830 for ; Tue, 22 Aug 1995 20:24:59 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA01759; Tue, 22 Aug 95 14:26:23 EDT Received: from cygnus.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA01744; Tue, 22 Aug 95 14:26:05 EDT Received: from rtl.cygnus.com (rtl.cygnus.com [140.174.1.2]) by cygnus.com (8.6.12/8.6.9) with ESMTP id LAA29516; Tue, 22 Aug 1995 11:26:03 -0700 From: "J.T. Conklin" Received: (jtc@localhost) by rtl.cygnus.com (8.6.12/8.6.4) id LAA25278; Tue, 22 Aug 1995 11:26:03 -0700 Date: Tue, 22 Aug 1995 11:26:03 -0700 Message-Id: <199508221826.LAA25278@rtl.cygnus.com> To: plb@mdcsc.ca.mdis.com ("Preston L.Bannister") Cc: info-cvs@prep.ai.mit.edu In-Reply-To: plb@mdcsc.ca.mdis.com's message of 22 Aug 1995 06:11:10 -0700 Subject: Re: CVS 1.5 ported to Windows NT? Status: RO >>>>> "Preston" == "Preston L Bannister" writes: Preston> If we did change the filenames, I would suggest placing a Preston> file containing a map of filenames into the CVS directory. Preston> If the map were not present assume the old names. The idea Preston> being that existing users would not do anything to upgrade, Preston> unless they wanted the (new) functionality of interoperating Preston> with DOS users of CVS. I once wrote a client/server version of CVS a few years back. The DOS client had a name-mangling library which would translate names to and from long filenames. This "name database" was stored in the CVS subdirectory with the Entries and Repository files. I didn't bother with the Mac client, since 32 character filenames were considered "long enough" (plus, most of the developers were mac based). This scheme worked pretty well, but there were some problems: The name maps were dynamic, so that the addition and deletion of files, or even the order of file checkout could change the names. This didn't happen often, but when it did Makefiles, etc. had to be changed to reflect the "new" names. It was even worse when the name of a header file was changed. Before the name mapping code was written, I suggested that we modify GNU make and the GNU cpp to use the name mapping library. This was never done, so I don't know how worthwhile that project would be. But with that experience, I think I would just find it easer to use 8.3 monocase filenames and avoid the whole mess. --jtc From info-cvs-ownrr@prep.ai.mit.edu Mon Aug 21 19:40:42 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA23417 for ; Mon, 21 Aug 1995 19:40:41 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA11426; Mon, 21 Aug 95 14:41:29 EDT Received: from relay3.UU.NET by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA11412; Mon, 21 Aug 95 14:41:13 EDT Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQzdty06824; Mon, 21 Aug 1995 14:40:57 -0400 Received: from etnibsd.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Mon, 21 Aug 1995 14:41:09 -0400 Received: by etnibsd.UUCP (4.1/SMI-4.1(VSH)) id AA02303; Mon, 21 Aug 95 13:57:49 EDT From: etnibsd!vsh@uunet.uu.net (Steve Harris) Message-Id: <9508211757.AA02303@etnibsd.UUCP> Subject: Re: is there a way to do a CVS "clean". To: uunet!think.com!dougw@uunet.uu.net (Douglas Wiedemann) Date: Mon, 21 Aug 1995 13:57:48 -0400 (EDT) Cc: info-cvs@prep.ai.mit.edu (CVS Info Maillist) In-Reply-To: <9508181711.AA22439@lion.think.com> from "Douglas Wiedemann" at Aug 18, 95 01:11:52 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7830 Status: RO Douglas Wiedemann writes: > > > Howdy, > > If we have a large directory tree under CVS control, can the CVS user > run something which goes through their checked out tree and deletes > all files not under CVS control? This would be very useful for those > applications where lots of clutter files or log files are routinely > generated. Note that this would be a little different than doing a > commit; rm *; checkout, because it would not disturb the repository. > > Thanks, > Doug Wiedemann > > See "mkcvsclean.pl", attached. Sorry, it's not fully commented. ;-( Do "perl mkcvsclean.pl -?" for usage info. -- Steve Harris - Eaton Corp. - Beverly, MA - vsh%etnibsd@uunet.uu.net #!/usr/local/bin/perl @prog = split(/\//, $0); ($progdir, $prog) = &dbname($0); $here = &getcwd; unless ($progdir =~ m!^/!) { &chdir($progdir); $progdir = &getcwd; &chdir($here); } # pre-usage variable definitions go here @usage_tab = ( # opt arg action descrip # --- --- ------ ------- '?', '', '&usage($verbose=1)', "verbose usage", 'v', '', '$verbose++', "verbose", 't', '', '$trace++', "trace", 'q', '', '$quiet++', "quiet", 'd', '', '$debug++', "debug", 'i', '', '$interactive++', "interactive", 'l', '', '$local++', "do not recurse", # 'T', 'toc', '$toc=$arg', "table of contents for input", # 'L', 'list', '&getlist', "list of words (delimited with '--')", 'U', '', '&usage(1)', "usage (use '-vU' for verbose usage)", '', '[dir...]', '', "dirs to be processed", ); #Verbose description of the command goes here. #It should be preceeded and followed with empty lines $usage_notes = <); return 1 unless $ans =~ /^\s*y(es?)?\s*$/; } return "rmrf"; } unless (open(E,'CVS/Entries')) { &warn("cannot open ${path}CVS/Entries ($!)"); return 1; } %entries = (); while () { chop; s!^/!!; s!/.*!!; $entries{$_} = 1; } unless (opendir(D, '.')) { &warn("unable to opendir $path as '.' ($!)"); return 0; } local(@dirnames); @filenames = sort(readdir(D)); foreach (@filenames) { next if $_ eq '.' || $_ eq '..'; -l $_; # do a symlink &warn("${path}$_ is both a symlink and in Entries"), next if -l $_ && $entries{$_}; &warn("${path}$_ is both a dir and in Entries") if -d _ && $entries{$_}; push(@dirnames,$_), next if -d _; next if $entries{$_}; if ($interactive) { print "remove: ${path}$_ ? "; chop($ans = ); next unless $ans =~ /^\s*y(es?)?\s*$/; } else { print "${path}$_\n" unless $quiet; } &unlink($_) unless $debug; } return 1 if $local; foreach $_ (@dirnames) { next if $_ eq 'CVS'; &chdir($_); $tmp = &dodir("${path}$_/"); &chdir(".."); &rmrf("${path}$_") if $tmp eq "rmrf"; } 1; } sub rmrf { local(@rmrf) = ("rm", "-rf"); $" = ', '; print "system(@rmrf, @_)\n" unless $quiet; $" = ' '; return 1 if $debug; system(@rmrf, @_); 1; } #-------------------------------------------------------------------- # the following is my /usr/local/lib/usage.pl file. # feel free to use it wherever you want. #-------------------------------------------------------------------- package usage; ;#-------------------------------------------------------------------- ;# function parseargs ;# parameters: ;# input: none ;# output: none ;# globals: ;# input: @main'usage_tab, $main'usage_notes, @ARGV ;# output: $main'arg ;#-------------------------------------------------------------------- sub main'parseargs { &parse_usage_tab; ARG: while ($_ = $ARGV[0], /^-/) { shift(@ARGV); last if $_ eq '--'; $n=1; OPT: foreach $opt (split(//,$_)) { next if $opt eq '-'; if ($args{$opt} ne '') { if ($n == length($_)) { unless (@ARGV) { warn("no arg for option '$opt'\n"); $err++; last ARG; } $main'arg = shift(@ARGV); } else { $main'arg = substr($_,$n); } } if (defined($acts{$opt})) { $act = $acts{$opt}; package main; eval($usage'act); die("cannot eval($usage'act):\n\t$@") if $@; package usage; } else { warn("invalid option: $opt\n"); $err++; } last OPT if ($args{$opt} ne ''); # remaining opts snarfed into arg } continue { $n++; } } &main'usage if $err; } sub parse_usage_tab { while ($#main'usage_tab > 0) { $opt = shift(@main'usage_tab); $main'arg = shift(@main'usage_tab); $act = shift(@main'usage_tab); $dsc = shift(@main'usage_tab); $acts{$opt} = $act; $args{$opt} = $main'arg; $tmp = ''; if ($opt && $main'arg) { $tmp = "-$opt $main'arg"; $argopts .= " [$tmp]"; $usage_desc .= "\t$tmp"; } elsif ($opt) { $opts .= $opt; $usage_desc .= "\t-$opt"; } elsif ($main'arg) { $tmp = $main'arg; $progargs .= " $main'arg"; $usage_desc .= "\t$main'arg"; } $usage_desc .= "\n\t" if length($tmp) > 7; $usage_desc .= "\t$dsc" if $dsc; $usage_desc .= "\n"; } } sub main'usage { print "usage: $main'prog"; print " [-$opts]" if $opts; print "$argopts$progargs"; print "\n"; exit(1) unless $_[0]; print "where:\n", $usage_desc if $usage_desc; exit(1) unless $main'verbose; print $main'usage_notes; exit(1); } 1; From info-cvs-ownrr@prep.ai.mit.edu Mon Aug 21 18:08:37 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA06677 for ; Mon, 21 Aug 1995 18:08:30 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA07995; Mon, 21 Aug 95 13:44:05 EDT Received: from mdcsc.ca.mdis.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA07982; Mon, 21 Aug 95 13:43:55 EDT Received: from bannister (pc-plb.ca.mdis.com) by mdcsc.ca.mdis.com (4.1/SMI-4.1) id AA18072; Mon, 21 Aug 95 10:34:32 PDT Message-Id: <9508211734.AA18072@mdcsc.ca.mdis.com> X-Sender: plb@mdcsc.ca.mdis.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Aug 1995 10:43:21 -0700 To: esitler@national.aaa.com (Ed T. Sitler) From: "Preston L.Bannister" Subject: Re: CVS 1.5 ported to Windows NT? Cc: info-cvs@prep.ai.mit.edu Status: RO Ok, I'm impatient. I tried the port for CVS 1.4A2 to Win32 on my home machine (which is running Win95) and it _seems_ to work. Given my lack of familiarity with CVS, that is the strongest statement I'm willing to make. :-) I've looked a bit at the sources. I found sources for: 1. CVS 1.3 base version 2. CVS 1.3 OS/2 (and DOS) port. 3. CVS 1.4A2 Win32 port 4. CVS 1.5 base version (Would have been nice to have the 1.4 base version as well). The changes for Win32 between (3) and (4) seemed to fall into two categories: blocks of code surrounded by #ifdef WIN32, and lots of places where "/" was used as a directory separator replaced by a DIRSEP macro. The #ifdef WIN32 blocks mostly encapsulated behavioral differences. Copying the #ifdef WIN32 blocks of code into 1.5 was fairly straight-forward I was looking at all the places "/" was replaced in the code, and wondering if that was really the right idea. DOS (and Windows NT) is perfectly happy using "/" or "\" was a directory separator. It is only some of the DOS command line utilities that get confused using "/" as a directory separator. It also looked in some places like the file names containing directory separators are written to CVS control(?) files. This could be a bad idea. One of the nice features of RCS is the ability have the RCS version files on an NFS mounted filesystem, and use RCS from either PC's or from Unix. It should be possible to have the same sort of interoperability with CVS. Presumably the Unix version of CVS would _not_ be happy with filenames containing "\" as directory separators. Perhaps it would be better to convert the "\" separators to "/" on input (command line parameters and directory scan?), and convert "/" to "\" only when generating command line parameters (not necessary for RCS?). One of the main changes in CVS 1.3 between (1) and (2) was to use shorter names for CVS control files that fit in the DOS 8.3 format. Now in theory both Windows NT 3.5 and Windows 95 can use longer filenames, so perhaps this is (soon to be) no longer an issue (with perhaps the exception of OS/2?). Still, it is possible to support CVS on DOS, compiled as a 32-bit application, if shorter filenames are used. This means that the Unix version of CVS would have to use the shorter filenames. --- Preston L. Bannister Email : plb@mdcsc.ca.mdis.com CIS : 71350,3505 Phone : (714)724-5724 From info-cvs-ownrr@prep.ai.mit.edu Mon Aug 14 14:21:10 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id OAA08965 for ; Mon, 14 Aug 1995 14:21:09 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA03006; Mon, 14 Aug 95 10:47:41 EDT Received: from mailgate.ericsson.se by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA02990; Mon, 14 Aug 95 10:47:23 EDT Received: from era-t.ericsson.se (era-t.ericsson.se [147.214.76.10]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id QAA01049 for ; Mon, 14 Aug 1995 16:47:14 +0200 Received: from grolsch.ericsson.se by era-t.ericsson.se (4.1/SMI-4.0-LME1.4) id AA23700; Mon, 14 Aug 95 16:46:24 +0200 From: Svante.Signell@era-t.ericsson.se (Svante Signell) Received: by grolsch.ericsson.se (4.1/client-1.3) id AA24913; Mon, 14 Aug 95 16:47:11 DST Date: Mon, 14 Aug 95 16:47:11 DST Message-Id: <9508141447.AA24913@grolsch.ericsson.se> To: info-cvs@prep.ai.mit.edu Subject: CVS remote support for double repositories ? Status: RO Hello, I have a question about the latest release of cvs (1.5) regarding remote support. Reading the documentation cvsclient.texi, the NEWS file and the FAQ and making some experiments, the server/client concept seems to work if ONE common repository is used. Our problem is that we want to use TWO repositories located at different places. Some info about multiple repositories is found in the FAQ. However the FAQ is not up to date with the latest release. We are also aware of rcvs from SLAC, which is not yet updated to support cvs-1.5. My questions are: 1) Can we in some way use the remote support in cvs-1.5 in order to have two repositories syncronized with each other ? 2) Is rcvs the best way to go ? 3) Shall we wait for rcvs updated to support cvs-1.5 ? 4) Will future releases of cvs support multiple repositories ? 5) Are there other workarounds possible using cvs-1.5 ? Regards Svante.Signell@era-t.ericsson.se From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 4 03:50:34 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id DAA20177 for ; Fri, 4 Aug 1995 03:50:34 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA06109; Thu, 3 Aug 95 11:02:03 EDT Received: from server.bridgeway.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA06097; Thu, 3 Aug 95 11:01:44 EDT Received: (from kfh@localhost) by server.bridgeway.com (8.6.9/8.6.9) id IAA07361; Thu, 3 Aug 1995 08:02:10 -0700 Date: Thu, 3 Aug 1995 08:02:09 -0700 (PDT) From: "Karen H." To: info-cvs@prep.ai.mit.edu Subject: Help to define a module Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO I have read all the CVS documents several times (especially the FAQ warning "Expect to feel stupid . . .";-) and done some tests and I still cannot figure out how to do the following: I want to make a cvs module that has a directory structure and only a subset of the files (and sub-dirs) in that directory structure in it. The module name, for example could be S_module. When I do a "cvs checkout S_module" I want cvs to build the following: top_dir/ # I want only some directories in top_dir projects/ # I want only one of the dirs in projects S_project/ # I want all dirs & files in S_project * include/ # I want only select files in include eg1.h eg2.h The following does not work as a line in the modules file, even though I'm sure all of the directories and files are in cvs's control: S_module top_dir projects/S_project include/eg1.h include/eg2.h I get the following error: cvs [checkout aborted]: no such directory `projects' I've tried other permutations. Can CVS do this? If not, is there something "wrong" with this approach? All replies gratefully accepted. From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 11 20:03:30 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA00660 for ; Fri, 11 Aug 1995 20:03:29 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA25654; Fri, 11 Aug 95 13:18:50 EDT Received: from relay1.pipex.net by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA25629; Fri, 11 Aug 95 13:18:24 EDT Received: from mithras.kapiti.co.uk by flow.pipex.net with SMTP (PP); Fri, 11 Aug 1995 18:18:14 +0100 Received: from kampala.kapiti.co.uk by mithras.kapiti.co.uk (4.1/SMI-4.1) id AA05764; Fri, 11 Aug 95 18:15:44 BST Received: by kampala.kapiti.co.uk (5.65/DEC-Ultrix/4.3) id AA28741; Fri, 11 Aug 1995 18:15:43 +0100 Message-Id: <9508111715.AA28741@kampala.kapiti.co.uk> To: info-cvs@prep.ai.mit.edu Reply-To: younga1@kapiti.co.uk Subject: rcs warning/commitlog branch/remote cvs/archive Date: Fri, 11 Aug 1995 18:15:42 +0100 From: Alastair Young Status: RO 4 unrelated questions -> Using Cvs 1.5 I often get this rcs warning % cvs commit -m '4445 aix 4.1.2 fix' cvs commit: Examining . cvs commit: Committing . Checking in sauce_env.; /u5/cvsroot/fist/sauce/sauce_env.,v <-- sauce_env. new revision: 1.40.2.2; previous revision: 1.40.2.1 done rcs warning: No locks are set. <----------- HERE and this warning doesn't appear when committing on the main line. This didn't happen with 1.3 and the commit seems to work ok. Does this indicate a problem? -------------------------------------------------- In the commit log I sometimes get a line like Revision/Branch: fist440 but sometimes not, even though its been committed on a branch. I thought it might be that sometimes a 'cvs commit' is done and other times a 'cvs commit -r branch' is done (by a script), but I'm not so sure it ties up now. It would be nice to have this message reliably in the log. This may be a bug. -------------------------------------------------- When using remote cvs if I do cvs co fred/fred.c where fred is a module that contains some files (including fred.c), it checks out all files in the module fred (recursively), whereas non-remote cvs checks out just the one file (as expected). This may also be a bug, or can it be done another way? -------------------------------------------------- I think this question may have been asked recently... Is there an archive of this list anywhere? (preferably in http) (if so, this could be one for the faq/mini-faq) -------------------------------------------------- +--------------------------------------------------------+ | Alastair Young Tel: +44 1753 573244 | | Kapiti Ltd. Fax: +44 1753 575964 | | Slough | | England Email: Alastair.Young@kapiti.co.uk | +--------------------------------------------------------+ From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 11 19:35:21 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA26693 for ; Fri, 11 Aug 1995 19:35:20 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA21110; Fri, 11 Aug 95 12:02:00 EDT Received: from mailgate.ericsson.se by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA20886; Fri, 11 Aug 95 11:57:29 EDT Received: from era-t.ericsson.se (era-t.ericsson.se [147.214.76.10]) by mailgate.ericsson.se (8.6.11/1.0) with SMTP id RAA22149 for ; Fri, 11 Aug 1995 17:30:44 +0200 Received: from grolsch.ericsson.se by era-t.ericsson.se (4.1/SMI-4.0-LME1.4) id AA00873; Fri, 11 Aug 95 17:29:59 +0200 From: Svante.Signell@era-t.ericsson.se (Svante Signell) Received: by grolsch.ericsson.se (4.1/client-1.3) id AA15967; Fri, 11 Aug 95 17:30:41 DST Date: Fri, 11 Aug 95 17:30:41 DST Message-Id: <9508111530.AA15967@grolsch.ericsson.se> To: info-cvs@prep.ai.mit.edu Subject: Tempdir used by CVS ? Status: RO Hello, A question about what tempdir is used by different CVS commands: After a commit of a file the editor pointed to by the EDITOR environment variable is invoked, in my case Emacs. My problem is that the temporary file created is written to /usr/tmp, an area that often does not have much space left. When no disk space is left I get the following output from cvs: Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) After reading the manual one get the impression that the TMPDIR environment variable overrides the compiled in value by using a call like: char *temp_dir = getenv ("TMPDIR"); Scanning through the source files one finds that commit.c and import.c uses the default /tmp for temporary files while server.c uses /usr/tmp. Questions: 1) If I am not using remote path for CVSROOT is the program server invoked ? 2) Is /usr/tmp specified somewhere else ? (We are using Perl, i.e. log.pl is in $CVSROOT/CVSROOT) 3) What commands uses some kind of temporary files? 4) Should'nt TMPDIR override compiled in values? 5) Where is the commentary text coming from when using the editor for commit logs? My guess is logmsg.c 6) Have I missed something ? Regards, Svante.Signell@era-t.ericsson.se Computer: sparc-sun-sunos4.1.3 Compiler: gcc-2.6.3 RCS-version: 5.7 CVS-version: 1.5 From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 11 18:26:17 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA00324 for ; Fri, 11 Aug 1995 18:26:16 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA21512; Fri, 11 Aug 95 12:10:49 EDT Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AB21491; Fri, 11 Aug 95 12:10:37 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id LAA20024; Fri, 11 Aug 1995 11:10:36 -0500 Date: Fri, 11 Aug 1995 11:10:36 -0500 From: Jim Blandy Message-Id: <199508111610.LAA20024@totoro.cyclic.com> To: info-cvs@prep.ai.mit.edu Subject: Tempdir used by CVS ? In-Reply-To: <9508111530.AA15967@grolsch.ericsson.se> References: <9508111530.AA15967@grolsch.ericsson.se> X-Windows: graphics hacking :: Roman numerals : sqrt (pi) Status: RO Svante Signell asks: >4) Should'nt TMPDIR override compiled in values? Yes, TMPDIR should always override compiled-in values. The filename that's causing you trouble is created in do_editor in logmsg.c, by calling the tmpnam function. Does your system's documentation claim that tmpnam respects TMPDIR? If it doesn't, then that's the problem. From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 11 07:45:48 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id HAA26945 for ; Fri, 11 Aug 1995 07:45:48 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA01127; Fri, 11 Aug 95 02:45:25 EDT Received: from metro.ucc.su.OZ.AU by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA01071; Fri, 11 Aug 95 02:44:42 EDT Received: from mama.research.canon.oz.au by metro.ucc.su.OZ.AU with MHSnet id AA05778 (5.65c/IDA-1.4.4 for info-cvs@prep.ai.mit.edu); Fri, 11 Aug 1995 16:43:58 +1000 Received: from miles.research.canon.oz.au (miles.research.canon.com.au) by mama.research.canon.oz.au with SMTP id AA18687 (5.65c8/IDA-1.5); Fri, 11 Aug 1995 13:26:27 +1000 Received: by miles.research.canon.oz.au (NX5.67d/NX3.0S) id AA25758; Fri, 11 Aug 95 13:26:25 +1000 From: Graham Stoney Message-Id: <9508110326.AA25758@miles.research.canon.oz.au> Subject: Re: CVS 1.3 -> 1.5 (or 1.6) compatability? To: awasser@hermes.sgc.com (Adam Wasserman) Date: Fri, 11 Aug 1995 13:26:24 +1000 (GMT+1000) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9508101439.AA21564@hermes> from "Adam Wasserman" at Aug 10, 95 10:39:48 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 662 Status: RO Adam Wasserman writes: > My company is currently using CVS v1.3 with an old version of rcs (I > believe 5.6 circa late 1992). I'm exploring upgrading to CVS 1.5/6 > and rcs 5.7. We have a large group of repositories we need to > continue to use with the new versions. > > Are the repositories portable to the new versions of the tools? Yes, and if you don't use any of the new rcs features, the files should be backward compatible with your old version of rcs. > Is > there any work involved other than installing the new software? Or is > there some conversion procedure which is necessary? No, and no. Overall, it just works. Regards, Graham From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 23 00:09:30 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id AAA13889 for ; Wed, 23 Aug 1995 00:09:29 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA13774; Tue, 22 Aug 95 17:42:14 EDT Received: from mdcsc.ca.mdis.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA13575; Tue, 22 Aug 95 17:40:38 EDT Received: from bannister (pc-plb.ca.mdis.com) by mdcsc.ca.mdis.com (4.1/SMI-4.1) id AA28461; Tue, 22 Aug 95 14:30:09 PDT Message-Id: <9508222130.AA28461@mdcsc.ca.mdis.com> X-Sender: plb@mdcsc.ca.mdis.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Aug 1995 14:39:13 -0700 To: "J.T. Conklin" From: "Preston L.Bannister" Subject: Re: CVS 1.5 ported to Windows NT? Cc: info-cvs@prep.ai.mit.edu Status: RO At 11:26 AM 8/22/95 -0700, J.T. Conklin wrote: >>>>>> "Preston" == "Preston L Bannister" writes: >Preston> If we did change the filenames, I would suggest placing a >Preston> file containing a map of filenames into the CVS directory. >Preston> If the map were not present assume the old names. The idea >Preston> being that existing users would not do anything to upgrade, >Preston> unless they wanted the (new) functionality of interoperating >Preston> with DOS users of CVS. > >I once wrote a client/server version of CVS a few years back. The DOS >client had a name-mangling library which would translate names to and >from long filenames. This "name database" was stored in the CVS >subdirectory with the Entries and Repository files. I didn't bother >with the Mac client, since 32 character filenames were considered >"long enough" (plus, most of the developers were mac based). As an aside, if there was a "name database" for mapping file names, this could also be used to allow files to be renamed or moved to different directories between releases. --- Preston L. Bannister Email : plb@mdcsc.ca.mdis.com CIS : 71350,3505 Phone : (714)724-5724 From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 25 09:16:55 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA22288 for ; Fri, 25 Aug 1995 09:16:54 -0400 Date: Fri, 25 Aug 1995 09:16:54 -0400 From: info-cvs-ownrr@prep.ai.mit.edu Message-Id: <199508251316.JAA22288@jupiter.cs.uml.edu> Apparently-To: Status: RO Just a few thoughts to let you know somebody's reading. :-) > Still, doing it this way has the advantage that the repository files > are created in the correct place and all of the history is there. I just > hope that in 1.6 > > 1 if you are working on branch xyz in directory def and > create and add file abc, that CVS creates repository file > $CVSROOT/.../def/abc,v > instead of > $CVSROOT/.../def/Attic/abc,v > (as it seems to now) I think this makes sense since if you remove a file and it no longer exists on main it is moved into the attic. In this case, you are adding a file that doesn't yet exist on the main branch so shouldn't it too go into the attic? I guess I don't have a problem with this. > 2 that someone doing a "cvs update" on the main or other branch > will not see the new abc file until ... > > 3 a "cvs update -j xyz" in def will correctly add the new file to > whatever branch (other or main) that the user is working on, > causing def/abc to appear. In my experience this _is_ the way cvs 1.5 works. If you do the cvs update -j xyz then the file will get locally added to your tree. A cvs commit then causes a new revision to get created and the file is moved out of the attic like you would expect. The only thing weird is that the new version on the main is 1.2 since 1.1 had to be created in order to branch the initial version, but I think this is acceptable. One thing that I am wondering after reading your note is if the use of a CVS attic still makes sense now that we have Death Support in cvs 1.5. Would setting the state on a version to dead be sufficient? Seems like a lot cleaner approach than moving files around all the time. Anyway, let me know if I totally missed the point above. :-) Kirby --- Kirby Koster, koster@sctc.com From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 24 18:36:36 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA03853 for ; Thu, 24 Aug 1995 18:36:35 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA01969; Thu, 24 Aug 95 12:13:16 EDT Received: from harvey.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA01946; Thu, 24 Aug 95 12:12:54 EDT Received: (from kingdon@localhost) by harvey.cyclic.com (8.6.9/8.6.9) id MAA00345; Thu, 24 Aug 1995 12:13:24 -0400 Date: Thu, 24 Aug 1995 12:13:24 -0400 From: Jim Kingdon Message-Id: <199508241613.MAA00345@harvey.cyclic.com> To: webb@ctiole.ctio.noao.edu Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9508241541.AA03651@ctiole> (webb@ctiole.ctio.noao.edu) Subject: Re: adding directories in tagged directories Status: RO 1 if you are working on branch xyz in directory def and create and add file abc, that CVS creates repository file $CVSROOT/.../def/abc,v instead of $CVSROOT/.../def/Attic/abc,v Whether it goes in Attic or not is not a user-visible behavior, so I can't think of any need to change this. Right now it is in Attic if the main branch head revision is dead, or out of Attic if the main branch head revision is live. 3 a "cvs update -j xyz" in def will correctly add the new file to whatever branch (other or main) that the user is working on, causing def/abc to appear. Kirby Koster just wrote a patch to avoid dumping core in this case, which has been checked in, so 1.6 will be a minor improvement. But to fix it to actually behave correctly someone has to get around to writing the code to fix it. If you care about this, I would recommend writing and submitting a fix (or hiring someone to do it for you). From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 24 17:02:38 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA00178 for ; Thu, 24 Aug 1995 17:02:38 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA00284; Thu, 24 Aug 95 11:42:20 EDT Received: from noao.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA00277; Thu, 24 Aug 95 11:42:09 EDT Received: from ctiole (ctiole.ctio.noao.edu) by noao.edu (4.1/SAG-Noao.G102) id AA23133; Thu, 24 Aug 95 08:42:03 MST; for info-cvs@prep.ai.mit.edu Received: by ctiole (4.1/JBH.4) id AA03651; Thu, 24 Aug 95 11:41:58 CST Date: Thu, 24 Aug 95 11:41:58 CST From: webb@ctiole.ctio.noao.edu (gary webb x240) Message-Id: <9508241541.AA03651@ctiole> To: wahle@dlger.cr.usgs.gov Subject: adding directories in tagged directories Cc: info-cvs@prep.ai.mit.edu Status: RO Jo, No you aren't doing anything wrong, CVS is. We ran into the same problem with 1.4A2 and hoped it would be fixed with 1.5. It is not just directories but also files, and the temporary solution is to add them to the main branch first. But I hope that 1.6 fixes the problem so that files/directories can be added to the branch under development and then merged into the main branch without errors or erroneous placement of the RCS files into the Attic. Anyway, for the moment, I have asked my co-workers to do the following: ----------------------------------------- They are working on branch xyz and wish to add new file/directory abc: cvs commit # save the current state of the branch cvs update -A # forget all sticky tags (create a stub for the file/directory if it doesn't exist yet) (using touch for files and mkdir for directories ) cvs add abc # add it to the main branch cvs commit -m "new files for branch xyz" cvs tag -b xyz abc # add it to branch xyz cvs update -r xyz # return to working on branch xyz (make any changes to abc) cvs commit # put the real file/directory on the branch ---------------------------------------------- This conflicts with a dictum from high management that says "Thou shalt not add anything onto the main branch until it has been tested and approved", but fortunately our intermediate management is willing to listen to reason. And of course with directories, it is even uglier, since what you have to do is add stubs for each of the files you are planning on creating (but then we all design well enough that we know what files we will create, right? ;-) Still, doing it this way has the advantage that the repository files are created in the correct place and all of the history is there. I just hope that in 1.6 1 if you are working on branch xyz in directory def and create and add file abc, that CVS creates repository file $CVSROOT/.../def/abc,v instead of $CVSROOT/.../def/Attic/abc,v (as it seems to now) 2 that someone doing a "cvs update" on the main or other branch will not see the new abc file until ... 3 a "cvs update -j xyz" in def will correctly add the new file to whatever branch (other or main) that the user is working on, causing def/abc to appear. Gary Lee Webb Cerro Tololo Interamerican Observatory La Serena, Chile From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 24 21:27:45 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id VAA19493 for ; Thu, 24 Aug 1995 21:27:44 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA14901; Thu, 24 Aug 95 15:56:45 EDT Received: from harvey.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA14884; Thu, 24 Aug 95 15:56:34 EDT Received: (from kingdon@localhost) by harvey.cyclic.com (8.6.9/8.6.9) id PAA00493; Thu, 24 Aug 1995 15:57:24 -0400 Date: Thu, 24 Aug 1995 15:57:24 -0400 From: Jim Kingdon Message-Id: <199508241957.PAA00493@harvey.cyclic.com> To: webb@ctiole.ctio.noao.edu Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9508241919.AA04327@ctiole> (webb@ctiole.ctio.noao.edu) Subject: Re: adding directories in tagged directories Status: RO > One question though... what do you mean by the > main branch head revision being dead or alive ? Forget what you knew about 1.4A2; in 1.5 each revision (not each file as in 1.4A2) can be dead (non-existent) or alive (existent). Look in the sources for DEATH_SUPPORT ifdefs or other clues. > You know much better than I, o guru (it's your code!). Uh, no, it isn't "my" code. It "belongs" to the people who are willing to do the work of maintaining it (appearances to the contrary notwithstanding I am not the only such person, nor am I the only person who checks stuff into the master repository). > Any estimates? If you are thinking of hiring someone who is in the business of selling CVS support, I'm sure they'd be willing to quote you a price for a support contract and/or a specific enhancement. Other than that no estimates (not from me, anyway). From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 24 22:46:33 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA06464 for ; Thu, 24 Aug 1995 22:46:28 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA13176; Thu, 24 Aug 95 15:19:59 EDT Received: from noao.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA13164; Thu, 24 Aug 95 15:19:47 EDT Received: from ctiole (ctiole.ctio.noao.edu) by noao.edu (4.1/SAG-Noao.G102) id AA29862; Thu, 24 Aug 95 12:19:38 MST; for info-cvs@prep.ai.mit.edu Received: by ctiole (4.1/JBH.4) id AA04327; Thu, 24 Aug 95 15:19:36 CST Date: Thu, 24 Aug 95 15:19:36 CST From: webb@ctiole.ctio.noao.edu (gary webb x240) Message-Id: <9508241919.AA04327@ctiole> To: kingdon@harvey.cyclic.com Subject: Re: adding directories in tagged directories Cc: info-cvs@prep.ai.mit.edu Status: RO > From kingdon@harvey.cyclic.com Thu Aug 24 12:12:57 1995 > Date: Thu, 24 Aug 1995 12:13:24 -0400 > From: Jim Kingdon > To: webb@ctiole.ctio.noao.edu > Cc: info-cvs@prep.ai.mit.edu > Subject: Re: adding directories in tagged directories > Content-Length: 952 > > > 1 if you are working on branch xyz in directory def and > create and add file abc, that CVS creates repository file > $CVSROOT/.../def/abc,v > instead of > $CVSROOT/.../def/Attic/abc,v > > Whether it goes in Attic or not is not a user-visible behavior, so I > can't think of any need to change this. Right now it is in Attic if > the main branch head revision is dead, or out of Attic if the main > branch head revision is live. > > 3 a "cvs update -j xyz" in def will correctly add the new file to > whatever branch (other or main) that the user is working on, > causing def/abc to appear. > > Kirby Koster just wrote a patch to avoid dumping core in this case, > which has been checked in, so 1.6 will be a minor improvement. But to > fix it to actually behave correctly someone has to get around to > writing the code to fix it. If you care about this, I would recommend > writing and submitting a fix (or hiring someone to do it for you). > OK, I stand corrected: apparently the behavior HAS changed from 1.4A2 to 1.5 . We had hoped it had, but not tried it, and I read Jo Wahle's e-mail to say that it had not. In revision 1.4A2, our experience was as follows. One of our programmers made a number of changes including new files on a branch, added and committed them there. He then tried to copy (unix cp) the new files to a directory containing the main branch and add them, but the new files would not add (they were already added). On the other hand he could not check them out, either. And on investigation, we discovered that the repository files were in the Attic -- apparently in 1.4A2 if you are working on branch xyz in directory def and create and add file abc, that CVS creates repository file $CVSROOT/.../def/Attic/abc,v as I wrote. And we found no way of getting it to appear in the main branch other than erasing the repository file, erasing the line in Entries, and adding the file to the main branch first! But if you say that the RCS file now goes in the correct directory in 1.5, when the file is added to the branch first, I'll happily take your word for it. One question though... what do you mean by the main branch head revision being dead or alive ? The file in this case has not been added to the main branch yet -- so how does it have a head revision? And it certainly has not been removed, so it shouldn't be dead. So perhaps that is (was?) the problem: rather than dead or alive, by adding it on the branch first, the head revision of his files were simply "non-existant". And yes, since I do think that one should be able to add files to a branch first, I'll add "spend the time to learn the CVS code so that I may write and submit a fix" to my list of things to do. Sounds like fun! But please don't wait on me -- my bosses have me booked through October 1996. On the other hand, if they really want a policy of "Thou shalt not add anything onto the main branch until it has been tested and approved" then I could insist that to implement said policy I would need to spend the time and get a fix approved... (hmmm...). If the file logic only supports dead/alive now, I would guess that going to dead/alive/not-yet-in-main is a first step. Or at least putting in a reasonable first revision code: despite being "in the branch", the revision numbers had two parts instead of four. You know much better than I, o guru (it's your code!). Any estimates? Gary Lee Webb From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 23 19:59:28 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA04079 for ; Wed, 23 Aug 1995 19:59:27 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA22833; Wed, 23 Aug 95 10:32:58 EDT Received: from sunl.cr.usgs.gov by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA22823; Wed, 23 Aug 95 10:32:50 EDT Received: from dlger.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2) id AA17042; Wed, 23 Aug 95 09:32:49 CDT Received: by dlger.cr.usgs.gov (5.4R2.01/1.34) id AA10801; Wed, 23 Aug 1995 09:15:31 -0500 Date: Wed, 23 Aug 1995 09:15:29 -0500 (CDT) From: Jo Wahle To: info-cvs@prep.ai.mit.edu Subject: adding directories in tagged directories Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO We've been making extensive use of tags to coordinate CVS-controlled code among quite a few developers. This is working okay (not great), but we have a problem adding directories. When someone executes "cvs add ", there is a message, "using per-directory sticky tag ", then when the developer goes into the new directory and executes "cvs add " and "cvs commit", the new files are put into the _Attic_, on a _branch_ with that tag. So far I've come up with two solutions: 1. In the parent of the new directory, the developer must do "cvs update -A" to bring the entire directory up-to-date and forget sticky tags. This is often undesirable. 2. After adding the new directory, execute "cvs tag -d ", then "cvs update -A ". Then go into the directory and add the files. We're using CVS 1.5. Suggestions? Explanations? Something we're doing wrong? Thanks! ====================================================================== || Make 'em think you're crazy: || --Jo || || "Practice random acts of kindness || Software Developer || || and senselss acts of beauty." || wahle@dlger.cr.usgs.gov || || -- Anne Herbert, 1990 || Hughes STX (EROS Data Ctr) || ====================================================================== Disclaimer -- Ideas expressed here are my own and not those of Hughes STX nor of the government ... etc., etc. ... (If this had been an official document representing either entity, you would know it!) ====================================================================== From info-cvs-ownrr@prep.ai.mit.edu Fri Aug 25 20:46:20 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA16756 for ; Fri, 25 Aug 1995 20:46:19 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA07640; Fri, 25 Aug 95 17:04:08 EDT Received: from sunl.cr.usgs.gov by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA07627; Fri, 25 Aug 95 17:03:59 EDT Received: from dlger.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2) id AA16516; Fri, 25 Aug 95 16:03:52 CDT Received: by dlger.cr.usgs.gov (5.4R2.01/1.34) id AA13301; Fri, 25 Aug 1995 15:46:25 -0500 Date: Fri, 25 Aug 1995 15:46:24 -0500 (CDT) From: Jo Wahle To: Tony.Lill@ajlc.waterloo.on.ca Cc: info-cvs@prep.ai.mit.edu Subject: Re: adding directories in tagged directories In-Reply-To: <199508251557.PAA29962@matrix.ajlc.waterloo.on.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Fri, 25 Aug 1995, Anthony J. Lill wrote: > > I agree that adding files in src/foo,v instead of src/Attic/foo,v is > dead wrong (sorry, couldn't resist). A branch is meant to be a > sequestered environment, usually used to support released code, while > the main trunk is a developers free-for-all. If you add something to > this environment, I wouldn't expect it to be visible anywhere else. > Trouble is, I was never referring to a branch. I was referring to the main trunk, where we'd given a tag as a way to "freeze" the repository at that point. There are no branches involved in this case. It was very confusing when I added files/directories to a local directory that was all "main trunk" stuff, and CVS put the new files on a branch. And then in the Attic too! Also, since the tag identified to a freeze/snapshot, I did _not_ want the new files to have that tag, because they did not exist at the time of that snapshot. I've gotten several responses, and some of them seem to explain what happened. Whether the behavior of automatically tagging (and branching) new files is a bug, or we're making poor use of CVS at our site, I'm not sure. (Well, I know the latter is true. Not sure about the former. :-) ) ====================================================================== || Make 'em think you're crazy: || --Jo || || "Practice random acts of kindness || Software Developer || || and senselss acts of beauty." || wahle@dlger.cr.usgs.gov || || -- Anne Herbert, 1990 || Hughes STX (EROS Data Ctr) || ====================================================================== Disclaimer -- Ideas expressed here are my own and not those of Hughes STX nor of the government ... etc., etc. ... (If this had been an official document representing either entity, you would know it!) ====================================================================== From sre@jrcase.mq.edu.au Wed Aug 23 20:19:15 1995 Received: from dishwasher1.mpce.mq.edu.au (dishwasher1.mpce.mq.edu.au [137.111.216.16]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id UAA27637 for ; Wed, 23 Aug 1995 20:19:09 -0400 Received: from (localhost.mpce.mq.edu.au [127.0.0.1]) by dishwasher1.mpce.mq.edu.au (8.6.9/8.6.9) with SMTP id KAA18406; Thu, 24 Aug 1995 10:03:40 +1000 Date: Thu, 24 Aug 1995 10:03:40 +1000 Message-Id: <303B83C9@hqmssmtp1.nwest.mccaw.com> Errors-To: didar@macadam.mpce.mq.edu.au Reply-To: sre@jrcase.mq.edu.au Originator: sre@jrcase.mq.edu.au Sender: sre@jrcase.mq.edu.au Precedence: bulk From: Mark Adolph To: Multiple recipients of list Subject: [SRE:331] RE: SRE in Wonderland X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Software Requirements for Engineering Mailing List X-Mailer: Microsoft Mail V3.0 Status: RO On Tuesday, August 22, 1995, Andrew Gabb (apg@itd.dsto.gov.au) wrote: > Here I stress the point that the specification is ALWAYS an inadequate > representation of the users' needs. It is ALWAYS incomplete, because the > genuine requirements are conceptual and can't be adequately expressed in any > language or representation. I also agree that the developer must eventually > have an complete (to his satisfaction) statement of requirements to work to, > and to test against, at some stage. Is this statement really true? Are these conceptual requirements truly impervious to unambiguous elucidation? As it has been stated, after all, all requirements eventually boil down to code, documents, and procedures. The developers employ some transformation to go from the requirements to these deliverables. Is it truly impossible to document this transformation before the fact, or even after? I have done a lot of work in the theatre, specifically stage lighting. Creation of a specific series of "looks" or "moods" onstage is one of the least concrete activities that I can imagine, yet theatrical lighting designers have developed a standard set of deliverables which can enable a lighting crew to create the intended product. And they often do this, I might note, in the face of union rules which prohibit the designer from even touching a light, wrench, or wire. In fact, some designers never show up in person at the theatre until the work is largely done, and then they just come to fine tune the whole. What can we learn from that seemingly unrelated activity? From my experience, directors often know what "look" they want, but few can describe that in terms of specific lighting instruments, intensities, angles, and colors. That is the lighting designer's job. Few directors review the lighting design documents, but all view the final product and make suggestions. How do lighting designers explain to the director what they will do before they do it? In a compromise between the director's and lighting professionals' terms. They say, "We'll bring up a warm wash from the left with just a touch of cool fill on that sofa, and a spot around that lamp," rather than "We'll install 13 1000 watt 8x16's on these two house pipes, install a Roscolux Bastard Amber, and bring them up to 8 on the dimmers..." These are unnecessary details. It's also interesting to note that lighting designs include a combination of diagrams and text to describe the three dimensional volume of light and the set of lighting crew activities. There is some redundancy among these documents, but each also supplies the part of the to which it is best suited. There is specialization among lighting crews. Designers deal with the director and scene designer, and they design. Master Electricians and their crews hang and focus. The Lighting Run crew runs the performances under the direction of the Stage Manager. Master Electricians don't design; if they do, they're called Designers while they're doing it. And nobody expects the follow-spot operator to understand the director's overall vision; he's expected to follow the cue sheet he receives. If the show ends up looking like crap, people blame the designer and no one else (except perhaps the director). Finally, even if there are a few things that could still be improved, the show opens on opening night. Nobody *ever* "slides" the opening of a show. In short, the theatre lighting community has managed to take a very fuzzy, very conceptual activity and broken it down into a series of familiar, repeatable steps. The creative activity, the leap from vision to lighting plot occurs within one person: the lighting designer, who occupies the same role in the process that we do as requirements engineers. But he manages to document the results of that activity quite cleanly. Software is more complex, because the final product must deal gracefully with a far larger set of possibilities. Therefore, one would expect the documentation to be proportionally more complex as well. But can it be written? Eventually, I believe that we'll find that it can. After all, the first theatre with indoor lighting, the Savoy in London, was only built late last century. They don't have too big a head start. Mark C. Adolph AT&T Wireless mark.adolph@mccaw.com From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 29 21:20:13 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id VAA25714 for ; Tue, 29 Aug 1995 21:20:12 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA26267; Tue, 29 Aug 95 17:34:38 EDT Received: from solen.gac.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA26214; Tue, 29 Aug 95 17:34:17 EDT Received: from gac.edu (guenther@lunen.gac.edu [138.236.128.17]) by solen.gac.edu (8.6.12/8.6.12) with ESMTP id QAA19087 for ; Tue, 29 Aug 1995 16:34:17 -0500 Message-Id: <199508292134.QAA19087@solen.gac.edu> To: info-cvs@prep.ai.mit.edu Subject: Re: more branches and merging Date: Tue, 29 Aug 1995 16:33:52 -0500 From: Philip Guenther Status: RO (I first mailed this just to Dave, but realized that it would be Good Thing (tm) if other people can jump in (or on) and correct my errors, argue against my dialectic, or suggest better punishments than the breaking of legs. -Philip) Dave Norton wrote: >Several people have written (and many thanks for your responses) to >say that in merging of files, there needs to be some space around the >changes for cvs to pick up the right context - that doesn't seem to >help the situation at all, though. > >here is an example: > >main trunk has a file "aaa" with the contents: >aaaaaaaaaa > > >and the branch "dave" has a file (the contents of which are also in >the working directory) that has: >aaaaaaaaaa >3333333333 >4444444444 > > >the branch "tim" has a file with the contents: >aaaaaaaaaa >3333333333 >4444444444 > / > <========== lots of space here > \ >aaaaaaaaaa >1111111111 >2222222222 RCS Rule #5692) White space is not special. Whitespace is just another string of characters as far as RCS is concerned. When whoever (I don't _think_ it was me) said you needed "some space around the changes", he or she didn't mean white space, but rather source that's unchanged between the branchpoint and the head of each branch. For example, if in file "bbb" you have: bbbbbbbbbb cccccccccc and branch "dave"'s version contains: bbbbbbbbb 111111111 ccccccccc while branch "tim"'s version has: bbbbbbbbb 111111111 ccccccccc aaaaaaaaa 555555555 then they will merge in the desired fashion. This makes sense if you look at the diffs from the base version. In your example, each branch is a one piece diff from the base version, and these two pieces differ. In the example above, one branch ("dave") is a one piece diff from the base version, while the other ("tim") is a two piece diff *AND THE FIRST PIECE IS IDENTICAL TO dave's PIECE*. >from the working directory (which again looks the same as branch dave) >I do a: >cvs update -jtim aaa > >and get the following: > >aaaaaaaaaa ><<<<<<< aaa >3333333333 >4444444444 > >======= >3333333333 >4444444444 > > > >aaaaaaaaaa >1111111111 >2222222222 >>>>>>>> 1.1.1.1.6.2 > > >Am I really thick? I don't quite understand why there is a conflict >in the merge. It looks like, as suggested by one person, I'll have to >dig into rcs and see what is going on with the merge operation that >cvs calls. One branch added 3 lines, the other added 8 lines, and they both added in the same place. That a conflict. The fact that one addition subsumes the other is not detected by merge, and is therefore doesn't matter. If merge *did* detect when one addition contained another, it would be very dangerous, as such a situation isn't always conflictless. merge has to walk a line between too conservative (flag every change by either) and too liberal (smash the changes together, even where they overlap). When in doubt, as it is here, merge is conservative, as only a human (and in particular one who understands the file in question) can understand the nuances of the merge. >If anyone knows how I can bring my working copy up to date with the >"tim" branch without essentially doing it all by hand - please drop a >line. I repeat: it is a bad idea for two seperate branches to make the same primary change (by 'primary' I mean by hand, as opposed to merging a change from one branch to another). If it's so important that every working copy needs the change, it should have been commited by itself (preferable on the trunk, though a branch will do), then each working copy updated. If someone else made the *exact* same change, it will merge without conflict. If they haven't touched those sections, it will merge with out conflict. If they have touched those section for whatever reason, it will provoke a conflict, which is _good_! If they made a similar change (to fix the same problem), they need to remove their fix, while if it's a different problem, they need to at least determine which side of the merged fix their changes should go one (before or after). The only case that loses is if they have made the exact same fix, _and_ other changes (as in your example). The problem is that it is extremely hard to distinguish this case from when the changes aren't exactly the same (i.e., if the merged version contained two changes, and only one of those was done to the working copy). By creating an intermediate version containing just the common changes you give merge someway to determine what branch specific, and thus can perform the merges so as to avoid most of the conflicts. The differance between merging the intermediate 'common' change onto the trunk versus a branch, is that if you put it on the trunk, then everyone *has* to do the update before they can commit anything, while if it's on a branch, they can commit with merging. Depending on you local management techniques for getting branches merged in, one may be preferable to the other. You just have to be careful with the second, as its one more branch lying around to confuse people (do not under estimate the ability of people to get confused in the presence of multiple branches). In fact, I would say that making it a seperate branch should *only* be done if someone (you?) is ready, willing and able to take responsibility for the resulting merge. When you start, you should make sure that everyone has commited, then as soon as you have commited a final version containing all the changes, have them update. If they make more changes against old revisions, you'll end you strangling them. That warning given, here's a sketch of how to do it: Given a tree of revisions like this: Common changes +----------------+ --------| Tag: COMMON | / +----------------+ / / Set one. Includes Desired result. Includes / common changes both DAVE and TIM changes. +------+ +-------------+ +----------------+ | BASE |-------| Tag: DAVE |---------| | +------+ +-------------+ +----------------+ \ \ Set two. Includes \ common changes \ +-------------+ -------| Tag: TIM | +-------------+ Where DAVE was the last revision commited to the trunk (which means it was probably commited before TIM). cvs update -A # Fetch DAVE cvs update -jCOMMON -jTIM # Do the merge emacs * # Fix any conflicts that did occur cvs commit -m 'Merge of TIM and DAVE' cvs tag TIM_AND_DAVE # go around and make people do an update -A, especially Tim, and Dave Yeah, that looks simple, but if there are other intermediate versions on the branchs with TIM and DAVE, things can look more complicated then they are, and if you don't have COMMON, you suddenly find a huge number of conflicts. Conflicts can still occur (of course), but merging using the COMMON version should cut down on the number of conflicts surrounding the common changes. Note that TIM can just as well be a later version on the same branch as COMMON (i.e., Tim the person created the branch at base, commited the COMMON version on that branch, then did some more hacking and commited TIM on that same branch). The procedure's the same, but cvs/rcs has less work to do, and it actually makes sense, instead of looking like COMMON was pasted on afterwards. The same is true if COMMON is on the main branch (between BASE and DAVE), but that would seem to imply that Tim commited to a branch to avoid doing a merge. First break one of his knees (and tell him that if he uses cvs tag -b again you'll break his other one), then do the merge the same way. As a safety against my being totally confused (it's been known to happen), read section 4C of the FAQ, especially 4C.5, 4C.10 and 4C.14. (The selection may be me sermonizing again.) Philip Guenther ---------------------------------------------------------------- Philip Guenther UNIX Systems and Network Administrator Internet: guenther@gac.edu Phonenet: (507) 933-7596 Gustavus Adolphus College St. Peter, MN 56082-1498 I am _not_ a representative sample of the Gustavus Community. Yeah, right... Source code never lies (it just misleads). (Programming by Purloined Letter?) From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 31 17:19:43 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA27076 for ; Thu, 31 Aug 1995 17:19:42 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA27878; Thu, 31 Aug 95 10:36:47 EDT Received: from zazu.c3.lanl.gov by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA27866; Thu, 31 Aug 95 10:36:36 EDT Received: (krk@localhost) by zazu.c3.lanl.gov (8.6.10/c93112801) id IAA10477; Thu, 31 Aug 1995 08:36:22 -0600 Date: Thu, 31 Aug 1995 08:36:22 -0600 From: Kenneth R Koch Message-Id: <199508311436.IAA10477@zazu.c3.lanl.gov> To: info-cvs@prep.ai.mit.edu, immel@centerline.com Subject: Re: Removing Directories Status: RO Mark Immel writes: > > Folks -- > > OK, I feel like a moron here. (And, of course, that may mean that > this is a FAQ, but I couldn't find the answer, which would make me but > more of a moron. In that case, just point me to the answer, and I'll > hang my head...) > > How do you remove a directory from a CVS project? > > I'm using a remote repository. I cvs remove'd all source files from > the directory. I then cvs remove'd the directory. The server > responded in a positive fashion. But, a subsequent checkout included > the directory. I then tried rmdir'ing the directory, before cvs > removing it, but this caused an "Can't chdir to directory" message. > What's up here? > > -- > Mark Immel > immel@centerline.com > (202) 393-7833 (office) > (617) 498-3409 (voicemail) CVS must still maintain historical versions in the repository, so it can never "remove" its version of that directory. You have 2 choices: 1) use the -P option with the checkout and update commands to have CVS automatically remove empty directories 2) if you wish to burn your bridges, rm -rf the repository copy of that directory Ken Koch Parallel Architectures Team, CIC-3 Los Alamos National Laboratory From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 30 23:04:50 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA02954 for ; Wed, 30 Aug 1995 23:04:50 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA01842; Wed, 30 Aug 95 12:47:51 EDT Received: from charon.cctechnol.com (as15.net-connect.net) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA01827; Wed, 30 Aug 95 12:47:38 EDT Received: by charon.cctechnol.com (Smail3.1.28.1 #3) id m0snqIV-0008t0C; Wed, 30 Aug 95 11:47 CDT Message-Id: Date: Wed, 30 Aug 95 11:47 CDT From: js@cctechnol.com (Johnie Stafford) To: info-cvs@prep.ai.mit.edu Subject: Merge branch -- Core dump Reply-To: js@cctechnol.com Organization: C & C Technologies, Inc., Lafayette, LA Status: RO I tried to merge in changes from another branch with this command: cvs update -j rel3_3 and got this output: cvs update: Updating config/inland.posmv A config/inland.posmv/all.shutdown cvs update: bad revisions 0 or 1.1.2.1 Abort (core dumped) What does this mean? How can I fix it? Johnie From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 30 23:23:27 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA03219 for ; Wed, 30 Aug 1995 23:23:27 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA00997; Wed, 30 Aug 95 12:20:01 EDT Received: from motgate.mot.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA00340; Wed, 30 Aug 95 12:19:16 EDT Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.6.11/8.6.10/MOT-3.7) with ESMTP id LAA26227 for ; Wed, 30 Aug 1995 11:18:25 -0500 Received: from motsat.sat.mot.com (motsat.sat.mot.com [192.111.236.254]) by pobox.mot.com (8.6.11/8.6.10/MOT-3.8) with SMTP id LAA05521 for ; Wed, 30 Aug 1995 11:18:23 -0500 Received: from goodsenium.sat.mot.com by motsat.sat.mot.com with SMTP id AA10428 (5.65c/IDA-1.4.4 for ); Wed, 30 Aug 1995 09:20:23 -0700 Received: by goodsenium.sat.mot.com (5.x/SMI-SVR4) id AA21762; Wed, 30 Aug 1995 09:18:35 -0700 Date: Wed, 30 Aug 1995 09:18:35 -0700 From: goodse_j@goodsenium.sat.mot.com (John Goodsen) Message-Id: <9508301618.AA21762@goodsenium.sat.mot.com> To: "Stefan Monnier" Cc: CVS Mailing-List Subject: multiple repositories In-Reply-To: <12836.809772737@liasun1.epfl.ch> References: <12836.809772737@liasun1.epfl.ch> Status: RO Stefan Monnier writes: > > Multiple repositories have a little problem: > If CVS/Root says the repository is toto and $CVSROOT says it's tata, > cvs complains. So basically you can only use multiple repositories if > you don't define $CVSROOT in which case the CVS/Root content is always used. > (else, you have to use explicitely set $CVSROOT to the content of CVS/Root > to avoid CVS's complaints) > > would it be possible to have CVS ignore $CVSROOT and use CVS/Root as much > as possible ? This way $CVSROOT would specify the default for checkouts, > but wouldn't get in the way for checkins, updates, etc... > Yeah, I've run into this one also - I've had to kludge up some of my code in the Tcl/CVS toolkit that I'm developing to work around this. In my opinion, whenever there is a CVS/Root sitting there, that should take priority over $CVSROOT, at least that's the logic I'm coding into the toolkit. A warning message might get spit out, but the operation should still go through. The warning message should be suppressed with the -Q option to cvs. -- John Goodsen Currently On-Site: Rapid Engineering Specialist Motorola Satellite Communications The Dalmatian Group, Inc. Chandler, AZ jgoodsen@dalmatian.com Today's Weather: Extremely Hotly http://www.indirect.com/www/radsoft/jgoodsen.html From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 30 23:09:26 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA01247 for ; Wed, 30 Aug 1995 23:09:25 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA01419; Wed, 30 Aug 95 12:35:44 EDT Received: from floss.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA01396; Wed, 30 Aug 95 12:35:27 EDT Received: (from kfogel@localhost) by floss.cyclic.com (8.6.9/8.6.9) id LAA25344; Wed, 30 Aug 1995 11:38:54 -0500 Date: Wed, 30 Aug 1995 11:38:54 -0500 Message-Id: <199508301638.LAA25344@floss.cyclic.com> From: Karl Fogel To: goodse_j@goodsenium.sat.mot.com (John Goodsen) Cc: "Stefan Monnier" , CVS Mailing-List Subject: Re: multiple repositories Status: RO John Goodsen wrote: >Yeah, I've run into this one also - I've had to kludge up some of my >code in the Tcl/CVS toolkit that I'm developing to work around this. >In my opinion, whenever there is a CVS/Root sitting there, that should >take priority over $CVSROOT, at least that's the logic I'm coding into >the toolkit. A warning message might get spit out, but the operation >should still go through. The warning message should be suppressed >with the -Q option to cvs. Stefan Monnier's patch to do this (just submitted) is working fine, and will be in the next release (1.6). Thanks, Stefan! -Karl From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 30 20:39:15 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA28598 for ; Wed, 30 Aug 1995 20:39:14 -0400 Date: Wed, 30 Aug 1995 20:39:14 -0400 From: info-cvs-ownrr@prep.ai.mit.edu Message-Id: <199508310039.UAA28598@jupiter.cs.uml.edu> Apparently-To: Status: RO Multiple repositories have a little problem: If CVS/Root says the repository is toto and $CVSROOT says it's tata, cvs complains. So basically you can only use multiple repositories if you don't define $CVSROOT in which case the CVS/Root content is always used. (else, you have to use explicitely set $CVSROOT to the content of CVS/Root to avoid CVS's complaints) would it be possible to have CVS ignore $CVSROOT and use CVS/Root as much as possible ? This way $CVSROOT would specify the default for checkouts, but wouldn't get in the way for checkins, updates, etc... Stefan From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 30 22:40:20 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id WAA01880 for ; Wed, 30 Aug 1995 22:40:19 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA06393; Wed, 30 Aug 95 11:04:35 EDT Received: from liasun1.epfl.ch by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA06367; Wed, 30 Aug 95 11:04:21 EDT Received: from localhost by liasun1.epfl.ch with esmtp (Smail3.1.29.1 #16) id m0snofu-000KnvC; Wed, 30 Aug 95 17:03 MET DST From: "Stefan Monnier" To: Stefan Monnier Cc: CVS Mailing-List Subject: Re: multiple repositories In-Reply-To: kfogel's message of Wed, 30 Aug 1995 09:37:16 CDT. <199508301437.JAA18684@floss.cyclic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Aug 1995 17:03:34 +0200 Message-Id: <13740.809795014@liasun1.epfl.ch> Sender: monnier@liasun1.epfl.ch Status: RO Karl Fogel wrote: > if (-d is present) > { > if (CVS/Root is present) > Exit with an error if they don't match; > else > Use -d value; > } > else if (CVS/Root is present) > Use its value; > else if (CVSROOT is set) > Use its value; > else > Print an error message. What about: *** main.c Wed Jun 21 00:04:10 1995 --- /users/monnier/tmp/main.c Wed Aug 30 16:54:38 1995 *************** *** 398,404 **** #endif /* No SERVER_SUPPORT */ if (CVSADM_Root != NULL) { ! if (CVSroot == NULL) { CVSroot = CVSADM_Root; cvs_update_env = 1; /* need to update environment */ --- 398,404 ---- #endif /* No SERVER_SUPPORT */ if (CVSADM_Root != NULL) { ! if ((CVSroot == NULL) || !cvs_update_env) { CVSroot = CVSADM_Root; cvs_update_env = 1; /* need to update environment */ *************** *** 418,438 **** { error (0, 0, "%s value for CVS Root found in %s", CVSADM_Root, CVSADM_ROOT); ! if (cvs_update_env) ! { ! error (0, 0, "does not match command line -d %s setting", ! CVSroot); ! error (1, 0, ! "you may wish to try the cvs command again without the -d option "); ! } ! else ! { ! error (0, 0, ! "does not match CVSROOT environment value of %s", ! CVSroot); ! error (1, 0, ! "you may wish to unsetenv CVSROOT and try again"); ! } } } } --- 418,427 ---- { error (0, 0, "%s value for CVS Root found in %s", CVSADM_Root, CVSADM_ROOT); ! error (0, 0, "does not match command line -d %s setting", ! CVSroot); ! error (1, 0, ! "you may wish to try the cvs command again without the -d option "); } } } From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 23 19:52:29 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id TAA08952 for ; Wed, 23 Aug 1995 19:52:29 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA21529; Wed, 23 Aug 95 10:15:07 EDT Received: from beach.sctc.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA21480; Wed, 23 Aug 95 10:14:37 EDT Received: from beach.sctc.com (daemon@localhost) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id JAA01820; Wed, 23 Aug 1995 09:27:12 -0500 Received: from spirit.sctc.com (spirit.sctc.com [172.17.192.76]) by beach.sctc.com (8.6.12/8.6.12) with ESMTP id JAA01816; Wed, 23 Aug 1995 09:27:11 -0500 Received: from dagobah.sctc.com (dagobah.sctc.com [172.17.192.121]) by spirit.sctc.com (8.6.12/8.6.10) with ESMTP id JAA29205; Wed, 23 Aug 1995 09:14:40 -0500 Received: (from koster@localhost) by dagobah.sctc.com (8.6.12/8.6.9) id JAA08896; Wed, 23 Aug 1995 09:14:39 -0500 From: Kirby Koster Message-Id: <199508231414.JAA08896@dagobah.sctc.com> Subject: Re: Fix core-dump with update -j To: kingdon@harvey.cyclic.com (Jim Kingdon) Date: Wed, 23 Aug 1995 09:14:38 -0500 (CDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <199508230417.AAA09595@harvey.cyclic.com> from "Jim Kingdon" at Aug 23, 95 00:17:19 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1150 Status: RO > > This is a small patch which fixes a segmentation fault I came across when > > doing a cvs update -jTAG on some local sources. > > I've checked in the patch. I sent a pretty long note to Karl Fogel (Sp?) on this. I'm not sure now if this patch was the right thing to do or not. I haven't heard back yet though. Problem with the patch is that when you are merging between two branches any files on the merge branch that don't exist on the local branch are _ignored_ instead of _added_ to the local branch. I think that generally people would expect the files to get locally added when a merge is done. This patch is probably still better than a core dump ;-) and not adding the files was actually the functionality that I needed at the time ... However, I think that the circumstances that lead to this need were likely caused by the way we try and force CVS to fit into our current corporate CM process and might not reflect typical cvs usage. What do you think? Should these additional files be ignored or added into the local branch? Did merging between branches work before? Anyone? Kirby --- Kirby Koster, koster@sctc.com From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 3 23:28:53 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA31939 for ; Thu, 3 Aug 1995 23:28:52 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA12190; Thu, 3 Aug 95 19:29:58 EDT Received: from mixcom.mixcom.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA12120; Thu, 3 Aug 95 19:26:50 EDT Received: by mixcom.mixcom.com (8.6.12/2.2) id SAA18663; Thu, 3 Aug 1995 18:23:00 -0500 Message-Id: <199508032323.SAA18663@mixcom.mixcom.com> Subject: commitinfo execution when using cvs 1.5 remotely To: info-cvs@prep.ai.mit.edu Date: Thu, 3 Aug 1995 18:22:59 -0500 (CDT) From: "Calyx Corp." X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1095 Status: RO When we try to use cvs 1.5 remotely, the hooks in the editinfo and commitinfo files do not seem to work properly. We have a hooks via commitinfo to do pre-commit checking, a template hook via rcsinfo, a hook via editinfo to edit and validate the log messages, and a loginfo hook to record the checkin in a problem tracking database. When I run "cvs commit" remotely, a log message (with no template) is edited right away, and then the pre-commit actions appear to be run remotely. Our pre-commit actions normally prompt the user, but remotely it seems that stdin is closed. While the commitinfo, rcsinfo, editinfo, and loginfo files are not on the remote client, I had assumed that the commands in them would be run on the client and not the server. How is this supposed to work? The cvsclient documentation that comes with cvs 1.5 doesn't tell you how to use it; it appears only to describe some internal workings of the client/server communication. thanks, Nels Olsen -- PCN/Calyx Corporation 16745 W Bluemound Rd Suite 200 Brookfield, WI 53008 (414) 782-0300 calyx.corp@mixcom.com From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 10 00:30:05 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id AAA15139 for ; Thu, 10 Aug 1995 00:30:03 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA01177; Wed, 9 Aug 95 10:11:56 EDT Received: from sheba.sequoiap.com (sequoiap.vip.best.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA01118; Wed, 9 Aug 95 10:11:32 EDT Received: from blob.best.net (blob.best.net [204.156.128.88]) by shell1.best.com (8.6.12/8.6.5) with ESMTP id AAA11429 for ; Wed, 9 Aug 1995 00:02:31 -0700 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by blob.best.net (8.6.12/8.6.5) with SMTP id AAA06136 for ; Wed, 9 Aug 1995 00:02:30 -0700 Received: by life.ai.mit.edu (4.1/AI-4.10) id AB01711; Tue, 8 Aug 95 19:40:38 EDT Received: from sheba.sequoiap.com (sequoiap.vip.best.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA01691; Tue, 8 Aug 95 19:40:25 EDT Received: from blob.best.net (blob.best.net [204.156.128.88]) by shell1.best.com (8.6.12/8.6.5) with ESMTP id QAA01449 for ; Tue, 8 Aug 1995 16:33:35 -0700 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by blob.best.net (8.6.12/8.6.5) with SMTP id QAA17056 for ; Tue, 8 Aug 1995 16:33:33 -0700 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA18046; Tue, 8 Aug 95 08:52:07 EDT Received: from middx.x.co.uk by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA18029; Tue, 8 Aug 95 08:51:46 EDT Received: from powys.x.co.uk by middx.x.co.uk id aa20971; 8 Aug 95 13:37 BST Received: by powys.x.co.uk (4.1/1.2-eef) id AA06067; Tue, 8 Aug 95 13:38:02 BST From: Robin Peeler Message-Id: <9508081238.AA06067@powys.x.co.uk> To: info-cvs@prep.ai.mit.edu Subject: Release date for new 1.5 Cc: philip@x.co.uk, olafvb@x.co.uk X-Mailer: IXI Mail 2.0 Mime-Version: 1.0 Date: Tue, 8 Aug 1995 13:37:59 +0100 (BST) Source-Info: From (or Sender) name not authenticated. Source-Info: From (or Sender) name not authenticated. Status: RO Hi there I know CVS 1.5 has only just been released, but there seem to have been a fair number of patches posted to this list recently. Are there any plans for an upgrade? Jim Blandy at Cyclic said on 3rd August 95 > Cyclic is doing a Windows NT/Visual C++ port of the CVS client at the > moment. It's not hard, but not trivial either. NT's POSIX support is > notoriously poor. When this comes out, will it include the patches? We're currently using 1.4A2 and I'd like to upgrade to 1.5 but if a new 1.5 is around the corner, I'd just as soon wait a little. Thanks Robin +----------------------------------------------------------------+ | Robin Peeler Vision Park Mail: robinp@sco.com | | Quality Manager Cambridge Tel: +44 1223 518045 | | SCO Client Integration Div. CB4 4ZR, UK Fax: +44 1223 518001 | +----------------------------------------------------------------+ From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 8 20:12:25 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA02327 for ; Tue, 8 Aug 1995 20:12:20 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AB18244; Tue, 8 Aug 95 09:00:26 EDT Received: from floss.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA18227; Tue, 8 Aug 95 09:00:13 EDT Received: (from kfogel@localhost) by floss.cyclic.com (8.6.9/8.6.9) id HAA07472; Tue, 8 Aug 1995 07:59:43 -0500 Date: Tue, 8 Aug 1995 07:59:43 -0500 Message-Id: <199508081259.HAA07472@floss.cyclic.com> From: Karl Fogel To: Robin Peeler Cc: info-cvs@prep.ai.mit.edu, philip@x.co.uk, olafvb@x.co.uk Subject: Re: Release date for new 1.5 Status: RO >I know CVS 1.5 has only just been released, but there seem to have >been a fair number of patches posted to this list recently. > >Are there any plans for an upgrade? Yes, there are plans for 1.6 to be released sometime in September (the schedule is not yet firm, however). We'll post an announcement to this list when the release process (i.e.: feature freeze) starts, probably in late August. >Jim Blandy at Cyclic said on 3rd August 95 >> Cyclic is doing a Windows NT/Visual C++ port of the CVS client at the >> moment. It's not hard, but not trivial either. NT's POSIX support is >> notoriously poor. > >When this comes out, will it include the patches? Yes; the Windows NT work is being merged into the same sources as all the other patches. We use CVS to manage itself (of course), so this is easy. :-) -Karl From info-cvs-ownrr@prep.ai.mit.edu Tue Aug 8 23:58:23 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id XAA22904 for ; Tue, 8 Aug 1995 23:58:22 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA03707; Tue, 8 Aug 95 13:31:05 EDT Received: from maildrop.micrognosis.com (supernova.micrognosis.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-inbox id AA03697; Tue, 8 Aug 95 13:30:54 EDT Received: by maildrop.micrognosis.com (4.1/SMI-4.1) id AA19422; Tue, 8 Aug 95 13:30:50 EDT Received: from rndsrv1.mdev.micrognosis.com(198.112.252.23) by supernova.micrognosis.com via smap (V1.3) id sma019419; Tue Aug 8 13:30:24 1995 Received: from soggy (soggy.mdev.micrognosis.com) by mdev.micrognosis.com (4.1/1.0-integ.cf) id AA13166; Tue, 8 Aug 95 13:30:22 EDT From: francis@mdev.micrognosis.com (Frank Pardo #2) Received: by soggy id ; Tue, 8 Aug 1995 13:26:26 -0400 Date: Tue, 8 Aug 1995 13:26:26 -0400 Message-Id: <9508081726.AA28542@soggy> To: info-cvs@prep.ai.mit.edu Subject: magic branch tag format? Cc: VJ@mdev.micrognosis.com Status: RO This is a question about CVS 1.3; anybody out there still using it? For reasons that are immaterial, they gave me the chore of extracting and analyzing information about tags. What I don't know is, How do you distinguish a "magic branch tag" from all others? For one of the files I'm testing my script with, the list of revision numbers and associated tags is: 1.1 ORIG 1.11 MARSBASE_15FEB95 1.11 MARS_END 1.11 MIPSBASE_20MAR 1.11.0.2 MARS 1.12 V2_3-07_BASE 1.12.0.2 V2_3-07 1.12.2.1 V2_3-07_T0011 1.14 JUN13RESTORE 1.16 PRE_DAKS_MERGE 1.17 POST_DAKS_MERGE 1.9 DAKSBASE_03JAN95 1.9.0.2 DAKS Now, I know that the magic tags in our repository are MARS, DAKS, and V2_3-07. From looking at this and other files, I suspect that the revision numbers for magic branch tags alway have a zero in their penultimate component. Can anyone verify or disprove this? Or point me to a dusty corner of the FAQ that I missed? thanks in advance Frank Pardo Micrognosis Inc. From info-cvs-ownrr@prep.ai.mit.edu Wed Aug 16 17:41:33 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id RAA10158 for ; Wed, 16 Aug 1995 17:41:32 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA22299; Wed, 16 Aug 95 12:29:12 EDT Received: from sunl.cr.usgs.gov by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA22285; Wed, 16 Aug 95 12:29:02 EDT Received: from dlger.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2) id AA27693; Wed, 16 Aug 95 11:28:58 CDT Received: by dlger.cr.usgs.gov (5.4R2.01/1.34) id AA03801; Wed, 16 Aug 1995 11:12:09 -0500 Date: Wed, 16 Aug 1995 11:12:09 -0500 (CDT) From: Jo Wahle To: info-cvs@prep.ai.mit.edu Subject: postcommit.csh Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO We have recently upgraded to 1.5, and running some tests I ran into a problem with being unable to find 'postcommit.csh.' I can't figure out where this file is supposed to reside, nor why the problem hasn't surfaced before. After I commit this file and enter the log message, I get: Checking in rmMakefiles; /dlge1/csb/wahle/cvs_test_repository/v3/rmMakefiles,v <-- rmMakefiles new revision: 1.4; previous revision: 1.3 done cvs commit: Executing 'postcommit.csh /dlge1/csb/wahle/cvs_test_repository/v3' cvs commit: cannot exec postcommit.csh: No such file or directory Sure enough, I cannot find the file 'postcommit.csh' anywhere. I've done 'find's in my local directory, in the repository, and in the source that I originally un-tar'ed. It's apparently an important file -- the modules file says: #-------------------------------------- # All modules should run postcommit.csh # to ensure that the files are owned by # the correct user and group. #-------------------------------------- Only the top-level local directory in this module has a Checkin.prog under the CVS directory, so the problem only exists when modifying files. Why haven't I had this problem before? Where is 'postcommit.csh' supposed to reside? I've checked the man pages, and the manual at www.winternet.com. I'm confused. This particular problem exists on our Data Generals (DG/UX 5.4R2.10) and our SUN workstation (SunOS 5.4). I certainly haven't deleted the file. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! Make 'em think you're crazy: commit random !! --Jo !! !! acts of kindness and senseless beauty. !! wahle@dlger.cr.usgs.gov !! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 24 20:39:41 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA18787 for ; Thu, 24 Aug 1995 20:39:40 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA05132; Thu, 24 Aug 95 13:03:43 EDT Received: from mdcsc.ca.mdis.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA05123; Thu, 24 Aug 95 13:03:30 EDT Received: from bannister (pc-plb.ca.mdis.com) by mdcsc.ca.mdis.com (4.1/SMI-4.1) id AA11971; Thu, 24 Aug 95 09:53:52 PDT Message-Id: <9508241653.AA11971@mdcsc.ca.mdis.com> X-Sender: plb@mdcsc.ca.mdis.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Aug 1995 10:03:02 -0700 To: del@babel.dialix.oz.au (Del), info-cvs@prep.ai.mit.edu From: "Preston L.Bannister" Subject: Re: CVS 1.5 ported to Windows NT? Status: RO At 10:30 AM 8/24/95 EST, Del wrote: [...about having a file to map long Unix file names to DOS 8.3 format...] >I have an alternate solution -- use a 00trans.tbl file in the same >format as used by the Rock Ridge extensions to CD-ROM file systems. >That way the DOS 8.3 character file names can be used (note that >CDs are restricted to 8.3 character file names too) and the mapping >can be done in a way compatible with ISO 9660. This would (for >example) make it easy to archive an entire repository to writeable >CD-ROM. > >The code to do this can probably be pinched from one of the freeware >unices around that has an ISO9660 driver (Linux, for example). You probably would not want to use the same name, as this might cause problems if a distribution were written to CDROM. Also once we have a map, we may find in future that we want to add additional attributes to the map. Will the Rock Ridge extensions allow to an open-ended set of attributes? --- Preston L. Bannister Email : plb@mdcsc.ca.mdis.com CIS : 71350,3505 Phone : (714)724-5724 From info-cvs-ownrr@prep.ai.mit.edu Thu Aug 24 21:00:04 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id UAA09349 for ; Thu, 24 Aug 1995 20:59:54 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA06967; Thu, 24 Aug 95 13:37:05 EDT Received: from gateway.iscla.sei-it.com ([205.231.128.33]) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA06911; Thu, 24 Aug 95 13:35:18 EDT Received: from pop.iscla.sei-it.com (pop.iscla.sei-it.com [205.231.128.72]) by gateway.iscla.sei-it.com (8.6.12/8.6.12) with ESMTP id KAA01566; Thu, 24 Aug 1995 10:28:10 -0700 Received: from ISC_LA/SpoolDir by pop.iscla.sei-it.com (Mercury 1.21); 24 Aug 95 10:21:04 -0800 Received: from SpoolDir by ISC_LA (Mercury 1.21); 24 Aug 95 10:20:28 -0800 Received: from atlantis.idsoc.sei-it.com by pop.iscla.sei-it.com (Mercury 1.21) with ESMTP; 24 Aug 95 10:20:24 -0800 Received: (from dwig@localhost) by atlantis.idsoc.sei-it.com (8.6.12/8.6.12) id KAA68648; Thu, 24 Aug 1995 10:21:56 -0700 Date: Thu, 24 Aug 1995 10:21:56 -0700 From: dwig@sei-it.com Message-Id: <199508241721.KAA68648@atlantis.idsoc.sei-it.com> To: koster@sctc.com Cc: kingdon@harvey.cyclic.com, info-cvs@prep.ai.mit.edu In-Reply-To: <199508231414.JAA08896@dagobah.sctc.com> (message from Kirby Koster on Wed, 23 Aug 1995 09:14:38 -0500 (CDT)) Subject: Re: Fix core-dump with update -j Reply-To: Don Dwiggins Status: RO Kirby Koster writes: > Problem with the patch is that when you are merging between two branches > any files on the merge branch that don't exist on the local branch are > _ignored_ instead of _added_ to the local branch. I think that generally > people would expect the files to get locally added when a merge is done. > What do you think? Should these additional files be ignored or added into > the local branch? Did merging between branches work before? Anyone? A related question: if there are "removed" files on the merge branch, should the local branch's corresponding files be removed? If the intended semantics of the merge is "make this one like that one", it could be argued that the answer to both questions is "yes". At least, I'd like to be warned that there are "whole file" differences between the branches; a little nicer would be to have the option to add/remove on merge. Don Dwiggins "Things should be made as simple as possible, SEI Information Technology but no simpler" ddwiggins@sei-it.com -- Albert Einstein From info-cvs-ownrr@prep.ai.mit.edu Mon Sep 4 09:20:34 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id JAA05838 for ; Mon, 4 Sep 1995 09:20:33 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA17558; Mon, 4 Sep 95 04:58:15 EDT Received: from liasun1.epfl.ch by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA17535; Mon, 4 Sep 95 04:57:59 EDT Received: from localhost by liasun1.epfl.ch with esmtp (Smail3.1.29.1 #16) id m0spXIR-000KnvC; Mon, 4 Sep 95 10:54 MET DST From: "Stefan Monnier" To: robertl@arnet.com, stefan.monnier@epfl.ch Cc: CVS Mailing-List Subject: Re: Remote support w/ lame remshd's? In-Reply-To: paul's message of Mon, 04 Sep 1995 01:19:13 PDT. <9509040819.AA20372@sander.sander.cupertino.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Sep 1995 10:54:27 +0200 Message-Id: <20040.810204867@liasun1.epfl.ch> Sender: monnier@liasun1.epfl.ch Status: RO paul@sander.cupertino.ca.us (Paul Sander) wrote: [... remarks about the sysadm or cvsadm not relying on the user setup ...] Not requiring anything special from the user is good. Protecting the user against himself is probably not as necessary. (do you add the '\' in front of '/usr/local/bin/cvs' to make sure the user hasn't aliased this name ?) > The menus should invoke commands via fullpath. Should they ? Why is that ? I don't use fullpaths and find it very convenient. For instance, my .ctwmrc file is exactly the same on all my accounts (I actually misuse CVS's remote repositories to keep most of my config files coherent: it has some drawbacks on the file-protection side but it's much better than rdist on the bandwidth side :-) In any case, your comment was correct, mine was more about setting PATH in some login file which breaks every now and then. In the present case (installing CVS), it might make sense to try and use absolute paths, totally avoiding the PATH problem. Still, where would you encode that absolute path ? In the client's code ? Doesn't seem right to me since several people might use cvsclient at one site with servers at different places (or even simply in case of multiple remote repositories). Stefan From info-cvs-ownrr@prep.ai.mit.edu Mon Sep 4 18:47:00 1995 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id SAA20052 for ; Mon, 4 Sep 1995 18:46:59 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) id AA07886; Mon, 4 Sep 95 15:01:15 EDT Received: from sander.sander.cupertino.ca.u (sander.sander.cupertino.ca.us) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odq -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-inbox bug-cvs-non-local@gnu-life.ai.mit.edu id AA07877; Mon, 4 Sep 95 15:00:57 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA20705; Mon, 4 Sep 95 12:05:03 PDT Date: Mon, 4 Sep 95 12:05:03 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9509041905.AA20705@sander.sander.cupertino.ca.us> To: stefan.monnier@epfl.ch Subject: Re: Remote support w/ lame remshd's? Cc: info-cvs@prep.ai.mit.edu Status: RO Stefan Monnier wrote: Getting a bit off the CVS charter here, but the points made are relevant to the topic at hand... >paul@sander.cupertino.ca.us (Paul Sander) wrote: >[... remarks about the sysadm or cvsadm not relying on the user setup ...] >Not requiring anything special from the user is good. Protecting the user >against himself is probably not as necessary. (do you add the '\' in front of >'/usr/local/bin/cvs' to make sure the user hasn't aliased this name ?) This isn't usually necessary in sh, ksh, bash, perl, or tcl scripts, since the user doesn't have the chance to create aliases. It's also not necessary using csh if the -f flag is given. The "\" is really a workaround to the user's .cshrc file when writing csh scripts that omit the -f flag. But when such scripts are written, it is certainly necessary to protect the users from themselves. Have you ever had a user redefine their histchars? The old CVS 1.2 "checkin" script broke in one of my user's environments for this very reason, with nasty results. >> The menus should invoke commands via fullpath. >Should they ? >Why is that ? >I don't use fullpaths and find it very convenient. For instance, my .ctwmrc >file is exactly the same on all my accounts (I actually misuse CVS's remote >repositories to keep most of my config files coherent: it has some drawbacks >on the file-protection side but it's much better than rdist on the bandwidth >side :-) Your point is well taken. If such commands are written to work specifically with your environment, then it is safe to operate this way. But if the .ctwmrc file is shared between several users, then fullpaths should be used because everyone's environments will be different. In my role as buildmeister for my employer, I have 3 working environments: The I use for builds, the one I use for running regression suites, and my login environment. The build and test environments are profiled and are stored with each version of the product, since they change over time but must be preserved for reproducibility reasons. My login environment changes at the drop of a hat. I am required to launch interactive shells in each of these environments, and CVS (and all of my other tools) must be expected to work in all three environments. The best way I've found to have the tools work correctly under this kind of usage is to tolerate differences in the environment, while strictly enforcing environmental requirements by profiling them within each tool. >In any case, your comment was correct, mine was more about setting PATH in >some login file which breaks every now and then. In the present case >(installing CVS), it might make sense to try and use absolute paths, totally >avoiding the PATH problem. Still, where would you encode that absolute path ? >In the client's code ? Doesn't seem right to me since several people might use >cvsclient at one site with servers at different places (or even simply in case >of multiple remote repositories). The path should be encoded with the location of the repository, with fairly strong authentication to prevent corruptions or trojan horses. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From gnu@prep.ai.mit.edu Thu Sep 7 21:46:07 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id VAA22751 for ; Thu, 7 Sep 1995 21:46:04 -0400 Received: by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) id SAA15961; Thu, 7 Sep 1995 18:29:03 -0400 Resent-Date: Thu, 7 Sep 1995 18:29:03 -0400 Resent-From: GNU Mailing List Maintenance Resent-Message-Id: <199509072229.SAA15961@gnu-life.ai.mit.edu> Received: from gnu-life.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA03026; Thu, 7 Sep 95 07:05:55 EDT Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id HAA08113; Thu, 7 Sep 1995 07:05:17 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA03019; Thu, 7 Sep 95 07:05:13 EDT Received: from dayton.saic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs--non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA02998; Thu, 7 Sep 95 07:03:46 EDT Received: from llcoolj.dayton.saic.com.noname (llcoolj.dayton.SAIC.COM [139.121.26.6]) by dayton.saic.com (8.6.9/8.6.5) with SMTP id HAA28156; Thu, 7 Sep 1995 07:03:37 -0400 Received: by llcoolj.dayton.saic.com.noname (4.1/SMI-4.1) id AA25361; Thu, 7 Sep 95 07:05:07 EDT Date: Thu, 7 Sep 95 07:05:07 EDT Message-Id: <9509071105.AA25361@llcoolj.dayton.saic.com.noname> From: Mike Sutton Sender: gnu@prep.ai.mit.edu To: nyap@mailhub.garban.com, info-cvs@prep.ai.mit.edu In-Reply-To: <9509051352.AA15139@> (nyap@mailhub.garban.com) Subject: Re: virtual modules Status: RO >>>>> "Noel" == Noel Yap writes: Noel> Can cvs support named subsets of modules -- virtual categories Noel> as per Rumbaugh, current JOOP? For example: A module consists Noel> of m0.c, m1.c, and m2.c. Application A0 uses only m0.c and Noel> m1.c. Application A1 uses only m0.c and m2.c. Application A2 Noel> uses only m1.c and m2.c. Noel> I need to be able to check out only the compilation units that Noel> A0 uses (preferably by name/tag). You can add something like the following to your "modules" file: A0 directory_name m0.c m1.c A1 directory_name m0.c m2.c A2 directory_name m1.c m2.c This will set up the module names of A0, A1, and A2. When these are checked out only the listed files are retrieved. Mike Sutton | Life is hard when you're SAIC | home-pageless. Beavercreek, OH | Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's From gnu@prep.ai.mit.edu Thu Sep 7 22:10:40 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id WAA30810 for ; Thu, 7 Sep 1995 22:10:38 -0400 Received: by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) id SAA15960; Thu, 7 Sep 1995 18:28:40 -0400 Resent-Date: Thu, 7 Sep 1995 18:28:40 -0400 Resent-From: GNU Mailing List Maintenance Resent-Message-Id: <199509072228.SAA15960@gnu-life.ai.mit.edu> Received: from gnu-life.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA21440; Wed, 6 Sep 95 22:38:38 EDT Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id WAA06933; Wed, 6 Sep 1995 22:37:59 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA21424; Wed, 6 Sep 95 22:37:56 EDT Received: from bob.indirect.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs--non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA21415; Wed, 6 Sep 95 22:37:40 EDT Received: from bud.indirect.com (radsoft@bud.indirect.com [165.247.1.10]) by bob.indirect.com (8.6.12/8.6.9) with ESMTP id TAA00823 for ; Wed, 6 Sep 1995 19:37:59 -0700 Received: (from radsoft@localhost) by bud.indirect.com (8.6.12/8.6.6) id TAA06788 for info-cvs@prep.ai.mit.edu; Wed, 6 Sep 1995 19:38:13 -0700 Date: Wed, 6 Sep 1995 19:38:13 -0700 From: John Goodsen Sender: gnu@prep.ai.mit.edu Message-Id: <199509070238.TAA06788@bud.indirect.com> To: info-cvs@prep.ai.mit.edu Subject: Announce: RAD/CVS - Object-Oriented CVS Toolkit and Graphical User Interface to CVS Status: RO There's been several requests for a Tcl/Tk user interface to CVS. I'm posting this preliminary announcement to the CVS mailing list to inform you all of the soon to be announced GUI interface to CVS and Object-Oriented Tcl toolkit for CVS based upon the Tix object extensions to Tcl and the Tix widget set. For a quick look, check out: http://www.indirect.com/www/radsoft/radcvs/ And register yourself on the source code page for email notification when RAD/CVS completes Alpha testing and is released for public use as a Beta release within the next month. Regards, John Goodsen radcvs@radsoft.com From sre@jrcase.mq.edu.au Thu Sep 7 21:21:00 1995 Received: from dishwasher1.mpce.mq.edu.au (dishwasher1.mpce.mq.edu.au [137.111.216.16]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id VAA27102 for ; Thu, 7 Sep 1995 21:20:53 -0400 Received: from (localhost.mpce.mq.edu.au [127.0.0.1]) by dishwasher1.mpce.mq.edu.au (8.6.9/8.6.9) with SMTP id LAA15475; Fri, 8 Sep 1995 11:03:02 +1000 Date: Fri, 8 Sep 1995 11:03:02 +1000 Message-Id: Errors-To: didar@titanic.mpce.mq.edu.au Reply-To: sre@jrcase.mq.edu.au Originator: sre@jrcase.mq.edu.au Sender: sre@jrcase.mq.edu.au Precedence: bulk From: Didar Zowghi To: Multiple recipients of list Subject: [SRE:369] Requirements Volatility X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Software Requirements for Engineering Mailing List Status: RO Dear Colleagues I would like to start a discussion on Requirements Volatility which is one of my research interests. I am particularly interested to hear the views of practitioners who have had some experience with managing changes to requirements. Your response to any of the following questions is very much appreciated. 1. What is the most effective way of handling changes to requirements in relation to cost, schedule, etc? 2. How do you predict the impact of changes to requirements? 3. Do extent and/or type of changes to requirements depend on the type and/or size of the project in any way? 4. How does prototyping contribute to the extent of volatility in requirements? 5. What do you think is the effect of "incremental development" on requirements volatility? 6. Do you think that "overspecification" affects requirements volatility? 7. In which stage(s) of the development process are changes to requirements most likely to be requested? 8. Is any aspect of the system under development prone to more changes than others (eg. user interface)? 9. Do you think that requirements volatility contributes to software size variability? (how) Regards -------------------------------------------------------------------- | Didar Zowghi CSIRO-Macquarie University | | Joint Research Centre for Advanced Systems Engineering (JRCASE) | | School of Mathematics, Physics, Computing and Electronics | | Macquarie University, Sydney, NSW 2109, AUSTRALIA | | E-mail: didar@mpce.mq.edu.au | | Phone: + 61 (02) 850 9105 (or 9101) | | Facsimile: + 61 (02) 850 9102 | -------------------------------------------------------------------- From gnu@ai.mit.edu Fri Sep 8 14:21:05 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id OAA17832 for ; Fri, 8 Sep 1995 14:21:00 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id MAA20656; Fri, 8 Sep 1995 12:10:10 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA29694; Fri, 8 Sep 95 12:10:04 EDT Received: from gnu-life.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AB29598; Fri, 8 Sep 95 12:07:12 EDT Received: by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) id MAA20628; Fri, 8 Sep 1995 12:01:26 -0400 Resent-Date: Fri, 8 Sep 1995 12:01:26 -0400 Resent-Message-Id: <199509081601.MAA20628@gnu-life.ai.mit.edu> Received: from ub4b.eunet.be by life.ai.mit.edu (4.1/AI-4.10) for gnu id AA09901; Fri, 8 Sep 95 03:26:50 EDT Received: from mailhost.sonytel.be by ub4b.eunet.be (ub4b_07) id AA10486; Fri, 8 Sep 1995 09:29:05 +0200 Received: from retina (retina.sonytel.be) by mailhost.sonytel.be (4.0/SONY-4.0MX) id AA05055; Fri, 8 Sep 95 09:25:42 +0200 Received: by retina (950215.SGI.8.6.10/940406.SGI.AUTO) for gnu@prep.ai.mit.edu id JAA12895; Fri, 8 Sep 1995 09:25:55 +0200 From: "Ives Aerts" Sender: gnu@prep.ai.mit.edu Message-Id: <9509080925.ZM12893@unknown.zmail.host> Date: Fri, 8 Sep 1995 09:25:53 -0600 In-Reply-To: GNU Mailing List Maintenance "Any way to remove tags I no longer need?" (Sep 7, 17:54) References: <199509072154.RAA15717@gnu-life.ai.mit.edu> Reply-To: ives@sonytel.be X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: info-cvs@prep.ai.mit.edu Subject: Re: Any way to remove tags I no longer need? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-From: info-cvs-request@prep.ai.mit.edu Status: RO On Sep 7, 17:54, GNU Mailing List Maintenance wrote: > Subject: Any way to remove tags I no longer need? > Thanx for any pointers cvs tag -d -Ives ____________________________________________________________ Ives Aerts (SW Developer) | Sony Telecom Europe ives@sonytel.be | St.Stevens-Woluwestr. 55 | B-1130 Brussels, Belgium `A moose once bit my sister' | PHONE : +32 2 724 19 67 (M.Python) | FAX : +32 2 726 26 86 From info-cvs-ownrr@prep.ai.mit.edu Fri Sep 8 19:34:14 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA29233 for ; Fri, 8 Sep 1995 19:34:13 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id SAA21668; Fri, 8 Sep 1995 18:00:53 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA24435; Fri, 8 Sep 95 18:00:49 EDT Received: from netmail1.austin.ibm.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA24376; Fri, 8 Sep 95 18:00:27 EDT Received: from fliegen.austin.ibm.com (fliegen.austin.ibm.com [129.35.128.200]) by netmail1.austin.ibm.com (8.6.11/8.6.11) with SMTP id RAA45466; Fri, 8 Sep 1995 17:00:25 -0500 Received: by fliegen.austin.ibm.com (AIX 4.1/UCB 5.64/4.03-client-2.6) for info-cvs@prep.ai.mit.edu at austin.ibm.com; id AA40168; Fri, 8 Sep 1995 16:58:54 -0500 From: knutson@austin.ibm.com (Jim Knutson) Message-Id: <9509082158.AA40168@fliegen.austin.ibm.com> Subject: Re: binary file trouble, even with admin -ko To: gvf@nando.net (gvf) Date: Fri, 8 Sep 1995 16:58:53 -0500 (CDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9509081918.AA09908@nando.net.nando.net> from "gvf" at Sep 8, 95 03:18:30 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 415 Status: RO > the 0x3d at the end is an = sign, and it looks like > cvs adds an @ sign and a nul to it. > > This is with CVS 1.3. Can anyone explain this, > or help me prevent it? I don't know how to prevent it, but it's RCS that's the problem. It likes to append the RCS field delimiter character (@) when the file doesn't have a trailing newline. It doesn't happen all the time, just at inconvenient times for me. Jim From info-cvs-ownrr@prep.ai.mit.edu Fri Sep 8 19:20:02 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA11630 for ; Fri, 8 Sep 1995 19:20:02 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id RAA21560; Fri, 8 Sep 1995 17:16:05 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA18987; Fri, 8 Sep 95 17:15:58 EDT Received: from noao.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA18976; Fri, 8 Sep 95 17:15:46 EDT Received: from ctiole (ctiole.ctio.noao.edu) by noao.edu (4.1/SAG-Noao.G102) id AA29736; Fri, 8 Sep 95 14:00:58 MST; for mws115@llcoolj.dayton.saic.com Received: by ctiole (4.1/JBH.4) id AA08436; Fri, 8 Sep 95 17:00:55 CST Date: Fri, 8 Sep 95 17:00:55 CST From: webb@ctiole.ctio.noao.edu (gary webb x240) Message-Id: <9509082100.AA08436@ctiole> To: mws115@llcoolj.dayton.saic.com, nilesh@aspentec.com Subject: Managing diff. extns on diff. platforms Cc: info-cvs@prep.ai.mit.edu Status: RO Mike is suggestiong that Nilesh keep all of his sources in *.for files and teach unix (make) how to compile them. This is fine for unix, but perhaps he has an operating system that is more intransigent. > From info-cvs-ownrr@prep.ai.mit.edu Fri Sep 8 15:57:45 1995 > Date: Fri, 8 Sep 95 13:19:53 EDT > From: Mike Sutton > To: info-cvs@prep.ai.mit.edu > Subject: Re: Managing diff. extns on diff. platforms > Content-Length: 738 > > >>>>> ":" == ATHQ writes: > > :> I have fortran source files under CVS control. Now, on > :> different platforms, different extentions are required by the > :> compiler. (e.g. UNIX requires *.f, VMS requires .for, PC/Windows-NT > :> requires .for etc.) > > :> Has anyone encountered this problem? Looks fortran-specific. > > No, it is not fortran specific. I use .for extensions on Unix. It a > Make thing. Add a new rule to your makefile. > > # add rule to account for .for suffix > .SUFFIXES: .for > .for.o: > $(COMPILE.f) $(OUTPUT_OPTION) $< > > > Mike Sutton | Life is hard when you're > SAIC | home-pageless. > Beavercreek, OH | > Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's > Another method is to just create links for each of the desired extensions to the actual source files. E.g., if your actual source is in snafu.fxx create a bunch of links snafu.f, snafu.for, snafu.f77, ... all pointing to snafu.fxx . Of course, not all operating systems like links. Getting back to make, you can avoid the links by having make do copies. Since I would actually put my sources in one directory and each operating systems objects in their own directory, this makes more sense to me. Of course, if you are in one directory, then you can do things like # add rules to account for varying suffixes .SUFFIXES: .fxx .for .f .f77 .fxx.for: -rm $*.for cp $*.fxx $*.for .fxx.f: -rm $*.f cp $*.fxx $*.f .fxx.f77: -rm $*.f77 cp $*.fxx $*.f77 I have to admit though, I have never come up with a way to include the directory copy that I like (I have lots of methods that work, but none are as clean as I think make should be). Anyway, that is the nice thing about S/W: lots of ways to attack the same problem. Enjoy! Gary Lee Webb Cerro Tololo From info-cvs-ownrr@prep.ai.mit.edu Fri Sep 8 22:58:29 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id WAA22604 for ; Fri, 8 Sep 1995 22:58:24 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id VAA22227; Fri, 8 Sep 1995 21:20:45 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA06964; Fri, 8 Sep 95 21:20:42 EDT Received: from alcor.twinsun.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA06952; Fri, 8 Sep 95 21:20:23 EDT Received: from twinsun.com (twinsun.twinsun.com [192.54.239.2]) by alcor.twinsun.com (8.6.12/8.6.5) with SMTP id SAA10063; Fri, 8 Sep 1995 18:13:30 -0700 Received: from light.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA22881; Fri, 8 Sep 95 18:18:08 PDT Received: by light.twinsun.com (SMI-8.6/SMI-SVR4) id SAA16012; Fri, 8 Sep 1995 18:18:08 -0700 Date: Fri, 8 Sep 1995 18:18:08 -0700 Message-Id: <199509090118.SAA16012@light.twinsun.com> From: Paul Eggert To: knutson@austin.ibm.com Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9509082158.AA40168@fliegen.austin.ibm.com> (knutson@austin.ibm.com) Subject: Re: binary file trouble, even with admin -ko Status: RO From: knutson@austin.ibm.com (Jim Knutson) Date: Fri, 8 Sep 1995 16:58:53 -0500 (CDT) [RCS] likes to append the RCS field delimiter character (@) when the file doesn't have a trailing newline. That bug is fixed in RCS 5.7. From info-cvs-ownrr@prep.ai.mit.edu Sat Sep 9 12:38:36 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id MAA18407 for ; Sat, 9 Sep 1995 12:38:35 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id KAA24115; Sat, 9 Sep 1995 10:44:48 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA25969; Sat, 9 Sep 95 10:44:46 EDT Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA25959; Sat, 9 Sep 95 10:44:29 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Sat, 9 Sep 95 10:44:00 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Sat, 9 Sep 95 10:44:00 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: Nilesh Patel/ATHQ Cc: info-cvs@prep.ai.mit.edu Subject: Re: Managing diff. extns on diff. platforms In-Reply-To: Nilesh Patel's message of "Fri, September 8, 1995 10:45:24 -0400" regarding "Managing diff. extns on diff. platforms" id References: Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Fri, September 8, 1995 at 10:45:24 (-0400), Nilesh Patel wrote: ] > Subject: Managing diff. extns on diff. platforms > > One way to get around this, is to have CVS rename the files > AFTER checkout and BEFORE commit. Can you comment on the pros and > cons of this approach? Also, which other function of CVS this may > affect (e.g. status, log, history, update etc.) An even easier way to solve this problem would be with make. Have a makefile included that adds another rule to build '.for' files from '.f' files, but only when building on DOS. -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Mon Sep 11 19:58:43 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA22898 for ; Mon, 11 Sep 1995 19:58:43 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id SAA01572; Mon, 11 Sep 1995 18:12:25 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA27314; Mon, 11 Sep 95 18:12:15 EDT Received: from tongue1.ftc.nrcs.usda.gov by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA27185; Mon, 11 Sep 95 18:11:49 EDT Received: by tongue1.ftc.nrcs.usda.gov with tcp (4.1/SMI-0.1-tom) id AA26235; Mon, 11 Sep 95 16:08:58 MDT From: jasr@tongue1.ftc.nrcs.usda.gov (Jason Restad) Message-Id: <9509112208.AA26235@tongue1.ftc.nrcs.usda.gov> Subject: Re: Question about performance. To: cdesouza@hpbbn.bbn.hp.com Date: Mon, 11 Sep 1995 16:08:57 -0600 (MDT) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <199509111329.AA016196150@hpbbi26.bbn.hp.com> from "Corny de Souza" at Sep 11, 95 03:29:10 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 967 Status: RO Corny de Souza wrote: > ... > One of the options is to use CVS and I wanted to know if there was any > experience in maintaining 60,000 files (including directories) under CVS, > especially with regard to performance. We are using CVS 1.3. There are ~50 Unix platforms accessing the single CVS repository via a NFS mount. The NFS file system is exported from a HP 755 There are currently 50,743 files in the repository including directories. Performance is acceptable. The performance seems more affected by the type of platform executing the cvs command and the NFS implimentation than the number of files in the repository. For example: On a 16MHz i386 using NRC's NFS a module with 162 files that take up 3Mbytes of space takes 4min 23sec to checkout The same module on a HP 755 using hp's NFS takes 1min 36sec Lastly on the HP 755 that is hosting the filesystem so no NFS mount or network is involved the module checks out in 24 seconds. From info-cvs-ownrr@prep.ai.mit.edu Mon Sep 11 17:18:34 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id RAA07198 for ; Mon, 11 Sep 1995 17:18:30 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id OAA00721; Mon, 11 Sep 1995 14:41:13 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA11723; Mon, 11 Sep 95 14:41:11 EDT Received: from rocky.sri.MT.net (sri.MT.net) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA11682; Mon, 11 Sep 95 14:40:53 EDT Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id MAA03010; Mon, 11 Sep 1995 12:42:56 -0600 Date: Mon, 11 Sep 1995 12:42:56 -0600 From: Nate Williams Message-Id: <199509111842.MAA03010@rocky.sri.MT.net> To: Krishna.Achutarao@laitram.com Cc: info-cvs@prep.ai.mit.edu, mak@laitram.com Subject: Re: CVS newbie install questions. etc... [LONG] In-Reply-To: <9509111202.aa04833@mak.laitram.com> References: <9509111202.aa04833@mak.laitram.com> Status: RO Krishna Achutarao writes: > > I have recently installed cvs 1.5 on an SCO box (System V/386 Release 3.2)(OSR3) Whee, lucky you. I'm stuck^H^H^H^H^Hblessed with using SCO systems as well. :) > Second.... > Installed RCS 5.7. The problem with this installation was that I could not > install this as root in the usual usr/local/ hierrarchy. While the > 'configure' part of the installation seemed to go smoothly, the 'make', > command would give me the following messages: Note, you are 'make'ing the code, not installing it at this point. > /bin/sh -x ./conf.sh 3>&1 >a.h 2>conf.err > ./conf.sh: testing permissions ... > ./conf.sh: This command should not be run with superuser permissions. When you build it, build it as a regular user. Once you build it you can install it as root. > Q: Am I okay with indiscriminate commenting of lines here??(ok, so it > was not indiscriminate, maybe just an intelligent guess). If it compiled and passed it's tests, you're probably safe. > Q. Why am I getting the junk at the beginning and the @ in the end even > though I have RCS 5.7? Is it safe to get rid of all that stuff, or does > RCS need the information? Hmm, this is new to me although I'm using RCS 5.6 binaries. I'll see if I can reproduce the error locally. Nate From info-cvs-ownrr@prep.ai.mit.edu Mon Sep 11 17:03:52 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id RAA10486 for ; Mon, 11 Sep 1995 17:03:42 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id NAA00627; Mon, 11 Sep 1995 13:56:22 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA09322; Mon, 11 Sep 95 13:56:20 EDT Received: from titan.laitram.com ([204.251.4.251]) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA09265; Mon, 11 Sep 95 13:55:40 EDT Received: (from uucp@localhost) by titan.laitram.com (8.6.9/8.6.9) id MAA09522 for ; Mon, 11 Sep 1995 12:09:04 -0500 Received: from earth.laitram.com(204.251.5.74) by titan.laitram.com via smap (V1.3) id sma009520; Mon Sep 11 12:09:00 1995 Received: from mak.laitram.com (mak.laitram.com [204.251.5.84]) by earth.laitram.com (8.6.9/8.6.9) with SMTP id LAA21514 for ; Mon, 11 Sep 1995 11:57:34 -0500 From: Krishna.Achutarao@laitram.com To: info-cvs@prep.ai.mit.edu Subject: CVS newbie install questions. etc... [LONG] Cc: mak@laitram.com X-Mailer: ScoMail 1.0 Date: Mon, 11 Sep 1995 12:02:39 -0500 (CDT) Message-Id: <9509111202.aa04833@mak.laitram.com> Status: RO Hi people, I have recently installed cvs 1.5 on an SCO box (System V/386 Release 3.2)(OSR3) I am a newbie to cvs (for that matter, to config-management). I am in the process of testing it out and have a few questions about the installation and performance. Please bear with me if some of these questions are naive. I am not a unix/c guru (nor a novice), just someone who has had version control duties dumped on him. First ... I installed gnu diff 2.7. Installation went smoothly with no problems of any kind. Second.... Installed RCS 5.7. The problem with this installation was that I could not install this as root in the usual usr/local/ hierrarchy. While the 'configure' part of the installation seemed to go smoothly, the 'make', command would give me the following messages: ************************including 'make' messages********************** cd man && make all make[1]: Entering directory `/usr/local/lib/rcs-5.7/man' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/local/lib/rcs-5.7/man' cd src && make all make[1]: Entering directory `/usr/local/lib/rcs-5.7/src' rm -f a.* ALL_CFLAGS=' -Dhas_conf_h -I. -I. -g -O' \ CC='gcc' \ COMPAT2='0' \ DIFF3='/usr/local/bin/diff3' DIFF3_BIN='1' \ DIFF='/usr/local/bin/diff' DIFFFLAGS='-an' DIFF_L='1' \ DIFF_SUCCESS='0' \ DIFF_FAILURE='1' \ DIFF_TROUBLE='2' \ ED='/bin/ed' \ LDFLAGS='' LIBS='' \ RCSPREFIX='/usr/local/bin/' \ SENDMAIL='"/usr/lib/sendmail"' \ /bin/sh -x ./conf.sh 3>&1 >a.h 2>conf.err ./conf.sh: testing permissions ... ./conf.sh: This command should not be run with superuser permissions. make[1]: *** [conf.h] Error 1. make[1]: Leaving directory `/usr/local/lib/rcs-5.7/src' make: *** [all] Error 2 ********************************end included portion************************** My questions here are, 1.Is this normal? or Is this a problem with something SCO specific? 2. If it is normal, why should this not be installed as root? (I did not find any such constraints in the INSTALL instruction file. I did proceed to install the whole thing as a user in the /usr/user_name directory by following the instructions. By setting the right permissions I have been able to get this to work for all the people that need to use this. But, are there any potential problems with this??? Thirdly...... I proceeded to install CVS 1.5 (as root)and in this I checked footnote 4 of the INSTALL file , but unlike the instruction to comment out the line include in server.c, which would puke out at the make command with the message: In file included from server.c /usr/include/sys/select.h:41; redefinition of `struct timeval' So I proceeded to comment the `include ' and remove the previous (recommended) comment line.. This seems to 'make' fine and not puke. I realized that the footnote 4 in INSTALL is from 1/4/93 which probably means an earlier version of cvs... Q: Am I okay with indiscriminate commenting of lines here??(ok, so it was not indiscriminate, maybe just an intelligent guess). At this point, assuming that cvs seemed to be installed, I proceeded to test things out and went through the motions of creating a repository etc etc. As far as I can see, everything (i.e cvs commands) seem to work as advertised. I however find that all the files checked out have a bunch of RCS info at the top of the file and the @ at the end of the file. I saw a post on this mailing list saying that the latest verison of RCS (5.7) should have fixed this bug. Q. Why am I getting the junk at the beginning and the @ in the end even though I have RCS 5.7? Is it safe to get rid of all that stuff, or does RCS need the information? I think I am going to throw these question out to you folks and reserve the further questions for a later post. I will also be posting this on the comp.software.config-management and comp.sco.unix newsgroups for a wider(?) audience. Thanks in advance krishna ***************************************************************************** Krishna AchutaRao krishna.achutarao@laitram.com R & D Engineer. The Laitram Corporation. New Orleans, LA. ***************************************************************************** *************************************************************************** Krishna AchutaRao E-mail: krishna.achutarao@laitram.com *************************************************************************** From info-cvs-ownrr@prep.ai.mit.edu Tue Sep 12 20:31:49 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id UAA25898 for ; Tue, 12 Sep 1995 20:31:47 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id SAA06013; Tue, 12 Sep 1995 18:10:30 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-non-local@gnu-life.ai.mit.edu id AA08750; Tue, 12 Sep 95 18:10:28 EDT Received: from titan.laitram.com ([204.251.4.251]) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-non-local@gnu-life.ai.mit.edu bug-cvs-non-local@gnu-life.ai.mit.edu id AA08585; Tue, 12 Sep 95 18:10:00 EDT Received: (from uucp@localhost) by titan.laitram.com (8.6.9/8.6.9) id RAA18246 for ; Tue, 12 Sep 1995 17:14:35 -0500 Received: from earth.laitram.com(204.251.5.74) by titan.laitram.com via smap (V1.3) id sma018242; Tue Sep 12 17:14:11 1995 Received: from mak.laitram.com (mak.laitram.com [204.251.5.84]) by earth.laitram.com (8.6.9/8.6.9) with SMTP id RAA13731 for ; Tue, 12 Sep 1995 17:02:17 -0500 From: Krishna.Achutarao@laitram.com To: info-cvs@prep.ai.mit.edu Subject: CVS Newbie Install [followup questions] Cc: mak@laitram.com X-Mailer: ScoMail 1.0 Date: Tue, 12 Sep 1995 17:07:29 -0500 (CDT) Message-Id: <9509121707.aa07607@mak.laitram.com> Status: RO Hi folks, Thanks a ton to everyone that replied to my first set of questions. I was quite enlightened by the replies that I received. The suggestion to run "make check" was given b y pretty much everyone that replied. I am happy to report that the check was completely successful. Yippee! I had to go through some contortions to find out that the BADROOT setting had to be disabled in src/options.h for me to run make check successfully as root. (If I had to install as root, should'nt there be a way to let sanity.sh take that into account?) After the check I turned back the BADROOT to not accept commits from root. The repository I had created (at this point there were no *real* files) must have been corrupt in some way when I first created them. When I decided to blow it all off and recreate the repository... the problem I had with RCS junk and @ symbol at the beginning and end of the files was gone. Strange! Now for the Level 2 questions (now that I seem to be out of the starting blocks :-) Q. I looked in the FAQ and web pages on CVS, but could not find anything about how CVS can be used on a network. We have a small cluster of 4 SCO machines and a server which is also where the installed CVS and repository are. As of now telneting to the server and working on it in their accounts is how the group is doing things. I would like to set it up so that each person has the repository NFS mounted and works on copies checked out. Is this the way net-people do it? Are there going to be any problems without either NTP or clock synchronization? I guess I am fishing for suggestions and/or experiences. Thanks.. once again krishna *************************************************************************** Krishna AchutaRao The Laitram Corporation. E-mail: krishna.achutarao@laitram.com. *************************************************************************** From info-cvs-ownrr@prep.ai.mit.edu Wed Sep 13 16:57:09 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id QAA01638 for ; Wed, 13 Sep 1995 16:57:09 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id OAA09951; Wed, 13 Sep 1995 14:06:16 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA29232; Wed, 13 Sep 95 14:06:09 EDT Received: from romulus.rutgers.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA29209; Wed, 13 Sep 95 14:05:53 EDT Received: (from vanembur@localhost) by romulus.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) id OAA11243; Wed, 13 Sep 1995 14:04:16 -0400 Date: Wed, 13 Sep 1995 14:04:16 -0400 From: Bill Van Emburg Message-Id: <199509131804.OAA11243@romulus.rutgers.edu> To: finken@conware.de Cc: info-cvs@prep.ai.mit.edu In-Reply-To: (finken@conware.de) Subject: Re: CVS - latest release? Status: RO We're up to 1.5 now, and it seems that cyclic is working on yet more nifty enhancements. I found a copy of the announcement message for 1.5, FYI. -BVE (er..that's Bill Van Emburg) (vanembur@remus.rutgers.edu) "You do what you want, and if you didn't, you don't" ============================================================ Date: Sun, 2 Jul 1995 23:41:19 -0400 From: James Kingdon Subject: CVS 1.5 now available The announcement for CVS 1.5 will be appearing on gnu.announce/info-gnu as soon as the moderator approves it, but the release is available at ftp://prep.ai.mit.edu/pub/gnu/cvs-1.5.tar.gz and will soon be on its mirror sites. For those who participated in the beta test program, diffs from 1.4.93 are available at: ftp://ftp.cyclic.com/pub/cvs/cvs-1.4.93-1.5.diff.gz ftp://alpha.gnu.ai.mit.edu/gnu/cvs-1.4.93-1.5.diff.gz If you have patches to submit for inclusion in the next release, *now* is the time to do so. Don't wait for there to be an announcement that the next release is in progress. Thanks to everyone who helped make this release possible. -- From info-cvs-ownrr@prep.ai.mit.edu Wed Sep 13 18:37:42 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id SAA05890 for ; Wed, 13 Sep 1995 18:37:41 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id QAA10303; Wed, 13 Sep 1995 16:13:40 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA08096; Wed, 13 Sep 95 16:13:35 EDT Received: from dayton.saic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA08055; Wed, 13 Sep 95 16:12:14 EDT Received: from llcoolj.dayton.saic.com.noname (llcoolj.dayton.SAIC.COM [139.121.26.6]) by dayton.saic.com (8.6.9/8.6.5) with SMTP id QAA09319; Wed, 13 Sep 1995 16:11:32 -0400 Received: by llcoolj.dayton.saic.com.noname (4.1/SMI-4.1) id AA11595; Wed, 13 Sep 95 16:13:10 EDT Date: Wed, 13 Sep 95 16:13:10 EDT Message-Id: <9509132013.AA11595@llcoolj.dayton.saic.com.noname> From: Mike Sutton To: raye.raskin@ia-us.com, info-cvs@prep.ai.mit.edu Cc: mws115@dayton.saic.com In-Reply-To: <9509131546.AA15290@masse.object> (raye.raskin@ia-us.com) Subject: Re: cvs update -j not working Status: RO >>>>> "-" == Raye Raskin x6880 writes: -> cvs update -j as shown below doesn't work. Should it? A few weeks ago a patch for cvs 1.5 was posted that solved this problem. Below is the patch. Mike Sutton | Life is hard when you're SAIC | home-pageless. Beavercreek, OH | Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's ----------------------cut line --------------------------------------- *** update.c Fri Aug 18 15:27:17 1995 --- update.c Fri Aug 18 15:25:45 1995 *************** *** 1496,1504 **** return; } ! /* skip joining identical revs */ ! if (strcmp (rev2, vers->vn_user) == 0) /* no merge necessary */ { free (rev2); return; } --- 1496,1505 ---- return; } ! /* skip joining non-relevant or identical revs */ ! if ( !vers->vn_user || (strcmp (rev2, vers->vn_user) == 0)) { + /* no merge necessary */ free (rev2); return; } From info-cvs-ownrr@prep.ai.mit.edu Thu Sep 14 14:37:25 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id OAA14028 for ; Thu, 14 Sep 1995 14:37:23 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id MAA13939; Thu, 14 Sep 1995 12:36:06 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA12628; Thu, 14 Sep 95 12:36:00 EDT Received: from oryx.com (bootlegger.oryx.COM) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA12542; Thu, 14 Sep 95 12:35:31 EDT Received: from jaguar.oryx.COM.atom by oryx.com (4.1/SMI-4.1) id AA12528; Thu, 14 Sep 95 11:35:00 CDT Date: Thu, 14 Sep 95 11:35:00 CDT From: Reg.Beardsley@oryx.com (Reg H. Beardsley) Message-Id: <9509141635.AA12528@oryx.com> To: info-cvs@prep.ai.mit.edu Status: RO Subject: repository reorganization? I have taken over a project which uses CVS for source code control. At present there are several copies of the same file stored in different directories. I would like to like to make CVS retrieve the file from the same place, e.g. each component would retrieve header files from a single RCS file. This came about because the programs were created by copying files and then the whole mess was stuck in CVS as is... Eventually, I need to do some major reorganization of the libraries since some exceed 250,000 lines. I have read Cederqvist's book, but don't see any simple way to do the restructuring without losing the ability to build older versions. Can you point me at a solution, (or say definitively that it can't be done)? Being able to use relative paths in the Entries file I think would work. Any hints greatly appreciated. thanks, Reg Beardsley rhb@acm.org ------- end ------- From info-cvs-ownrr@prep.ai.mit.edu Tue Sep 19 17:13:43 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id RAA29830 for ; Tue, 19 Sep 1995 17:13:42 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id NAA17479; Tue, 19 Sep 1995 13:34:47 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA09759; Tue, 19 Sep 95 13:34:43 EDT Received: from dayton.saic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA09717; Tue, 19 Sep 95 13:34:14 EDT Received: from llcoolj.dayton.saic.com.noname (llcoolj.dayton.SAIC.COM [139.121.26.6]) by dayton.saic.com (8.6.9/8.6.5) with SMTP id NAA16920; Tue, 19 Sep 1995 13:32:46 -0400 Received: by llcoolj.dayton.saic.com.noname (4.1/SMI-4.1) id AA04775; Tue, 19 Sep 95 13:34:31 EDT Date: Tue, 19 Sep 95 13:34:31 EDT Message-Id: <9509191734.AA04775@llcoolj.dayton.saic.com.noname> From: Mike Sutton To: tonyg@musky.moneng.mei.com, info-cvs@prep.ai.mit.edu In-Reply-To: <9509191624.AA04177@musky> (message from Tony Gargulak on Tue, 19 Sep 1995 11:24:26 -0500) Subject: Re: how to find files needing add/commit? Status: RO >>>>> "Tony" == Tony Gargulak writes: Tony> Is there any way within cvs to find all local files that are Tony> unknown to cvs? cvs -n update | grep '^\?' This will NOT update anything. All unknown files are prefaced with a question mark. Mike Sutton | Life is hard when you're SAIC | home-pageless. Beavercreek, OH | Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's From info-cvs-ownrr@prep.ai.mit.edu Wed Sep 20 12:56:02 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id MAA02936 for ; Wed, 20 Sep 1995 12:56:00 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id KAA21243; Wed, 20 Sep 1995 10:27:19 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06297; Wed, 20 Sep 95 10:27:15 EDT Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06279; Wed, 20 Sep 95 10:27:02 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Wed, 20 Sep 95 10:26:52 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Wed, 20 Sep 95 10:26:52 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: Graham Stoney Cc: info-cvs@prep.ai.mit.edu Subject: Re: how to find files needing add/commit? In-Reply-To: Graham Stoney's message of "Wed, September 20, 1995 10:13:31 +1000" regarding "Re: how to find files needing add/commit?" id <199509200013.KAA08460@miles.research.canon.com.au> References: <9509191624.AA04177@musky> <199509200013.KAA08460@miles.research.canon.com.au> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Wed, September 20, 1995 at 10:13:31 (+1000), Graham Stoney wrote: ] > Subject: Re: how to find files needing add/commit? > > "cvs update" tells you about unknown files (but not unknown directories, > unfortunately). If you educate your users to always run an update before > every commit, the problem may not be so severe. You need to update anyway if > the commit finds any files that aren't up to date, so you may as well do it > before every commit. It does tell you about unknown directories -- it just doesn't tell you that they are directories, though presumably that shouldn't be such a hard thing to discover on your own.... ttyp9: $ mkdir foo ttyp9: $ cvs -nq update ? foo -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Wed Sep 20 16:57:13 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id QAA05167 for ; Wed, 20 Sep 1995 16:57:11 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id OAA21969; Wed, 20 Sep 1995 14:25:49 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA21613; Wed, 20 Sep 95 14:25:46 EDT Received: from sander.sander.cupertino.ca.u ([192.148.188.3]) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA21588; Wed, 20 Sep 95 14:25:25 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA11788; Wed, 20 Sep 95 11:28:36 PDT Date: Wed, 20 Sep 95 11:28:36 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9509201828.AA11788@sander.sander.cupertino.ca.us> To: woods@most.weird.com Subject: Re: how to find files needing add/commit? Cc: info-cvs@prep.ai.mit.edu, tonyg@musky.moneng.mei.com Status: RO woods@most.weird.com (Greg A. Woods) wrote: >[ On Tue, September 19, 1995 at 17:51:57 (PDT), Paul Sander wrote: ] >> Subject: Re: how to find files needing add/commit? >> >> cvs -n update -I\! >Why the '-I\!'? Won't this catch all the files you'd likely rather have >it ignore? If you recall the original question, it asked how to discover all of the files unknown to CVS. A $HOME/.cvsignore file may provide a more useful ignore list. (After all, some people NEED to keep Ada source [*.a] under source control. Others NEED to keep vendor-supplied archives under source control, and still others want to ignore locally-build shared libraries.) > And why not "-I '!'" (i.e. use a separating space to keep >getopt(3) happy)? getopt(3) works just fine without a space. csh also requires a backslash to prevent history substitution. > [Note also that you don't need to quote the '!' if >you use /bin/sh.] Same with ksh. But the backslash is valid in every shell I'm familiar with. Paul -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-ownrr@prep.ai.mit.edu Wed Sep 20 13:33:52 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id NAA01822 for ; Wed, 20 Sep 1995 13:33:50 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id KAA21309; Wed, 20 Sep 1995 10:52:50 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA07870; Wed, 20 Sep 95 10:52:47 EDT Received: from teloseng.com (frog.teloseng.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA07857; Wed, 20 Sep 95 10:52:31 EDT Received: by teloseng.com (5.65/1.2-eef) id AA20315; Wed, 20 Sep 95 07:52:29 -0700 Message-Id: <9509201452.AA20315@teloseng.com> From: wolfe@@teloseng.com (null) (Peter Wolfe) To: info-cvs@prep.ai.mit.edu Subject: Re: how to find files needing add/commit? X-Mailer: ScoMail 1.0 Date: Wed, 20 Sep 1995 7:52:28 -0700 (PDT) Status: RO > Is there any way within cvs to find all local files that are unknown to > cvs? A cvs status performed _explicitly_ on an unknown file tells you > the file's status is unknown, but you have to know the file is unknown > in the first place which defeats its purpose. 'cvs status .' unfortunately > ignores unknown files. Other people have offered solution based on cvs status. We use cvs log here. The basic outline is as follows: 1. our makefiles list *all* source files (i.e. files in CVS) 2. our makefiles have a incvs target which does the following: cvs log -h > /dev/null $(SOURCE_FILES) *.h --- Peter Wolfe wolfe@teloseng.com Telos Engineering Limited From info-cvs-ownrr@prep.ai.mit.edu Wed Sep 20 11:43:04 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id LAA21146 for ; Wed, 20 Sep 1995 11:42:54 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id IAA21041; Wed, 20 Sep 1995 08:22:26 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA29762; Wed, 20 Sep 95 08:22:23 EDT Received: from ace2.ncsc.navy.mil by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA29740; Wed, 20 Sep 95 08:22:10 EDT Received: by ace2.ncsc.navy.mil (UCX V3.2 AXP) Wed, 20 Sep 1995 07:19:59 -0500 Received: from cc:Mail by CCMAIL.NCSC.NAVY.MIL id AA811606695; Wed, 20 Sep 95 07:15:01 CDT Date: Wed, 20 Sep 95 07:15:01 CDT From: algeej@ccmail.ncsc.navy.mil Encoding: 64 Text Message-Id: <9508208116.AA811606695@CCMAIL.NCSC.NAVY.MIL> To: tonyg@mei.com Subject: Re: how to find files needing add/commit? Status: RO > We've been using cvs quite successfully for the past 6 months. > However, by far our largest problem is forgetting to add and commit > a file resulting in successful local builds but failures building > everywhere else. > > Is there any way within cvs to find all local files that are unknown to > cvs? A cvs status performed _explicitly_ on an unknown file tells you > the file's status is unknown, but you have to know the file is unknown > in the first place which defeats its purpose. 'cvs status .' unfortunately > ignores unknown files. > > Any ideas would be greatly appreciated. Here are a couple of ways that it can be done. (We set up a couple of scripts in /usr/local. You will have to adjust it for the specific text string in your version of cvs.) 1. TO GET A LISTING AND MANUALLY INVOKE cvs Modified files are found by: cvs status * | grep 'Locally Modified' New files are found by: cvs status * | grep 'Unknown' 2. TO HAVE THEM AUTOMATICALLY UPDATED/ADDED/DELETED: a. Copy the 3 files below to your disk. b. Make all files executable. c. Substitute the ./cmdirectory with the appropriate target Of course, you can get fancy and use a command line attribute (i.e., $1) and include all sorts of error checking. first file ... cvsupd.sh ---- snip ----- cvs -n update ./cmdirectory > cvsstat ## fakes the update command awk -f cvsstat.awk cvsstat > cvsupdawk.sh ## process the following awk file cvsupdawk.sh ## execute awk results ---- snip ----- second file ... cvsstat.awk ---- snip ----- { if ( $1 == "A" ) ## Files added but not committed { print 'cvs commit ' $2 } if ( $1 == "R" ) ## Files removed but not committed { print 'cvs commit ' $2 } if ( $1 == "?" ) ## Files with an unknown status { print 'cvs add ' $2 print 'cvs commit ' $2 } } ---- snip ----- third file ... cvsupdawk.sh ---- snip ----- ## Dummy file that is the output of the awk command ---- snip ----- From info-cvs-ownrr@prep.ai.mit.edu Tue Sep 19 22:45:26 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id WAA28164 for ; Tue, 19 Sep 1995 22:45:25 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id UAA18639; Tue, 19 Sep 1995 20:48:09 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA08316; Tue, 19 Sep 95 20:48:06 EDT Received: from sander.sander.cupertino.ca.u ([192.148.188.3]) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA08303; Tue, 19 Sep 95 20:47:51 EDT Received: by sander.sander.cupertino.ca.us (5.64/A/UX-3.00) id AA11108; Tue, 19 Sep 95 17:51:57 PDT Date: Tue, 19 Sep 95 17:51:57 PDT From: paul@sander.cupertino.ca.us (Paul Sander) Message-Id: <9509200051.AA11108@sander.sander.cupertino.ca.us> To: info-cvs@prep.ai.mit.edu, tonyg@musky.moneng.mei.com Subject: Re: how to find files needing add/commit? Status: RO Tony Gargulak wrote: >Is there any way within cvs to find all local files that are unknown to >cvs? A cvs status performed _explicitly_ on an unknown file tells you >the file's status is unknown, but you have to know the file is unknown >in the first place which defeats its purpose. 'cvs status .' unfortunately >ignores unknown files. cvs -n update -I\! This will list all of the files that have not been committed or are not known to CVS. The ones marked with a "?" need to be added. -- Paul M. Sander | Every journey begins with one small step. What paul@sander.cupertino.ca.us | the hell, let's go. -- Capt. Bridger, Seaquest From info-cvs-ownrr@prep.ai.mit.edu Mon Sep 18 12:42:26 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id MAA17234 for ; Mon, 18 Sep 1995 12:42:23 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id KAA08631; Mon, 18 Sep 1995 10:20:44 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA17736; Mon, 18 Sep 95 10:20:39 EDT Received: from spsgate.sps.mot.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA17723; Mon, 18 Sep 95 10:20:28 EDT Received: from mogate (mogate.sps.mot.com) by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA08851 for info-cvs@prep.ai.mit.edu; Mon, 18 Sep 95 07:20:25 MST Received: from motsps by mogate (4.1/SMI-4.1/Email-2.0) id AA06867; Mon, 18 Sep 95 07:20:23 MST Received: from risc.sps.mot.com by motsps (4.1/SMI-4.1/Email-2.1) id AA02024 for info-cvs@prep.ai.mit.edu; Mon, 18 Sep 95 07:20:20 MST Received: from miaow.sps.mot.com by risc.sps.mot.com (4.1/SMI-3.0DEV3) id AA10868; Mon, 18 Sep 95 09:20:16 CDT Received: by miaow.sps.mot.com (AIX 3.2/UCB 5.64/4.03) id AA13466; Mon, 18 Sep 1995 09:20:14 -0500 From: dwolfe@risc.sps.mot.com (Dave Wolfe) Message-Id: <9509181420.AA13466@miaow.sps.mot.com> Subject: Re: cvs with perl, setuid problem again To: vdemarco@bou.shl.com (Vince Demarco) Date: Mon, 18 Sep 1995 09:20:14 -0500 (CDT) Cc: krk@c3serve.c3.lanl.gov, info-cvs@prep.ai.mit.edu, infan@mpd.tandem.com In-Reply-To: <9502201059.AA03942@bou.shl.com> from "Vince Demarco" at Sep 17, 95 04:06:23 pm Reply-To: David Wolfe X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 547 Status: RO [ Vince Demarco writes: ] > > Although this will work the easiest way is this: > > put all of the developers in the same group > set the group sticky bit on all directories in the repository > (this will ensure that the group permissions are correct > regardless of who checks in the code) Providing that the those checking in files don't have their umask set too restrictively, e.g. no more than 007. -- Dave Wolfe *Not a spokesman for Motorola* (512) 891-3246 Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598 From info-cvs-ownrr@prep.ai.mit.edu Fri Sep 15 20:01:31 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id UAA28727 for ; Fri, 15 Sep 1995 20:01:30 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id SAA21267; Fri, 15 Sep 1995 18:25:11 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA17109; Fri, 15 Sep 95 18:25:07 EDT Received: from motgate.mot.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA17093; Fri, 15 Sep 95 18:24:52 EDT Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.6.11/8.6.10/MOT-3.8) with ESMTP id RAA21953 for ; Fri, 15 Sep 1995 17:24:43 -0500 Received: from motsat.sat.mot.com (motsat.sat.mot.com [192.111.236.254]) by pobox.mot.com (8.6.11/8.6.10/MOT-3.8) with SMTP id RAA02467 for ; Fri, 15 Sep 1995 17:24:41 -0500 Received: from goodsenium.sat.mot.com by motsat.sat.mot.com with SMTP id AA02941 (5.65c/IDA-1.4.4 for ); Fri, 15 Sep 1995 15:26:51 -0700 Received: by goodsenium.sat.mot.com (5.x/SMI-SVR4) id AA24419; Fri, 15 Sep 1995 15:25:00 -0700 Date: Fri, 15 Sep 1995 15:25:00 -0700 Message-Id: <9509152225.AA24419@goodsenium.sat.mot.com> To: info-cvs@prep.ai.mit.edu From: jgoodsen@radsoft.com Subject: Re: CVS and Makefiles Status: RO > > On Fri, 15 Sep 1995 norton@nrlmry.navy.mil wrote: > > > How does one go about incorporating CVS into a Makefile or Makefile > > system besides a simply checkout rule. > My guess is that you want to do something similar to how Makefiles do it with RCS or SCCS. When you're just using raw RCS or SCCS, you want this behavior because of the missing functionality to manage entire directories (or better yet, full directory trees) which is exactly what CVS excels at. Just fire off a CVS update -l in the local directory and then reinvoke Make from within the makefile to rebuild all out of date sources, like this: -- snip snip -- .c.o: MAIN_OBJ = myprog.o OBJS = foo.o bar.o ## Invoke an update, and reinvoke Make all: cvs update -l make myprog myprog: $(OBJS) $MAIN_OBJ) cc -o myprog $(MAIN_OBJ) $(OBJS) -- snip snip -- -- John Goodsen jgoodsen@dalmatian.com The Dalmatian Group, Inc http://www.indirect.com/www/radsoft/ User Interface Specialists ** RAD/CVS Home Page is now at http://www.indirect.com/www/radsoft/radcvs/ ** From info-cvs-ownrr@prep.ai.mit.edu Thu Sep 14 13:03:56 1995 Received: from ulowell.uml.edu (ulowell.uml.edu [129.63.1.1]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with SMTP id NAA05452 for ; Thu, 14 Sep 1995 13:03:55 -0400 Received: from gnu-life.ai.mit.edu by ulowell.uml.edu with SMTP id AA08849 (5.67b/IDA-1.5 for ); Thu, 14 Sep 1995 13:03:59 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id JAA13373; Thu, 14 Sep 1995 09:50:39 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA01308; Thu, 14 Sep 95 09:50:34 EDT Received: from sunl.cr.usgs.gov by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA01274; Thu, 14 Sep 95 09:49:57 EDT Received: from dlger.cr.usgs.gov by sunl.cr.usgs.gov (4.1/SMI-3.2) id AA22812; Thu, 14 Sep 95 08:49:48 CDT Received: by dlger.cr.usgs.gov (5.4R2.01/1.34) id AA06033; Thu, 14 Sep 1995 08:31:03 -0500 Date: Thu, 14 Sep 1995 08:31:03 -0500 (CDT) From: Jo Wahle To: Stefan Monnier Cc: info-cvs@prep.ai.mit.edu Subject: Re: Recovering deleted files In-Reply-To: <21548.811065687@lia.di.epfl.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Thu, 14 Sep 1995, Stefan Monnier wrote: > Jo Wahle wrote: > > "cvs update -r ", assuming that CVS would check the Attics for > > files that had since been removed, and would restore them. It did not. > > Isn't your problem related to the fact that a plain 'cvs update' only > updates existing directories ? Since you pruned the now empty directories, > when you did the update, the directory didn't get updated. I have 'update -d' > in my .cvsrc to avoid such problems (it prevents me from checking out incomplete > directory structures, but I don't really care) I think you're right. I did "cvs checkout -r " from scratch on another machine, and the deleted directory was resurrected, along with the files below it. Then I tried removing the directory again from my real working directory, and did "cvs update -d -r ", and the directory and files were resurrected as I expected. So, the functionality is available. Could possibly be an addition to the FAQ, I guess, unless someone out there writes that rename database sometime soon. ... I think I'll try to find an appropriate place in the FAQ. :-) ====================================================================== || Make 'em think you're crazy: || --Jo || || "Practice random acts of kindness || Software Developer || || and senselss acts of beauty." || wahle@dlger.cr.usgs.gov || || -- Anne Herbert, 1990 || Hughes STX (EROS Data Ctr) || ====================================================================== Disclaimer -- Ideas expressed here are my own and not those of Hughes STX nor of the government ... etc., etc. ... (If this had been an official document representing either entity, you would know it!) ====================================================================== From info-cvs-ownrr@prep.ai.mit.edu Fri Sep 22 12:30:56 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id MAA05977 for ; Fri, 22 Sep 1995 12:30:54 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id JAA04475; Fri, 22 Sep 1995 09:55:43 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA01138; Fri, 22 Sep 95 09:55:39 EDT Received: from solen.gac.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA01123; Fri, 22 Sep 95 09:55:24 EDT Received: from gac.edu (guenther@lunen.gac.edu [138.236.128.17]) by solen.gac.edu (8.6.12/8.6.12) with ESMTP id IAA13054; Fri, 22 Sep 1995 08:55:20 -0500 Message-Id: <199509221355.IAA13054@solen.gac.edu> To: ALEX@dspse.com (Alex Urquizo) Cc: info-cvs@prep.ai.mit.edu Subject: Re: Creating Repository with CVS import In-Reply-To: Your message of "Thu, 21 Sep 1995 20:38:19 EST." <199509220101.SAA05469@netcomsv.netcom.com> Date: Fri, 22 Sep 1995 08:55:20 -0500 From: Philip Guenther Status: RO >I am using the command --> cvs import -m "message" to create a new project in my repository. > >This command puts the project in a vendor branch version 1.1.1 > >Reading the manual I see that the first version of a file in the >Main Branch (Line of Development) is 1.1 > >How can I go from the Vendor branch to the Main Branch??. No need. cvs import (the first time) will actually create 2 revisions. 1.1 contains the version you imported, and 1.1.1.1 is a standard RCS version that contains no diffs form 1.1 (it's parent). Note that the first revision in an RCS file _must_ be on the main branch (that is, have one dot in it's number). Thus the two revisions in one that cvs import does the first time. After that, it can just through the revisions on the end of the 1.1.1 branch (vendor branch). When you first make local changes to a file and commit it, you will create revision 1.2, and cvs will switch the "current branch" for that file to be the main branch. >I understand that initially the Vendor Branch and CVS Main Branch point to >the same location but when i do a "cvs status -v file" it gives information >related to the revision 1.1.1 (vendor branch) and not version 1.1 (Main >Branch) You're getting RCS branches and CVS branches confused. The RCS 1.1.1 branch is the CVS vendor branch. However, the CVS vendor branch is considered to be part of the CVS main branch. In some sense, the CVS main branch consists of the revisions of the CVS vendors branch, with local revisions interspersed among the vendor versions. It just so happens that CVS keeps this clean by storing the two types of revisions on two different _RCS_ branches (the trunk and 1.1.1), and uses the RCS default branch "flag" to keep track of which is the current end of the _CVS_ main branch. Does that make sense? Philip Guenther ---------------------------------------------------------------- Philip Guenther UNIX Systems and Network Administrator Internet: guenther@gac.edu Phonenet: (507) 933-7596 Gustavus Adolphus College St. Peter, MN 56082-1498 I am _not_ a representative sample of the Gustavus Community. Yeah, right... Source code never lies (it just misleads). (Programming by Purloined Letter?) From info-cvs-ownrr@prep.ai.mit.edu Mon Sep 25 07:50:06 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id HAA06261 for ; Mon, 25 Sep 1995 07:47:57 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id FAA03329; Mon, 25 Sep 1995 05:33:20 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA25969; Mon, 25 Sep 95 05:33:14 EDT Received: from ensta.ensta.fr by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA25918; Mon, 25 Sep 95 05:25:59 EDT Received: from itesec.hsc-sec.fr (itesec.hsc-sec.fr [192.70.106.33]) by ensta.ensta.fr (8.7/8.7) with ESMTP id KAA19294; Mon, 25 Sep 1995 10:25:51 +0100 (MET) Received: (from roberto@localhost) by itesec.hsc-sec.fr (8.7/8.7/itesec-1.4) id KAA01208; Mon, 25 Sep 1995 10:26:59 +0100 (MET) From: Ollivier Robert Message-Id: <199509250926.KAA01208@itesec.hsc-sec.fr> Subject: Re: CVS 1.5.1 development To: Ian.Mathieson@mel.dit.csiro.au (Ian Mathieson) Date: Mon, 25 Sep 1995 10:26:59 +0100 (MET) Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <199509220538.AA19518@shark.mel.dit.csiro.au> from "Ian Mathieson" at Sep 22, 95 03:38:52 pm X-Mailer: ELM [version 2.4 PL24 ME7a+] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Status: RO It seems that Ian Mathieson said: > At the moment, I'm building some perl wrappers around CVS 1.5.1 to > provide an authenticated (and perhaps even encrypted) connection > between a client and server over firewalls, using SSL or PGP or > somesuch. I will share the wrappers if others are interested (once > I've got them running :-). There is something you could use: SSH. SSH is a complete replacement for rsh/rlogin and rcp, with IDEA/DES/RC4 encryption and RSA authentication. I don't know how it could be integrated into CVS but it is worth considering. ftp://ftp.cs.hut.fi/pub/ssh/ -- Ollivier ROBERT -=-=- Hervi Schauer Consultants -=-=- roberto@hsc.fr.net -=-=-=-=-=- Support The Free UNIX Systems ! FreeBSD Linux NetBSD -=-=-=-=-=- From info-cvs-ownrr@prep.ai.mit.edu Mon Sep 25 08:17:19 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id IAA17147 for ; Mon, 25 Sep 1995 08:17:18 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id FAA03436; Mon, 25 Sep 1995 05:36:58 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA26003; Mon, 25 Sep 95 05:36:54 EDT Received: from geech.gnu.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA25994; Mon, 25 Sep 95 05:36:45 EDT Received: from terpsichore.sse.ie by geech.gnu.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id FAA17694 for ; Mon, 25 Sep 1995 05:31:15 -0400 Received: by terpsichore.sse.ie (AIX 3.2/UCB 5.64/4.03) id AA26863; Mon, 25 Sep 1995 10:34:23 +0100 Date: Mon, 25 Sep 1995 10:34:23 +0100 From: Adrian Colley To: Ian Mathieson Cc: info-cvs@gnu.ai.mit.edu Subject: Re: secure cvs In-Reply-To: <199509250529.AA21799@shark.mel.dit.csiro.au> References: <199509250529.AA21799@shark.mel.dit.csiro.au> Reply-To: Adrian.Colley@three.serpentine.com Organization: Pansilvan-eschatological Dendrochronology X-Pgp-Key-Location: http://wuh.three.serpentine.com/u/aecolley/pgpkee X-Pgp-Key-Fingerprint: 09 B5 08 B2 CB E6 D9 5E 60 62 FA 02 89 48 CF 5D Message-Id: <6714834.fnord246480@three.serpentine.com> X-Nsa-Fodder: domestic disruption Honduras Exon Status: RO "Ian>" == Ian Mathieson Ian> Tell me more about your ssh version of cvs 1.5. It sounds like you've Ian> saved me some trouble. SSH isn't mine; it was written by Tatu Ylonen . For more information, look at . Or just FTP it from ftp.cs.hut.fi:/pub/ssh/ssh-1.2.0.tar.gz if you're reckless. It can function as a drop-in replacement for rsh, but will prompt the user for a password/passphrase, using an X dialogue box if necessary. OK, enough blurb. --adrian. http://wuh.three.serpentine.com/u/aecolley/ From info-cvs-ownrr@prep.ai.mit.edu Sun Sep 24 16:52:45 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id QAA24348 for ; Sun, 24 Sep 1995 16:52:41 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id PAA29524; Sun, 24 Sep 1995 15:28:53 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA28988; Sun, 24 Sep 95 15:28:50 EDT Received: from bou.shl.com (dilbert.bou.shl.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA28977; Sun, 24 Sep 95 15:28:35 EDT Received: from butthead by bou.shl.com (NX5.67e/NX3.0Ma) id AA10549; Sun, 24 Sep 95 12:28:34 -0700 Message-Id: <9509241928.AA10549@bou.shl.com> Received: by butthead.bou.shl.com (NX5.67e/NX3.0X) id AA00236; Sun, 24 Sep 95 12:28:31 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Vince DeMarco Date: Sun, 24 Sep 95 12:28:12 -0700 To: woods@most.weird.com (Greg A. Woods) Subject: Re: CVS TODO Cc: info-cvs@prep.ai.mit.edu References: <14126.811784481@lia.di.epfl.ch> <9509221729.AA07115@bou.shl.com> <9509230101.AA08551@bou.shl.com> Status: RO Hey, >> I wrote >> Subject: Re: CVS TODO >> >> I'm not suggesting that you use the wrappers code to do this. All i am >> really saying is that it is possible. > >sorry -- my "hmmm" was more intended as my opinion about the wrappers >stuff, and about your suggestion to use them! ;-) You are right about the current version not being the best tool for the job. But given the current tool set out there doesn't seem to be any better alternatives. What i really need for my nextstep program is some addition to cvs that will allow it to transparently manage certain directories. Ie if a file gets added to a directory tree, cvs will automatically notice this new file and add it to the repository. (to get this functionality the wrappers code was added. The current implementation works, and it is far from perfect, but...) >I'm just not sure they're the most elegant solution to *any* problem! ;-) > >> other possible uses of the wrappers code would be to take a framemaker >> document and convert it to a mif file before checking it in, and maybe >> converting it back to a frame document on checkout. This way you end up >>with >> a text file that you **may** be able to merge. >Yes, they do make some tasks possible without having to modify the more >fundamental tools, such as RCS.... ;-) >A nice parser-tree based DBMS with tools that perform syntax based >merging would be ideal for programming languages! Unfortunately I seems >that such things didn't get much beyond the research in the early 80's. Taligent has a tool called HOOPS that does this. Its all driven graphically and it seemed very impressive (i saw a demo of it at Object World). To me it looked like a very nice front end to diff and a version control system. vince From info-cvs-ownrr@prep.ai.mit.edu Fri Sep 22 22:36:11 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id WAA23078 for ; Fri, 22 Sep 1995 22:36:10 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id VAA08982; Fri, 22 Sep 1995 21:01:55 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA11040; Fri, 22 Sep 95 21:01:53 EDT Received: from bou.shl.com (dilbert.bou.shl.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA11030; Fri, 22 Sep 95 21:01:42 EDT Received: from butthead by bou.shl.com (NX5.67e/NX3.0Ma) id AA08551; Fri, 22 Sep 95 18:01:30 -0700 Message-Id: <9509230101.AA08551@bou.shl.com> Received: by butthead.bou.shl.com (NX5.67e/NX3.0X) id AA00247; Fri, 22 Sep 95 18:01:27 -0700 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Vince DeMarco Date: Fri, 22 Sep 95 18:01:10 -0700 To: woods@most.weird.com (Greg A. Woods) Subject: Re: CVS TODO Cc: info-cvs@prep.ai.mit.edu References: <14126.811784481@lia.di.epfl.ch> <9509221729.AA07115@bou.shl.com> Status: RO I apologize for my poor grammar. I really should start proof reading my mail before i press the deliver button. I'm not suggesting that you use the wrappers code to do this. All i am really saying is that it is possible. Right now i am using the wrappers code to package up directories before checking them in. (This is under NEXTSTEP. Most/All next apps create directory packages as a container for a document, ie a text document, interface description etc) other possible uses of the wrappers code would be to take a framemaker document and convert it to a mif file before checking it in, and maybe converting it back to a frame document on checkout. This way you end up with a text file that you **may** be able to merge. vince Begin forwarded message: Date: Fri, 22 Sep 95 16:16:19 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: Vince Demarco Cc: info-cvs@prep.ai.mit.edu, kingdon@harvey.cyclic.com Subject: Re: CVS TODO In-Reply-To: Vince Demarco's message of "Fri, September 22, 1995 11:29:17 -0600" regarding "CVS TODO" id <9509221729.AA07115@bou.shl.com> References: <14126.811784481@lia.di.epfl.ch> <9509221729.AA07115@bou.shl.com> [ On Fri, September 22, 1995 at 11:29:17 (-0600), Vince Demarco wrote: ] > Subject: CVS TODO > > There is a TODO entry in the cvs-1.5.1 code that says the following: > > 136. Is it possible to specify a command to be run on each > file when it is checked out and another command to > be run before it is checked in? > > My idea of how this feature would be used: > On checkout: > run indent with user's preferred style > On checkin: > run indent with space-saving, style-free for > checkin I've a comment about this wee nugget: You do *not* want to reduce the repository version to a style-free format, lest you loose all ability to merge your code. If anything you should pretty-print the code into the most diff'able possible style, and add lots of newlines between code objects such as delcarations and definitions such that nearby changes won't be considered together. Of course then you've got to do the merges in the internal "style", and perhaps you'd want to re-format to the personal style before handing the merged result to the programmer, but if the merge breaks the syntax of the code, heaven help the re-formatter! Time for language structure editors and repositories before we go this far though, me thinks.... > Well this all possible right now with the support of the wrappers code. hmm.... -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Fri Sep 22 21:14:15 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id VAA29356 for ; Fri, 22 Sep 1995 21:14:04 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id TAA08487; Fri, 22 Sep 1995 19:32:49 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA07310; Fri, 22 Sep 95 19:32:45 EDT Received: from most.weird.com (mail.weird.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA07265; Fri, 22 Sep 95 19:31:03 EDT Received: by mail.weird.com via sendmail with stdio id for info-cvs@prep.ai.mit.edu; Fri, 22 Sep 95 16:16:19 -0400 (EDT) (/\##/\ Smail3.1.30.13 #30.1 built 9-jul-95) Message-Id: Date: Fri, 22 Sep 95 16:16:19 -0400 (EDT) From: woods@most.weird.com (Greg A. Woods) To: Vince Demarco Cc: info-cvs@prep.ai.mit.edu, kingdon@harvey.cyclic.com Subject: Re: CVS TODO In-Reply-To: Vince Demarco's message of "Fri, September 22, 1995 11:29:17 -0600" regarding "CVS TODO" id <9509221729.AA07115@bou.shl.com> References: <14126.811784481@lia.di.epfl.ch> <9509221729.AA07115@bou.shl.com> Reply-To: woods@most.weird.com (Greg A. Woods) X-Mailer: ViewMail (vm) Version 5.72 (beta) with GNU Emacs 19.28.1 (m68k-sun-sunos4.1.1_U1) of Thu Mar 9 1995 on most Organization: Planix, Inc.; Toronto, Ontario; Canada Status: RO [ On Fri, September 22, 1995 at 11:29:17 (-0600), Vince Demarco wrote: ] > Subject: CVS TODO > > There is a TODO entry in the cvs-1.5.1 code that says the following: > > 136. Is it possible to specify a command to be run on each > file when it is checked out and another command to > be run before it is checked in? > > My idea of how this feature would be used: > On checkout: > run indent with user's preferred style > On checkin: > run indent with space-saving, style-free for > checkin I've a comment about this wee nugget: You do *not* want to reduce the repository version to a style-free format, lest you loose all ability to merge your code. If anything you should pretty-print the code into the most diff'able possible style, and add lots of newlines between code objects such as delcarations and definitions such that nearby changes won't be considered together. Of course then you've got to do the merges in the internal "style", and perhaps you'd want to re-format to the personal style before handing the merged result to the programmer, but if the merge breaks the syntax of the code, heaven help the re-formatter! Time for language structure editors and repositories before we go this far though, me thinks.... > Well this all possible right now with the support of the wrappers code. hmm.... -- Greg A. Woods +1 416 443-1734 VE3TCP robohack!woods Planix, Inc. ; Secrets of the Weird From info-cvs-ownrr@prep.ai.mit.edu Wed Sep 27 18:39:45 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id SAA12318 for ; Wed, 27 Sep 1995 18:39:43 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id QAA18656; Wed, 27 Sep 1995 16:46:22 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA04885; Wed, 27 Sep 95 16:46:16 EDT Received: from server.bridgeway.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA04854; Wed, 27 Sep 95 16:45:56 EDT Received: (from kfh@localhost) by server.bridgeway.com (8.6.9/8.6.9) id NAA13541; Wed, 27 Sep 1995 13:46:26 -0700 Date: Wed, 27 Sep 1995 13:46:25 -0700 (PDT) From: Karen Hensley To: Bob Fehrenbach Cc: info-cvs@prep.ai.mit.edu Subject: Re: Documentation In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: OR Try the command "info cvs" to see if you can read the manual online Try the command "info info" to see if the online info manual tells you how to strip info or texi files. Try the FAQ provided with the distribution for some of the best docs. Try reading GETTING.GNU.SOFTWARE at ftp prep.ai.mit.edu pub/gnu for pointers to hard copy docs. Try getting texinfo-3.6.tar.gz at the same place to let you build the on-line document reader, and may well have directions how to strip the file you want to read if you don't want to install info. Good Luck - Karen ============================================================================= Karen Hensley Bridgeway Corporation Manager of Software Development Bridging the Gap in Network Mgt. My opinions may not be Bridgeway's. On Wed, 27 Sep 1995, Bob Fehrenbach wrote: > The manual files in the archive I have contain all sorts of formatting > information and I have been unsuccessful in converting them to something > I can read. I have tried a number of conversion utilities but none have > been very effective. > > Does a straight ascii text version of the documentation exist for CVS? > > If not, is there a place where a hard copy version might be obtained? > > -------- > Bob Fehrenbach Wauwatosa, WI bfehrenb@execpc.com > From info-cvs-ownrr@prep.ai.mit.edu Wed Sep 27 17:15:55 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id RAA23399 for ; Wed, 27 Sep 1995 17:15:54 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id OAA17967; Wed, 27 Sep 1995 14:12:57 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA24943; Wed, 27 Sep 95 14:12:54 EDT Received: from mail.swip.net by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA24843; Wed, 27 Sep 95 14:12:23 EDT Received: from bull.se by mail.swip.net (8.6.8/3.01) id TAA13933; Wed, 27 Sep 1995 19:19:04 +0100 Received: from comserv.bull.se by bull.se with smtp (Smail3.1.28.1 #8) id m0sy0xK-0000xAC; Wed, 27 Sep 95 19:11 MET Received: from ml by comserv.bull.se with uucp (Smail3.1.28.1 #2) id m0sy119-0000gEC; Wed, 27 Sep 95 20:15 MET Received: by ml.link.bull.se (Smail3.1.28.1 #5) id m0sy0xs-000AsNC; Wed, 27 Sep 95 19:12 MET Message-Id: Date: Wed, 27 Sep 95 19:12 MET To: stefan.monnier@epfl.ch Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <28127.812219072@lia.di.epfl.ch> (stefan.monnier@epfl.ch) Subject: Re: need a smart diff tool From: Linus Tolke Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Status: OR From: "Stefan Monnier" Date: Wed, 27 Sep 1995 17:24:32 +0100 Sender: monnier@lia.di.epfl.ch Jim Blandy wrote: > Marc Paquette says: > >Use "ediff" or "emerge" in XEmacs. > point out that Emerge is also available on the FSF's distribution of Those details aside, could anyone tell me how to use ediff (or emerge) on a buffer resulting from a cvs update ? I know how to use them when I have to compare/merge distinct files/buffers, but don't know how to use them on a single rcsmerged buffer. Or is there some VC wrapper that can do it for me? If you use the pcl-cvs cvs-wrapper (this work entirely different than the VC wrapper but they can be used in combination) and you use a *real* FSF emacs (:-) there is a possibility to run an emerge against what is in the repository. Just type 'e' at the file you want to compare and pcl-cvs will check out the most recent version in that branch and give you your changes as buffer A and the repositorys version in buffer B. When you exit the emerge the merge result is saved as you new version. (For all you XEmacs freaks I can mention that you have access to the same function in the pcl-cvs menu "CVS". It is called "Interactively merge (emerge)"). To be able to appreciate this you probably will have to learn "the pcl-cvs way of doing things" as opposed to "the VC way of doing things". The pcl-cvs way is in my opinion an approach that better follows the intentions of cvs instead of the RCS/SCCS-per file approach implemented by VC. In short: You cannot run it directly from a buffer visiting the file but instead you will have to run it from your *cvs*-buffer. /Linus From info-cvs-ownrr@prep.ai.mit.edu Tue Sep 26 20:18:22 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id UAA06770 for ; Tue, 26 Sep 1995 20:18:21 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id SAA12516; Tue, 26 Sep 1995 18:06:08 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA13370; Tue, 26 Sep 95 18:06:03 EDT Received: from gateway.sctc.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA13283; Tue, 26 Sep 95 18:05:25 EDT Received: from sccmailhost.sctc.com (sccmailhost.sctc.com [192.55.214.100]) by gateway.sctc.com (8.6.10/8.6.9) with SMTP id RAA21571; Tue, 26 Sep 1995 17:08:03 -0500 Received: from sccmailhost.sctc.com by sccmailhost.sctc.com id 097260000; 26 Sep 95 18:05 CDT Received: from sctc.com by sccmailhost.sctc.com id 245440000; 26 Sep 95 18:05 CDT Received: from dagobah.sctc.com (dagobah.sctc.com [172.17.192.121]) by spirit.sctc.com (8.6.12/8.6.10) with ESMTP id RAA20206; Tue, 26 Sep 1995 17:04:43 -0500 Received: (from koster@localhost) by dagobah.sctc.com (8.6.12/8.6.9) id RAA05711; Tue, 26 Sep 1995 17:04:42 -0500 From: Kirby Koster Message-Id: <199509262204.RAA05711@dagobah.sctc.com> Subject: Re: CVS setup questions: one on tags (sort of), another on branches To: Jo Wahle Date: Tue, 26 Sep 1995 17:04:41 -0500 (CDT) Cc: garyo@avs.com, info-cvs@prep.ai.mit.edu In-Reply-To: from "Jo Wahle" at Sep 26, 95 02:54:50 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3897 Status: OR -*- As spoken by Jo Wahle -*- > > On Tue, 26 Sep 1995, Gary Oberbrunner wrote: > > > > > 1: you can build any version of the product just by knowing the > > version number of Files.rel that it came from (if it was built that > > way rather than just from the head). This is like knowing the tag > > name, but you can always get the last "stable" version by getting the > > head version of Files.rel. > > > > 2: it provides a convenient label for each build of the product > > ("4.287"), not just actual releases (which would be tagged under CVS). > > > > Who says you can't tag each build? Tags don't take much space. We're > tagging each build here. We're tagging releases too. If you want "a > convenient label," why not use something that means something? We tag each build for development purposes, but I still feel more comfortable keeping a "Files.rel" (we call it a Version Description Document) around also. In my opinion tags can't be fully relied on for CM purposes since any user (including myself :-) ) can change them. Of course, this only applies if you are _really_ concerned about being able to confidently rebuild previous releases. > > 3. It provides isolation from the development branch (whatever's > > checked in on the head) to the release branch (what's in Files.rel), > > since it's not necessary that every change be reflected in Files.rel > > unless it's a part of the current release. In CVS, presumably this > > can be done via branches (currently we use SCCS branches when two > > people need to check out the same file -- yecch). > > > > I am currently planning to maintain this architecture under CVS, even > > though it doesn't use tags to their fullest potential. My first > > question is, is this sensible? > > Doesn't seem like it to me, from what you've described. I think you can > use tags instead of Files.rel to accomplish what you've described. The scheme you have pointed out is similar to what we use. One problem that you have to consider though is the model of CVS. When you used SCCS and two people had to branch when modifying the same file, the "buildmeister" could decide to include one or both of the fixes since they were committed individually on seperate branches. With CVS, these fixes would be automatically merged and resolved. This automatic merging can cause you alot of trouble if you want to keep a set of fixes out that go in before the set you wish to include. Of course you can always start doing diffs and merges and such but it is not always as simple as you might hope. This means that your release "branch" isn't as controllable as it might have been before and really Files.rel becomes more of a snapshot of past areas (like a tag) than a release control mechanism. If you are willing to take the risk with tags, and except that one might get corrupted down the line, then using the CVS tagging mechanism might work out better for you. > > Is there any way to maintain a history > > of where tags used to point to, which would fulfill advantage #1? > > Tags are their own history. "Freeze" tags (as opposed to "branch" tags) > always point to where they used to point to, unless _you_ explicitly move > them. Or anybody else. > > (Yes, I know I could just use a different unique tag each time, but > > this is space and time consuming, and maybe error prone(?)). > > Space consuming? Not really. Time consuming? No more so than updating > Files.rel every time. Error prone? Again, no more so than editing > Files.rel every time. Jo makes a good point that updating Files.rel by hand would probably be worse than taking the risk that a tag is going to disappear or change on you. We have tools that automate this process (that existed before cvs) so it is pretty efficient for us. Hope this made some kind of sense ... Good luck :-) Kirby --- Kirby Koster, koster@sctc.com From info-cvs-ownrr@prep.ai.mit.edu Thu Sep 28 18:58:17 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id SAA29793 for ; Thu, 28 Sep 1995 18:57:55 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id PAA00941; Thu, 28 Sep 1995 15:30:22 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06628; Thu, 28 Sep 95 15:30:19 EDT Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06619; Thu, 28 Sep 95 15:30:08 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA28220; Thu, 28 Sep 1995 15:30:04 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA25311; Thu, 28 Sep 95 15:29:58 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id PAA11631; Thu, 28 Sep 1995 15:29:57 -0400 Date: Thu, 28 Sep 1995 15:29:57 -0400 Message-Id: <199509281929.PAA11631@kayak.odi.com> To: jim@pfm-tun-wells.ccmail.compuserve.com Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <950928101605_702420.204300_BHD46-53@CompuServe.COM> (jim@pfm-tun-wells.ccmail.compuserve.com) Subject: Re: Configuring the CVS programs without re-making CVS Reply-To: dgg@odi.com Status: RO > Our problem is that we want use diff and diff3 with the -a option (for use > with binary files) but re-making the programs isn't a sensible option here > (long story...). > > I think I've seen something on the mailing list about this but I've lost > the messages, and I can't find anything in FAQ, does anyone have any > suggestions? This isn't really a CVS question. It is more of a Unix configuration question. You have five options I can think of quickly: - Rebuild CVS. - Fix CVS to find "diff" and "diff3" via an environment variable. Then rebuild CVS. - Change "diff" and "diff3" to be a script (or symlink to a script) that calls the real "diff" with -a. - Put the above script into a new directory that only CVS users have in their PATH in front of whereever you normally store diff and diff3. - Patch the binary with Emacs or adb or gnused or . . . (Make sure you keep the same string length. From info-cvs-ownrr@prep.ai.mit.edu Thu Sep 28 19:07:50 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA30327 for ; Thu, 28 Sep 1995 19:07:49 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id PAA00979; Thu, 28 Sep 1995 15:34:18 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06760; Thu, 28 Sep 95 15:34:17 EDT Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06679; Thu, 28 Sep 95 15:32:45 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA28228; Thu, 28 Sep 1995 15:31:25 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA25441; Thu, 28 Sep 95 15:31:24 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id PAA11646; Thu, 28 Sep 1995 15:31:23 -0400 Date: Thu, 28 Sep 1995 15:31:23 -0400 Message-Id: <199509281931.PAA11646@kayak.odi.com> To: dtayl@anubis.nii.ncb.gov.sg Cc: info-cvs@prep.ai.mit.edu In-Reply-To: Subject: Re: cvs release in 1.5 Reply-To: dgg@odi.com Status: RO > The FAQ distributed with CVS 1.5 states the following: > > ========== > 2B.3 How do I get rid of the directory that "checkout" created? > > Change your directory to be the same as when you executed the > "checkout" command that created . > > If you want to get rid of the CVS control information, but leave > the files and directories, type: > > cvs release > =========== > > This doesn't work for me. The behaviour is no different than 1.4. That is, > "cvs release " does not change the tree in any way. > Changes to 1.5 release.c include client code, modified type declaration, > and removal of 1.2 support, but nothing else. > > So is the FAQ in error or am I missing something? > > dtayl The FAQ naturally trails the code when the code changes quickly. The FAQ is not documentation -- it is an attempt to answer questions about the software. "release" has been broken for a long time. After I fool around with a fixed version, I'll change the FAQ to match the code. From info-cvs-ownrr@prep.ai.mit.edu Tue Sep 26 15:01:40 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id PAA17997 for ; Tue, 26 Sep 1995 15:01:38 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id KAA10885; Tue, 26 Sep 1995 10:59:10 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA14392; Tue, 26 Sep 95 10:59:03 EDT Received: from caffeine.avs.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA14328; Tue, 26 Sep 95 10:58:22 EDT Received: from darkstar.avs.com by caffeine.avs.com (5.x/SMI-SVR4) id AA13485; Tue, 26 Sep 1995 10:56:30 -0400 Received: by darkstar.avs.com (5.x/SMI-SVR4) id AA02094; Tue, 26 Sep 1995 10:55:26 -0400 Date: Tue, 26 Sep 1995 10:55:26 -0400 Message-Id: <9509261455.AA02094@darkstar.avs.com> From: Gary Oberbrunner To: info-cvs@prep.ai.mit.edu Subject: CVS setup questions: one on tags (sort of), another on branches Status: RO Hi CVS folks. I'm about to set up CVS here; we're currently using SCCS. I've been a CVS user before, but never the CVS admin. I'd like to describe parts of my setup to you and see if you have any helpful hints. Currently (under SCCS), we have a special file called Files.rel (under version control itself) which contains a line for each other file under sccs, with that file's name and a version number. Files.rel is used like a CVS tag, in the sense that given a version of Files.rel you can rebuild the world as of that point. However, in a way it's better than a tag, since if you "move the tag" by updating Files.rel and committing it, you still preserve the old "tag location" because Files.rel is version controlled. Of course it's harder to update. During development, developers check their stuff in and then send mail to an administrator, who enters the version numbers of changed files manually into Files.rel. The admin may reject the change if it's destabilizing or inadequately tested. A release is then made from a particular version of Files.rel. This setup has three advantages: 1: you can build any version of the product just by knowing the version number of Files.rel that it came from (if it was built that way rather than just from the head). This is like knowing the tag name, but you can always get the last "stable" version by getting the head version of Files.rel. 2: it provides a convenient label for each build of the product ("4.287"), not just actual releases (which would be tagged under CVS). 3. It provides isolation from the development branch (whatever's checked in on the head) to the release branch (what's in Files.rel), since it's not necessary that every change be reflected in Files.rel unless it's a part of the current release. In CVS, presumably this can be done via branches (currently we use SCCS branches when two people need to check out the same file -- yecch). I am currently planning to maintain this architecture under CVS, even though it doesn't use tags to their fullest potential. My first question is, is this sensible? Is there any way to maintain a history of where tags used to point to, which would fulfill advantage #1? (Yes, I know I could just use a different unique tag each time, but this is space and time consuming, and maybe error prone(?)). My second question is how people generally set up branches for multiple releases and patches. Let's say that version 2.0 is just about to go out (it's nearly frozen), and some folks are working on 2.1 which is a bug fix release only, and most folks are working on 3.0, which will have lots of new features. It seems to me that if you have a branch for each of those releases plus the trunk, you end up double-committing (or even triple-) if (for example) you're working on 3.0, and find and fix a critical bug which should go into 2.0 and 2.1. Similarly if you're working on 2.1, you may or may not want your fix to go into 3.0, so you may double-commit. Is this how you normally work, or is there some better setup? Thanks for listening, and thanks for any advice you may have for me. -- Gary Oberbrunner garyo@avs.com Advanced Visual Systems, Inc. http://www.avs.com/~garyo 300 Fifth Avenue (617)890-8192 x2133 TEL Waltham, MA 02154 (617)890-2887 FAX From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 4 09:39:11 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id JAA12154 for ; Wed, 4 Oct 1995 09:39:09 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id HAA13059; Wed, 4 Oct 1995 07:25:33 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA10134; Wed, 4 Oct 95 07:25:29 EDT Received: from dayton.saic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA10125; Wed, 4 Oct 95 07:25:16 EDT Received: from llcoolj.dayton.saic.com.noname (llcoolj.dayton.SAIC.COM [139.121.26.6]) by dayton.saic.com (8.6.9/8.6.5) with SMTP id HAA01151; Wed, 4 Oct 1995 07:25:08 -0400 Received: by llcoolj.dayton.saic.com.noname (4.1/SMI-4.1) id AA29735; Wed, 4 Oct 95 07:27:10 EDT Date: Wed, 4 Oct 95 07:27:10 EDT Message-Id: <9510041127.AA29735@llcoolj.dayton.saic.com.noname> From: Mike Sutton To: ALEX@dspse.com, info-cvs@prep.ai.mit.edu In-Reply-To: <199510032104.OAA29620@netcomsv.netcom.com> (ALEX@dspse.com) Subject: Re: Creating directories on a branch Status: RO >>>>> "Alex" == Alex Urquizo writes: Alex> Is there any way to GET just the stuff that is supposed to be on Alex> the Main Branch and not (empty) directories that I created on a Alex> separate branch? cvs -P co foo where the -P will prune the empty directories. Mike Sutton | Life is hard when you're SAIC | home-pageless. Beavercreek, OH | Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's From info-cvs-ownrr@prep.ai.mit.edu Tue Oct 10 19:12:18 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA27054 for ; Tue, 10 Oct 1995 19:12:17 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id QAA23446; Tue, 10 Oct 1995 16:34:26 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA01072; Tue, 10 Oct 95 16:34:23 EDT Received: from atlantic.merl.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA01041; Tue, 10 Oct 95 16:34:11 EDT Received: by atlantic.merl.com (1.37.109.16/16.2) id AA248537240; Tue, 10 Oct 1995 16:34:00 -0400 Received: from pacific.ca.merl.com(140.237.10.103) by atlantic.merl.com via smap (V1.3) id sma024848; Tue Oct 10 16:33:29 1995 Received: from rdc01.ca.merl.com by ca.merl.com (4.1/SMI-RD-4.1) id AA27347; Tue, 10 Oct 95 13:33:25 PDT Organization: Mitsubishi Electric Research Laboratories, Inc. Sunnyvale R&D Lab Sunnyvale, California, USA Received: by rdc01.ca.merl.com (4.1/SMI-4.0) id AA01728; Tue, 10 Oct 95 13:33:24 PDT Date: Tue, 10 Oct 95 13:33:24 PDT From: ajain@ca.merl.com (Anurag Jain) Message-Id: <9510102033.AA01728@rdc01.ca.merl.com> To: Kai.Quale@usit.uio.no Subject: Re: cvsinit problem on HP-UX ver. 9 Cc: info-cvs@prep.ai.mit.edu Status: RO Hi, loginfo is the file in ${CVSROOT}/CVSROOT such as /projects/src/CVSROOT/loginfo where /projects/src is ${CVSROOT} and loginfo is under /projects/src/CVSROOT. logfile is created at the time of CVSROOT installation by cvsinit executable (script) file. In other words, when CVS is compiled and available to use, one sets CVSROOT environment variable and execute "cvsinit" to automatically produce loginfo and many other admin. files in ${CVSROOT}/CVSROOT. (Of course, you must create a CVSROOT sub-directory in your ${CVSROOT} before admin. related files (like loginfo) can be automatically produced in there. Hope this helps. Anu >I get the following errors during cvsinit: >The ...../cvsroot/CVSROOT/loginfo file does not exist. >Making a simple one for you... >cat: contrib/log.pl: No such file or directory >cp: examples/loginfo: No such file or directory >ci: loginfo: No such file or directory >Does anyone know what the problem can be ? >I run CVS 1.5 and the current version of RCS fetched from the FSF site, >on a HP-UX PA 9. >Thanks in advance, >kai From info-cvs-ownrr@prep.ai.mit.edu Tue Oct 10 19:17:52 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA07645 for ; Tue, 10 Oct 1995 19:17:52 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id QAA23438; Tue, 10 Oct 1995 16:29:26 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA00854; Tue, 10 Oct 95 16:29:22 EDT Received: from dayton.saic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA00834; Tue, 10 Oct 95 16:29:06 EDT Received: from llcoolj.dayton.saic.com.noname (llcoolj.dayton.SAIC.COM [139.121.26.6]) by dayton.saic.com (8.6.9/8.6.5) with SMTP id QAA13473; Tue, 10 Oct 1995 16:28:52 -0400 Received: by llcoolj.dayton.saic.com.noname (4.1/SMI-4.1) id AA15764; Tue, 10 Oct 95 16:31:01 EDT Date: Tue, 10 Oct 95 16:31:01 EDT Message-Id: <9510102031.AA15764@llcoolj.dayton.saic.com.noname> From: Mike Sutton To: Kai.Quale@usit.uio.no, info-cvs@prep.ai.mit.edu In-Reply-To: (Kai.Quale@usit.uio.no) Subject: Re: cvsinit problem on HP-UX ver. 9 Status: RO >>>>> "Kai" == Kai Quale writes: >The ...../cvsroot/CVSROOT/loginfo file does not exist. >Making a simple one for you... >cat: contrib/log.pl: No such file or directory >cp: examples/loginfo: No such file or directory >ci: loginfo: No such file or directory Looks like a relative path problem. Try running cvsinit from the directory where cvs was unloaded. contrib and examples are subdirectories. Mike Sutton | Life is hard when you're SAIC | home-pageless. Beavercreek, OH | Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's From info-cvs-ownrr@prep.ai.mit.edu Tue Oct 10 19:16:16 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA17200 for ; Tue, 10 Oct 1995 19:15:51 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id QAA23458; Tue, 10 Oct 1995 16:39:46 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA02004; Tue, 10 Oct 95 16:39:41 EDT Received: from uu7.psi.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA01995; Tue, 10 Oct 95 16:39:17 EDT Received: by uu7.psi.com (5.65b/4.0.940727-PSI/PSINet) via UUCP; id AA17627 for ; Tue, 10 Oct 95 16:20:34 -0400 Received: from avalon by insoft.com (4.1/InSoftMail-1.4) id AA21811; Tue, 10 Oct 95 16:19:30 EDT From: "R. Scott Youmans" Message-Id: <9510102019.AA21811@insoft.com> Received: by avalon (1.38.110.45/MailPunt-1.1) id AA043236648; Tue, 10 Oct 1995 16:24:08 -0400 Date: Tue, 10 Oct 1995 16:24:08 -0400 To: info-cvs@prep.ai.mit.edu In-Reply-To: (Kai.Quale@usit.uio.no) Subject: Re: cvsinit problem on HP-UX ver. 9 Reply-To: rsy@insoft.com Status: RO I'm running on CVS 1.5 on HPUX 9.X an HPUX 10.0 and haven't had any problems (yet). Could it be that you didn't run it from the source directory? Just a thought from a novice. >From the FAQ: >> 4B.1 What do I do first? How do I create a Repository? >> >> First, install all the programs. (See Section 4A.) >> >> Then create a Repository by executing "cvsinit", which works only >> from within the head of the CVS source directory. (It needs files >> from the distribution to work.) ...scotT ====================================================================== R. Scott Youmans Phone : (717) 730-9501 InSoft, Inc. FAX : (717) 730-9504 Mechanicsburg PA 17055 rsy@insoft.com http://www.insoft.com ====================================================================== From info-cvs-ownrr@prep.ai.mit.edu Tue Oct 10 16:25:42 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id QAA24703 for ; Tue, 10 Oct 1995 16:25:41 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id NAA23268; Tue, 10 Oct 1995 13:01:07 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA16482; Tue, 10 Oct 95 13:01:04 EDT Received: from harvey.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA16469; Tue, 10 Oct 95 13:00:54 EDT Received: (from kingdon@localhost) by harvey.cyclic.com (8.6.9/8.6.9) id NAA26488; Tue, 10 Oct 1995 13:07:29 -0400 Date: Tue, 10 Oct 1995 13:07:29 -0400 From: Jim Kingdon Message-Id: <199510101707.NAA26488@harvey.cyclic.com> To: webb@ctiole.ctio.noao.edu Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9510101655.AA02398@ctiole> (webb@ctiole.ctio.noao.edu) Subject: Re: Renaming (current status?) Status: RO > Under 1.4, when I renamed a file I had to (cvs) remove the old > name and add the new name, losing any history in the progress. The history is not lost. Commands like "cvs log foo" "cvs diff -r 1.2 -r 1.3 foo", where foo is the old name, mostly work (I think there have been some bugfixes in this area but I don't remember details; see the ChangeLogs). > Thanks -- there doesn't seem to be any documentation on the newer > versions. See the NEWS file in the 1.5 and 1.6 releases for lists of new features. From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 11 16:04:48 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id QAA17920 for ; Wed, 11 Oct 1995 16:04:43 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id MAA25113; Wed, 11 Oct 1995 12:43:53 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA03452; Wed, 11 Oct 95 12:43:50 EDT Received: from goggins.uio.no by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA03437; Wed, 11 Oct 95 12:43:36 EDT Received: from ulrik.uio.no by goggins.uio.no with local-SMTP (PP) id <07048-0@goggins.uio.no>; Wed, 11 Oct 1995 17:43:23 +0100 Received: from [129.240.200.229] by bilbo.uio.no ; Wed, 11 Oct 1995 17:43:20 +0100 X-Sender: kai@bilbo.uio.no Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Oct 1995 17:59:18 +0100 To: info-cvs@prep.ai.mit.edu From: Kai.Quale@usit.uio.no (Kai Quale) Subject: Re: cvsinit problem on HP-UX ver. 9 Status: RO At 16:24 10-10-95, R. Scott Youmans wrote: >I'm running on CVS 1.5 on HPUX 9.X an HPUX 10.0 and haven't had any >problems (yet). Could it be that you didn't run it from the source >directory? Just a thought from a novice. > >>From the FAQ: >>> 4B.1 What do I do first? How do I create a Repository? >>> >>> First, install all the programs. (See Section 4A.) >>> >>> Then create a Repository by executing "cvsinit", which works only >>> from within the head of the CVS source directory. (It needs files >>> from the distribution to work.) *BLUSH* I didn't see that - never entered my mind one might have to run it from a special directory. Now it works - thanks ! kai From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 11 20:32:52 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id UAA25564 for ; Wed, 11 Oct 1995 20:32:46 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id RAA25417; Wed, 11 Oct 1995 17:40:03 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA22785; Wed, 11 Oct 95 17:40:00 EDT Received: from alcor.twinsun.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA22772; Wed, 11 Oct 95 17:39:50 EDT Received: from twinsun.com (twinsun.twinsun.com [192.54.239.2]) by alcor.twinsun.com (8.6.12/8.6.5) with SMTP id OAA04257; Wed, 11 Oct 1995 14:28:53 -0700 Received: from light.twinsun.com by twinsun.com (4.1/SMI-4.1) id AA15680; Wed, 11 Oct 95 14:38:48 PDT Received: by light.twinsun.com (SMI-8.6/SMI-SVR4) id OAA13485; Wed, 11 Oct 1995 14:38:45 -0700 Date: Wed, 11 Oct 1995 14:38:45 -0700 Message-Id: <199510112138.OAA13485@light.twinsun.com> From: Paul Eggert To: barrow@ingenia.fr Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9510111753.AA16386@oslo.ingenia.fr> (barrow@ingenia.fr) Subject: Re: year 2000 in CVS Status: RO Date: Wed, 11 Oct 1995 17:53:26 +0200 From: barrow@ingenia.fr (Rupert BARROW) Please could you confirm that CVS and RCS will correctly handle date problems when passing into the next century (year 2000) ? I tested RCS 5.5 a while ago by running it in the next century. I haven't tested CVS, though. In case you're worried about the dates in RCS files, RCS's strategy is to store dates from 1900 through 1999 without the leading `19', but to store other dates in full. This hack is for backwards compatibility with older versions of RCS (i.e. versions before RCS 5.5, which was released in 1990). Older versions of RCS assume that dates are between 1900 and 1999, and in general these older versions won't work correctly after 1999-12-31. From sre@jrcase.mq.edu.au Wed Oct 11 21:03:28 1995 Received: from dishwasher1.mpce.mq.edu.au (dishwasher1.mpce.mq.edu.au [137.111.216.16]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id VAA21706 for ; Wed, 11 Oct 1995 21:03:21 -0400 Received: from (localhost.mpce.mq.edu.au [127.0.0.1]) by dishwasher1.mpce.mq.edu.au (8.6.9/8.6.9) with SMTP id KAA05568; Thu, 12 Oct 1995 10:57:03 +1000 Date: Thu, 12 Oct 1995 10:57:03 +1000 Message-Id: <199510112036.OAA04159@anchor.cs.colorado.edu> Errors-To: didar@mpce.mq.edu.au Reply-To: sre@jrcase.mq.edu.au Originator: sre@jrcase.mq.edu.au Sender: sre@jrcase.mq.edu.au Precedence: bulk From: Regina Gonzales To: Multiple recipients of list Subject: [SRE:427] Taxonomy of Requirements Problem Space X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Software Requirements for Engineering Mailing List Status: RO I have been reading with interest the commentary about customers as well as the discussions regarding ontologies. I was wondering if there exists a taxonomy of the requirements engineering problem domain. I have a background in embedded systems, which then expanded to included more software related to user interface and such. I also have had the opportunity to do requirements engineering in the DOE Nuclear Weapon Telemetry domain and a more hostile competative domain of high-tech commercial systems. I get the feeling that we are looking at this enormous elephant and characterizing it based on our viewpoint. I would like to see, maybe someone has a reference, a taxonomy of problem domains. I will try to start and so Jan can get in on the discussion I will use my rather unpracticed PROLOG skills. requirementsproblem(X) :- commercial(X) requirementsproblem(X) :- military(X) commercial(X) :- large(X) commercial(X) :- small(X) military (X) :- legacy(X) military (X) :- new(X) large(X) :- diverse(X), new(X) ;diverse technically small(X) :- homogeneous(X), understood(X) ;homogeneous technically ect. I will give it more thought, this was just a primer to see if anyone else is thinking about requirements this way. I must admit with e-mail that Prolog is not a bad way to get a structure across. Regina M. Gonzales University of Colorado, Computer Science, SERL From lechner Wed Oct 11 20:49:11 1995 Received: (from lechner@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id UAA28565 for lechner; Wed, 11 Oct 1995 20:49:10 -0400 From: Bob Lechner Message-Id: <199510120049.UAA28565@jupiter.cs.uml.edu> Subject: How to rename files handled by CVS without losing history To: lechner Date: Wed, 11 Oct 1995 20:49:10 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1697 Status: RO Forwarded message: >From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 11 17:59:04 1995 Date: Wed, 11 Oct 1995 14:11:10 -0400 From: Jim Kingdon Message-Id: <199510111811.OAA28598@harvey.cyclic.com> To: barrow@ingenia.fr Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <9510111753.AA16386@oslo.ingenia.fr> (barrow@ingenia.fr) Subject: Re: year 2000 in CVS > When will one be able to rename files handled by CVS without losing > history traceability ? Enclosed is the section of the 1.6 manual on the subject. Basically, you never have lost the history when you rename a file, although death support and bugfixes have made this work better in recent versions. > When will a GUI be available for CVS ? Check out tkCVS (http://www.winternet.com/~zoo/cvs has instructions for how to find it). ------------------------------------------------------------ @node Outside @section The Normal way to Rename The normal way to move a file is to copy @var{old} to @var{new}, and then issue the normal @sc{cvs} commands to remove @var{old} from the repository, and add @var{new} to it. (Both @var{old} and @var{new} could contain relative paths, for example @file{foo/bar.c}). @example $ mv @var{old} @var{new} $ cvs remove @var{old} $ cvs add @var{new} $ cvs commit -m "Renamed @var{old} to @var{new}" @var{old} @var{new} @end example This is the simplest way to move a file, it is not error-prone, and it preserves the history of what was done. Note that to access the history of the file you must specify the old or the new name, depending on what portion of the history you are accessing. For example, @code{cvs log @var{old}} will give the log up until the time of the rename. From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 11 06:33:10 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id GAA15955 for ; Wed, 11 Oct 1995 06:33:08 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id DAA24570; Wed, 11 Oct 1995 03:23:04 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA07258; Wed, 11 Oct 95 03:23:01 EDT Received: from snex11.senet.abb.se by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA07235; Wed, 11 Oct 95 03:22:40 EDT Received: from localhost by snex11.senet.abb.se; (5.65/1.1.8.2/03Oct94-0154PM) id AA24478; Wed, 11 Oct 1995 08:26:57 +0100 Message-Id: <9510110726.AA24478@snex11.senet.abb.se> To: info-cvs@prep.ai.mit.edu Subject: How do I inhibit the commitlog Date: Wed, 11 Oct 95 08:26:56 +0100 From: gtornblo@senet.abb.se X-Mts: smtp Status: RO Hi When you create a new CVS library with the standard cvsinit file you will get a loginfo file with a DEFAULT action to start a script log.pl that will create a log file "commitlog" and write a little history into it at each commit. Last time I built our s7w into a CVS library the commit log file grew to 20 megabyte. Question: can I inhibit the activation of log.pl by just removing the loginfo file (or the DEFAULT line from the loginfo file) ? Thanks. Gunnar From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 11 11:56:02 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id LAA04895 for ; Wed, 11 Oct 1995 11:56:01 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id HAA24898; Wed, 11 Oct 1995 07:38:05 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA12950; Wed, 11 Oct 95 07:38:01 EDT Received: from condor.CC.UMontreal.CA by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA12940; Wed, 11 Oct 95 07:37:47 EDT Received: from crt0.crt.umontreal.ca (crt0.CRT.UMontreal.CA [132.204.100.27]) by condor.CC.UMontreal.CA with SMTP id HAA14412 (8.6.11/IDA-1.6 for ); Wed, 11 Oct 1995 07:36:28 -0400 Received: from markov.crt.umontreal.ca by crt0.crt.umontreal.ca (4.1/SMI-4.1) id AA18521; Wed, 11 Oct 95 07:41:13 EDT Message-Id: <9510111141.AA18521@crt0.crt.umontreal.ca> Received: by markov.crt.umontreal.ca (1.37.109.4/16.2) id AA28378; Wed, 11 Oct 95 07:40:58 -0400 Date: Wed, 11 Oct 95 07:40:58 -0400 From: danielv@crt.umontreal.ca To: info-cvs@prep.ai.mit.edu Subject: re: How do I inhibit the commitlog In-Reply-To: <9510110726.AA24478@snex11.senet.abb.se> References: <9510110726.AA24478@snex11.senet.abb.se> Status: RO gtornblo@senet.abb.se writes: > When you create a new CVS library with the standard cvsinit file you will > get a loginfo file with a DEFAULT action to start a script log.pl that will > create a log file "commitlog" and write a little history into it at each > commit. > > Question: can I inhibit the activation of log.pl by just removing the > loginfo file (or the DEFAULT line from the loginfo file) ? If you are not using the file log.pl, you may just comment out the DEFAULT line in the loginfo file. If you are using it, you may just edit the perl script log.pl to not open and write to this file. This is what we have done here, along with some other customizations of log.pl. --Daniel From info-cvs-ownrr@prep.ai.mit.edu Thu Oct 12 19:08:12 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA31054 for ; Thu, 12 Oct 1995 19:08:11 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id PAA27226; Thu, 12 Oct 1995 15:27:44 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA29302; Thu, 12 Oct 95 15:27:42 EDT Received: from ns.onet.on.ca by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA29290; Thu, 12 Oct 95 15:27:29 EDT Received: from sqarc.sq.com ([192.31.6.128]) by ns.onet.on.ca with SMTP id <4856>; Thu, 12 Oct 1995 15:26:45 -0400 Received: from saturn.carolian.com by sqarc.sq.com with smtp (Smail3.1.29.1 #4) id m0t3TGs-000CatC; Thu, 12 Oct 95 15:26 EDT Received: from steve.carolian.com by saturn.carolian.com with smtp (Smail3.1.29.1 #6) id m0t3TGd-000WzaC; Thu, 12 Oct 95 15:26 EDT Message-Id: From: willer@carolian.com (Steve Willer) To: info-cvs@prep.ai.mit.edu Subject: Re: Simultaneous Unix and NT development. Date: Thu, 12 Oct 1995 19:28:53 GMT Organization: Carolian Systems, Toronto ON References: <199510121418.JAA08860@europa.futuresource.com> X-Mailer: Forte Agent .99b.112 Status: RO On Thu, 12 Oct 1995 09:18:09 -0500, you wrote: >Hi! Has anybody tried using a single CVS repository for both Unix and NT >developers? The problem, of course, is that DOS files have the extra >carriage returns, so whichever file format is chosen for the repository >will look odd to one set of developers unless something clever is done. It is my understanding that Cyclic's NT CVS opens the files in text mode, so it is stored on the Unix machine in Unix format DOS files. Of course, this means that it scrambles binaries, but someone posted a patch (yesterday?) to CVS that allows you to specify which files are binary. >I can't find any material addressing this problem in the FAQ or man pages, >and I can't find the archive for this mail-list nor contact its keeper a.k.a >berliner.sun.com. Any ideas? Doesn't the Cyclic web server have an archive? Or is that a different mailing list? From info-cvs-ownrr@prep.ai.mit.edu Thu Oct 12 19:08:12 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA31054 for ; Thu, 12 Oct 1995 19:08:11 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id PAA27226; Thu, 12 Oct 1995 15:27:44 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA29302; Thu, 12 Oct 95 15:27:42 EDT Received: from ns.onet.on.ca by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA29290; Thu, 12 Oct 95 15:27:29 EDT Received: from sqarc.sq.com ([192.31.6.128]) by ns.onet.on.ca with SMTP id <4856>; Thu, 12 Oct 1995 15:26:45 -0400 Received: from saturn.carolian.com by sqarc.sq.com with smtp (Smail3.1.29.1 #4) id m0t3TGs-000CatC; Thu, 12 Oct 95 15:26 EDT Received: from steve.carolian.com by saturn.carolian.com with smtp (Smail3.1.29.1 #6) id m0t3TGd-000WzaC; Thu, 12 Oct 95 15:26 EDT Message-Id: From: willer@carolian.com (Steve Willer) To: info-cvs@prep.ai.mit.edu Subject: Re: Simultaneous Unix and NT development. Date: Thu, 12 Oct 1995 19:28:53 GMT Organization: Carolian Systems, Toronto ON References: <199510121418.JAA08860@europa.futuresource.com> X-Mailer: Forte Agent .99b.112 Status: RO On Thu, 12 Oct 1995 09:18:09 -0500, you wrote: >Hi! Has anybody tried using a single CVS repository for both Unix and NT >developers? The problem, of course, is that DOS files have the extra >carriage returns, so whichever file format is chosen for the repository >will look odd to one set of developers unless something clever is done. It is my understanding that Cyclic's NT CVS opens the files in text mode, so it is stored on the Unix machine in Unix format DOS files. Of course, this means that it scrambles binaries, but someone posted a patch (yesterday?) to CVS that allows you to specify which files are binary. >I can't find any material addressing this problem in the FAQ or man pages, >and I can't find the archive for this mail-list nor contact its keeper a.k.a >berliner.sun.com. Any ideas? Doesn't the Cyclic web server have an archive? Or is that a different mailing list? From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 11 18:20:34 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id SAA29120 for ; Wed, 11 Oct 1995 18:20:33 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id OAA25250; Wed, 11 Oct 1995 14:57:01 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA12138; Wed, 11 Oct 95 14:56:54 EDT Received: from caffeine.avs.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA12106; Wed, 11 Oct 95 14:56:24 EDT Received: from darkstar.avs.com by caffeine.avs.com (5.x/SMI-SVR4) id AA06035; Wed, 11 Oct 1995 14:54:20 -0400 Received: by darkstar.avs.com (5.x/SMI-SVR4) id AA27697; Wed, 11 Oct 1995 14:52:42 -0400 Date: Wed, 11 Oct 1995 14:52:42 -0400 Message-Id: <9510111852.AA27697@darkstar.avs.com> From: Gary Oberbrunner To: info-cvs@prep.ai.mit.edu Subject: Conflicts on RCS keywords during merge Status: RO We have the following standard RCS header: "@(#)$RCSfile: Makefile,v $ $Revision: 5.3 $ $AVS$ $Date: 1995/10/03 17:34:29 $" (usually prefaced by the appropriate comment leader). We have two branches of development: the dev_2_1 branch, and the main line. It seems that whenever someone merges a file from one to the other, we get a conflict on that RCS header line. I thought this wasn't supposed to happen? I am using CVS 1.5, but 1.6 seems no different. I seem to be able to use the "-ko" option to update -j to suppress the conflict, but that sets the -ko sticky option, which I certainly don't want! It seems that every file must be hand-edited to remove these conflicts; I don't remember CVS working this way in my past life! I have read the FAQ and the info document, but see no mention of how to deal with this, or even an acknowledgement that it happens. Hence I wonder if it's not something I'm doing wrong. Here's the -t (trace) output so you can see the rcsmerge options: % cvs -n -t update -j dev_2_1 foo.c -> unlink(.#foo.c.4.2) -> copy(foo.c,.#foo.c.4.2) -> chmod(foo.c,100664) -> system(/public/solaris/bin/rcsmerge -r4.1 -r4.1.2.1 /net/build/cvs/repository/express/ackit/foo.c,v) If I run rcsmerge by hand, and pass in -kk, everything is fine: % rcsmerge -kk -r4.1 -r4.1.2.1 $CVSROOT/express/ackit/foo.c,v % So perhaps my question is, why doesn't RCS_merge (or merge_file) in rcscmds.c pass -kk into rcsmerge? I see that's #ifdefed out in join_file, but I don't see it anywhere in merge_file (in update.c). thanks, -- Gary Oberbrunner garyo@avs.com Advanced Visual Systems, Inc. http://www.avs.com/~garyo 300 Fifth Avenue (617)890-8192 x2133 TEL Waltham, MA 02154 (617)890-2887 FAX From info-cvs-ownrr@prep.ai.mit.edu Mon Oct 16 18:29:17 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id SAA16681 for ; Mon, 16 Oct 1995 18:29:16 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id PAA04146; Mon, 16 Oct 1995 15:21:28 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA20068; Mon, 16 Oct 95 15:21:24 EDT Received: from dayton.saic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA20045; Mon, 16 Oct 95 15:21:08 EDT Received: from llcoolj.dayton.saic.com.noname (llcoolj.dayton.SAIC.COM [139.121.26.6]) by dayton.saic.com (8.6.9/8.6.5) with SMTP id PAA22977 for ; Mon, 16 Oct 1995 15:20:54 -0400 Received: by llcoolj.dayton.saic.com.noname (4.1/SMI-4.1) id AA06938; Mon, 16 Oct 95 15:23:10 EDT Date: Mon, 16 Oct 95 15:23:10 EDT Message-Id: <9510161923.AA06938@llcoolj.dayton.saic.com.noname> From: Mike Sutton To: info-cvs@prep.ai.mit.edu Subject: The modules -e option Status: RO I have CVS 1.6 up and running. I tested the -e option today as I made a release. I have the -e option call a script that is extracted by the cvs export command. Performed as advertised. I hereby extend kudos to the implementor(s) of the -e option. Mike Sutton | Life is hard when you're SAIC | home-pageless. Beavercreek, OH | Mike_Sutton@dayton.saic.com | These are MY opinions, not SAIC's From info-cvs-ownrr@prep.ai.mit.edu Fri Oct 13 14:37:51 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id OAA16691 for ; Fri, 13 Oct 1995 14:29:52 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id KAA28424; Fri, 13 Oct 1995 10:56:55 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA17688; Fri, 13 Oct 95 10:56:51 EDT Received: from bou.shl.com (dilbert.bou.shl.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA17678; Fri, 13 Oct 95 10:56:40 EDT Received: from whatnow by bou.shl.com (NX5.67e/NX3.0Ma) id AA16988; Fri, 13 Oct 95 08:56:29 -0600 Message-Id: <9510131456.AA16988@bou.shl.com> Received: by whatnow.bou.shl.com (NX5.67e/NX3.0X) id AA09402; Fri, 13 Oct 95 08:56:27 -0600 Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Received: by NeXT.Mailer (1.118.3) From: Vince Demarco Date: Fri, 13 Oct 95 08:56:26 -0600 To: "Stefan Monnier" Subject: Re: treatment of binary files Cc: info-cvs@prep.ai.mit.edu References: Status: RO You already have this. Check the documentation for the cvswrappers file. What you can do is this say all of the files you have then match *.tiff are binaries (TIFF images) in the cvswrappers file add the following line *.tiff -m 'COPY' the -m tells cvs not to try to merge the file only copy it into the = repository. vince Begin forwarded message: From: "Stefan Monnier" To: info-cvs@prep.ai.mit.edu Subject: Re: treatment of binary files=20 In-Reply-To: nk%ipgate.col.sw-ley.de's message of Wed, 04 Oct 1995 17:06:16 = +0100. <9510041606.AA07228@HPLEY1.col.sw-ley.de>=20 Date: Fri, 13 Oct 1995 09:23:49 +0100 nk%ipgate.col.sw-ley.de@col.sw-ley.de wrote: > So here comes my "CVS goes binary" proposal: [...] > P3) Add a new option "-b" to "cvs add" to indicate binary files. This > would make much clearer that binary files are not just a matter of > RCS keyword expansion. Internally, "-b" should be translated to > "-kb" again. (If this proposal will be accepted, replace "-kb" by > "-b" in P1). Maybe it would be useful to also have cvsbinary (a la cvsignore) that specifies files that should be automatically treated like binary files. Stefan From info-cvs-ownrr@prep.ai.mit.edu Thu Oct 12 21:21:25 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id VAA04631 for ; Thu, 12 Oct 1995 21:21:23 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id SAA27328; Thu, 12 Oct 1995 18:14:03 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA10087; Thu, 12 Oct 95 18:14:00 EDT Received: from mail.mel.aone.net.au by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA10057; Thu, 12 Oct 95 18:13:14 EDT Received: from kyoko.mpx.com.au (kyoko.mpx.com.au [203.2.75.2]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id IAA26885; Fri, 13 Oct 1995 08:13:11 +1000 Received: from cristal.mpx.com.au(really [203.2.75.8]) by kyoko.mpx.com.au via smail with smtp id for ; Fri, 13 Oct 95 08:13:09 +1000 (EST) (/\##/\ Smail3.1.30.13 #30.8 built 5-oct-95) Received: by cristal.mpx.com.au (Smail3.1.28.1 #3) id m0t3VsB-0000WFC; Fri, 13 Oct 95 08:13 EDT Received: from babel.UUCP (root@localhost) by rosebay.matra.com.au with UUCP id IAA13449 (8.6.12/IDA-1.6); Fri, 13 Oct 1995 08:12:46 +1000 Date: Fri, 13 Oct 95 08:06 EST From: del@babel.matra.com.au (Del) Subject: Re: no taginfo support on import To: Rolf.Ebert@gmrs.isar.de Cc: info-cvs@prep.ai.mit.edu Message-Id: In-Reply-To: <9510121000.AA22656@dingo.gmrs.isar.de> Status: RO >I have just discovered the taginfo facility in CVS 1.6. I'm sure it >was not in 1.3 No, I put it there, it's new in CVS 1.6. It was in the NEWS file but missed inclusion in the 1.6 release note. >This is really a long needed great feature. I always had to remember >to insert the tag in my hand drawn diagram, too. Now I have set up >a small script which copies the main data (module, date, tag) into >a small database. Yup, that's what I use it for. >As usual, when I am satisfied I want more: > > 1) On 'cvs import' the taginfo is not evaluated. Neither the > vendor branch name, nor the initial tag are passed to the > tag_logging_program. > > 2) I'd like to pass a tag description to the tag_logging_program. > The -m option seems like a natural extension. Yes, these sound both like useful features, I had been wondering how to pass TR numbers to the tag_logging_program myself, some kind of formatted -m thing would probably do that job for me. Thanks for the suggestion. I'll work on these for 1.6+ -> 1.7. Del -- -------------------------------+------------------------------------- Del | del@babel.matra.com.au -------------------------------+------------------------------------- From info-cvs-ownrr@prep.ai.mit.edu Fri Oct 13 13:28:09 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id NAA30852 for ; Fri, 13 Oct 1995 13:27:58 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id IAA28301; Fri, 13 Oct 1995 08:43:06 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA10940; Fri, 13 Oct 95 08:43:03 EDT Received: from snew99 (snew99.senet.abb.se) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA10907; Fri, 13 Oct 95 08:42:30 EDT Received: from sneh28.senet.abb.se by snew99; (5.65/1.1.8.2/03Oct94-0154PM) id AA04992; Fri, 13 Oct 1995 13:46:35 +0100 Received: from localhost by sneh28; (5.65/1.1.8.2/20Dec94-1104AM) id AA18284; Fri, 13 Oct 1995 13:46:34 +0100 Message-Id: <9510131246.AA18284@sneh28> X-Mailer: exmh version 1.5.3 12/28/94 To: info-cvs@prep.ai.mit.edu Subject: Re: treatment of binary files Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Oct 95 13:46:34 +0100 From: gtornblo@senet.abb.se X-Mts: smtp Status: RO wrote: >Maybe it would be useful to also have cvsbinary (a la cvsignore) that >specifies files that should be automatically treated like binary files. I agree, a proposal that I sent to the list in april this year dealt with this but I also suggested that binary files should be externally stored but under CVS control. A resend titled "File locking and storage of binary file" follows below (Stefans "cvsbinary" is called ".nocvd" in my proposal). Thanks Gunnar File locking and storage of binary files ----------------------------------------- Two major reasons forces us to add functionality to our CVS based s/w development environment. 1) We need to store non-ascii files (documents, bitmaps etc.) these type of files can be stored in RCS but the deltas will be big and the files may become corrupted. 2) Files that cannot be merged (non-ascii files or files where parallel would generate instead of save work). To solve this we have to setup some kind of file storage that is not RCS based but must include version control. Further on, we must make introduce locking in order to serialize work on these and some other files (but parallel develoment should always be the default). Below you will find the outlines of a possible solution. Any comment/remark is welcome. a) The CVS repository is placed under a top directory that contains both CVSTOP and a BINTOP like this: REP /\ / \ / \ BINTOP CVSTOP b) In a central position in the CVS repository ($CVSROOT/CVSROOT) we keep a file ".nocdev" (for no concurrent development). The syntax of this file -- - --- is given in the following example: # ------------------- ----------------- .doc bin cchead ascii and like .cvsignore the file can appear on each cvs directory and if it does it will override the $CVSROOT/CVSROOT version. c) If a file matches a filename pattern in the ".nocvd" file at commit/checkout the following will happen: ascii: checkout/commit with lock using the real CVS (RCS based) repository with the method described in the CVS FAQ section 3C8 point 1-4 bin: commit : ------ if file not found under BINTOP: - Create a [filename].bintop file containing a line "[filename]_1" - Store the file under BINTOP with a filename that includes version number. (NOTE! no RCS storage) e.g. BINTOP/dir/dir/[filename]_1 - commit the [filename].bintop file into the real CVS (RCS based) repository. if file found under BINTOP: - checkout and lock [filename].bintop file. Use the method described un the CVS FAQ, section 3C.8 If it cannot be checked out the reason is that someone else has locked the file as described under checkout below. If your checkout+lock is successful it was either already checked out and locked by you or it was unlocked. In both cases it is OK to continue with the commit operation. - read the BINTOP filename from [filename].bintop e.g. "[filename]_17" - increment the version number and create a new [filename].bintop file containing a line e.g. "[filename}_18" - store the file under BINTOP with a filename that includes version number.(NOTE! no RCS storage) e.g. BINTOP/dir1/dir2/[filename]_18 - commit the [filename].bintop file into the real CVS (RCS based) repository. As a side-effect this commit will also release the lock. checkout: -------- - checkout and lock the latest version of the [filename].bintop file with the method described in the CVS FAQ section 3C8 point 1-4 If it cannot be checked out the reason is that someone else has locked the file and you will have to wait until the lock is released. - read the BINTOP filename from [filename].bintop e.g. "[filename]_17" - Get the file from BINTOP to user working dir. (release handling of 'binary' files can be done by putting a release tag on the [filename].bintop file since the content of this file is pointing out a specific revision of the actual file under BINTOP. Of course we need to invent some kind of postcommit script in order to fetch the real file from BINTOP)) NOTE! For all files that does not match any filename pattern given in ".nocvd" (appr. 95 % of all our files) we will use the standard CVS commit/checkout model including branches, parallel development and merge. Does this violate the CVS model ? is there a better solution ? did I forget something important ? Send any comment that you have to me directly (gunnar.tornblom@senet.abb.se) or to the CVS list. From info-cvs-ownrr@prep.ai.mit.edu Fri Oct 13 10:17:39 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id KAA03970 for ; Fri, 13 Oct 1995 10:17:37 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id GAA28222; Fri, 13 Oct 1995 06:47:56 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06679; Fri, 13 Oct 95 06:47:52 EDT Received: from liasg9.epfl.ch by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06669; Fri, 13 Oct 95 06:47:40 EDT Received: from lia.di.epfl.ch by liasg9.epfl.ch with esmtp (Smail3.1.29.1 #28) id m0t3heG-0009f2C; Fri, 13 Oct 95 11:47 MET Message-Id: From: "Stefan Monnier" To: CVS Mailing-List Subject: cvsignore: local vs remote Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Oct 1995 11:47:30 +0100 Sender: monnier@lia.di.epfl.ch Status: RO Here is a little example with cvs-1.6 that shows that when used remotely, cvs doesn't take $CVSROOT/CVSROOT/cvsignore into account, at least for updates: ~/tmp-0> cat /users/monnier/cvsroot/CVSROOT/cvsignore *.bbl *.blg *.idx *.log *.toc *.aux *.dvi *.ilg *.ind *.*fasl tclIndex ~/tmp-0> hostname liasg9 ~/tmp-0> (setenv CVSROOT /users/monnier/cvsroot; cvs checkout -d testlocal test) cvs checkout: Updating testlocal U testlocal/hello.c ~/tmp-0> (setenv CVSROOT liasg9:/users/monnier/cvsroot; cvs checkout -d testremote test) cvs server: Updating testremote U testremote/hello.c ~/tmp-0> touch testlocal/toto.fasl ~/tmp-0> touch testremote/toto.fasl ~/tmp-0> (cd testlocal; cvs -n update) cvs update: Updating . ~/tmp-0> (cd testremote; cvs -n update) ? toto.fasl cvs server: Updating . ~/tmp-0> Strangely, "cvs import" seems to work correctly, so the bug (as far as I can see) is only a minor annoyance, but it's strange enough that it might have other implications (I think this bug might be realted to Nilesh Patel's problems when checking out a single file of a module). Stefan From info-cvs-ownrr@prep.ai.mit.edu Mon Oct 9 22:18:51 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id WAA22269 for ; Mon, 9 Oct 1995 22:18:50 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id TAA21919; Mon, 9 Oct 1995 19:50:50 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA08199; Mon, 9 Oct 95 19:50:44 EDT Received: from caffeine.avs.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA08188; Mon, 9 Oct 95 19:50:33 EDT Received: from darkstar.avs.com by caffeine.avs.com (5.x/SMI-SVR4) id AA04950; Mon, 9 Oct 1995 19:48:24 -0400 Received: by darkstar.avs.com (5.x/SMI-SVR4) id AA25065; Mon, 9 Oct 1995 19:46:52 -0400 Date: Mon, 9 Oct 1995 19:46:52 -0400 Message-Id: <9510092346.AA25065@darkstar.avs.com> From: Gary Oberbrunner To: info-cvs@prep.ai.mit.edu Subject: Multiple merges onto a branch Status: RO Herewith some stuff I've discovered, seemingly not in the doc (at least not collected in any one place): If you have a branch which you wish to work on for some time, but periodically "keep up with" what everyone else is doing, you presumably want to merge from the head onto your branch every so often. The simple way of doing this does NOT work. The simple (non-working) way is, from the branch, repeatedly doing cvs update -j HEAD to pick up whatever changes have happened on the trunk. The problem with that is that if a given line is changed and you pick up that change and then it's changed again later, that line will be flagged as a *conflict* in your working file when you next join, even though you never touched it. (OK, from CVS's point of view you *did* touch it; it doesn't know where that change in the working file came from.) The answer to this seems like it should be in the info file, or at least in the FAQ: Merging Multiple Times Onto A Branch ------------------------------------ If you intend to merge from one branch onto another and continue development on both branches (one of these is often the trunk), you must create a tag on the "merged-from" branch and use that tag as the base for any successive merges rather than the common ancestor, which is otherwise used as the default base. You might ask why CVS cannot do the succeeding merges automatically. The only reason is really that there is no record of your having done the merge, so CVS cannot tell what new common ancestor to use the next time. This is why you have to have the tag. Of course, the other way to continue development on the branch while merging in changes from the trunk is to make a new branch off the trunk at the desired merge point, then merge the changes from the old branch onto the new branch. This looks like this: branch_1 ___________________ / | / BP2 | ---o------------------o-|------- trunk BP1 \| \_____________ branch_2 To do this, you do: cvs update -r branch_2 cvs update -j BP1 -j branch_1 cvs ci -m'Merged old branch_1 with trunk changes to BP2' with whatever tagging you like at each point. This way, just like the first way, the trunk continues along with no knowledge that anything's changed. The differences are that (a) the procedure is more complex, because it involves making a new branch, and (b) the branch_1 people now have to change the branch they're working on to branch_2. The payoff is that you don't have to tag the trunk and remember where that tag was when you go to do another merge into the branch. Merging both ways (from trunk to branch and back to trunk) quickly becomes a nightmare. Don't do it if you can help it. Terminate the branch and start a new one in this case. From info-cvs-ownrr@prep.ai.mit.edu Mon Oct 9 09:26:55 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id JAA11667 for ; Mon, 9 Oct 1995 09:26:51 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id FAA21046; Mon, 9 Oct 1995 05:43:36 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA28852; Mon, 9 Oct 95 05:43:33 EDT Received: from monad.armadillo.com (livingston.armadillo.com) by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA28843; Mon, 9 Oct 95 05:43:17 EDT Received: (from zoo@localhost) by monad.armadillo.com (8.6.12/8.6.12) id EAA03865 for info-cvs@prep.ai.mit.edu; Mon, 9 Oct 1995 04:45:03 -0500 Date: Mon, 9 Oct 1995 04:45:03 -0500 From: "david d `zoo' zuhn" Message-Id: <199510090945.EAA03865@monad.armadillo.com> To: info-cvs@prep.ai.mit.edu Subject: info-cvs mini-faq (Weekly posting, last modified Mon Jul 24 1995) Status: RO This is an automatically posted mini-FAQ. The "Subject:" header will not change unless the contents of the mini-FAQ change, which I hope will be infrequently. In any case, the format of the Subject will not change. The following questions are answered in this mini-FAQ. Please check to see if your question/concern/problem is answered here before sending mail to the list at large. What is CVS? Where do I find the real full-sized FAQ? What is this mailing list for? What is the current version of CVS and where is it? What does "Too many arguments!" mean? What other sources of information are available? How do I unsubscribe to this list? If you have any questions or comments about this mini-FAQ, please direct them to me and not to the list at large. My email address is 'zoo@armadillo.com'. Please include this $Revision: 1.6 $ number with any comments 1. What is CVS? "CVS" is an acronym for the "Concurrent Versions System". CVS is a "Source Control" or "Revision Control" tool designed to keep track of source changes made by groups of developers working on the same files, allowing them to stay in sync with each other as each individual chooses. 2. Where do I find the real full-sized FAQ? By anonymous ftp to ftp://ftp.odi.com/pub/users/dgg/FAQ.gz Via the World Wide Web at http://www.winternet.com/~zoo/cvs/FAQ.txt If you're new to CVS, or haven't read it lately, please read this FAQ. Though the information in it is still nearly all relevant, David Grubbs (dgg@odi.com) is in the process of catching up on recent 1.5 (and soon 1.6) changes. Suggestions for addition/modification are welcome. 3. What is this mailing list for? This list is for discussion about installing and using CVS. Talk about work on CVS is also welcome, as are enhancements and bugfixes. Bug reports should go to bug-cvs@prep.ai.mit.edu (or use the cvsbug script in the newer CVS release). 4. What is the current version of CVS and where is it? The current officially released version is 1.5 at ftp://prep.ai.mit.edu/pub/gnu/cvs-1.5.tar.gz as well as the usual GNU archive mirror sites. 5. What does "Too many arguments!" mean? CVS 1.4a2 has a cvsinit script that incorrectly sets up the loginfo file, but only if perl is available. If you don't have perl, you won't see this message (I don't have perl installed, which is why my testing didn't catch this bug). If you do have perl, you can apply the patch at the end of this message to your 1.4a2 distribution, or make the same change to your installed loginfo file (add a -f between %s and $CVSROOT). 6. What other sources of information are available? First off, the FAQ (see #2 above). Several WWW sites have information about CVS: http://www.winternet.com/~zoo/cvs/ http://www.loria.fr/~molli/cvs-index.html 7. How do I unsubscribe to this list? Please do NOT send a message to the entire list asking to unsubscribe. You'll only succeed in sending the message to hundreds of people who can't do anything about it. Send mail to info-cvs-request@prep.ai.mit.edu, and ask to be removed. The best way would be to include the text: unsubscribe info-cvs While someday the list may be automated, it is currently handled manually, and Brian is a very busy person. So it might take a while for things to happen. Please don't get frustrated and send mail to the list as a whole. Only Brian can remove you from the list. Appendices: I. The loginfo patch for 1.4a2 *** scratch/loginfo Sun Feb 12 19:51:25 1995 --- examples/loginfo Sun Feb 12 19:51:46 1995 *************** *** 18,20 **** # in addition to the first matching regex or DEFAULT. # ! DEFAULT $CVSROOT/CVSROOT/log.pl %s $CVSROOT/CVSROOT/commitlog --- 18,20 ---- # in addition to the first matching regex or DEFAULT. # ! DEFAULT $CVSROOT/CVSROOT/log.pl %s -f $CVSROOT/CVSROOT/commitlog From info-cvs-ownrr@prep.ai.mit.edu Thu Oct 5 19:39:37 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id TAA01258 for ; Thu, 5 Oct 1995 19:39:36 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id RAA15620; Thu, 5 Oct 1995 17:51:13 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA02494; Thu, 5 Oct 95 17:51:13 EDT Received: from mineshaft.odi.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA02481; Thu, 5 Oct 95 17:51:00 EDT Received: from odi.com (mastermind.odi.com) by mineshaft.odi.com (5.65c/SMI-4.0/ODI-5) id AA21960; Thu, 5 Oct 1995 17:50:55 -0400 Received: from kayak.odi.com by odi.com (4.1/SMI-4.0/ODI-15) id AA01335; Thu, 5 Oct 95 17:50:53 EDT From: David Grubbs Received: (dgg@localhost) by kayak.odi.com (8.6.12/8.6.12) id RAA18808; Thu, 5 Oct 1995 17:50:53 -0400 Date: Thu, 5 Oct 1995 17:50:53 -0400 Message-Id: <199510052150.RAA18808@kayak.odi.com> To: ALEX@dspse.com Cc: info-cvs@prep.ai.mit.edu In-Reply-To: <199510042004.NAA13082@netcomsv.netcom.com> (ALEX@dspse.com) Subject: Re: Merging Question Reply-To: dgg@odi.com Status: RO > I have a question about merging. > There are two types of branches that confuse me. Development Branch > (Merge and Forget) and Release Branch(Permanent Branch). > > Say I have the following structure: > > Branch BR_1 +------ B.1 -------> B.2 ----+ > /|\ | > | \|/ > A ------> B ------> C ------> D --------+-----> E > (Merge Point) > > > After doing the merge (Merge and Forget), I am still able to retrieve > the revisions B.1 and B.2 with a regular ---> cvs co -r B.1/B.2 > I see that I also can do a --> cvs co -r BR_1 > and keep on working on the respective branch (In this case BR_1). > > So I guess my question is, what does the CVS FAQ mean when it says > "Its (Release Branch) purpose and the way it(Release Branch) is > MANAGED are different (than a Development Branch)" (1D.9)?.Managed by us or CVS? > Does CVS know when we are dealing with either branch or this is more like > a human concept? "Manage" means human beings, white boards, release schedules and human plans. I'll look at the phrasing, but I remember writing that. It comes from believing that all CVS users understand that RCS and CVS keep track of physical files and revisions on branches (a main branch and other branches). But how humans use those branches differ. A Development branch is managed (by your manager and his/her manager in concert with the release engineering department) differently from a Release branch. Physically (i.e. in CVS & RCS data structures), they are the same. Functionally they are different. I am convinced, and the FAQ displays it, that 75% of source control is still in the hands of humans. Tools help by speeding up the overhead (the time not thinking about the real development), by making the actions more predictable and by providing the ability to dig information out of the source tree. But the *purpose* of a particular change, the revisions containing it, the branch on which to store thos revisions and the past & future histories of each remains in the realm of human interpretation. From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 18 15:59:42 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id PAA05692 for ; Wed, 18 Oct 1995 15:59:40 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id MAA07114; Wed, 18 Oct 1995 12:34:43 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06642; Wed, 18 Oct 95 12:34:39 EDT Received: from caffeine.avs.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06627; Wed, 18 Oct 95 12:34:18 EDT Received: from darkstar.avs.com by caffeine.avs.com (5.x/SMI-SVR4) id AA20736; Wed, 18 Oct 1995 12:32:06 -0400 Received: by darkstar.avs.com (5.x/SMI-SVR4) id AA03607; Wed, 18 Oct 1995 12:30:11 -0400 Date: Wed, 18 Oct 1995 12:30:11 -0400 Message-Id: <9510181630.AA03607@darkstar.avs.com> From: Gary Oberbrunner To: info-cvs@prep.ai.mit.edu Subject: cvs update -j problems Status: RO We have noticed that in server mode, cvs update -j sometimes does not actually modify the working file, although if you use -t it seems to be running all the right commands on the server; it just never downloads the merged file to the client. See the cvslog.out trace file below for details. It seems to happen when I'm merging (say) changes between 4.1 and 4.2 into a working file which is on a branch with no members yet (so its sticky tag is 4.1.2 but there is no rev 4.1.2.1). If I create 4.1.2.1, then everything works fine; the changes between 4.1 and 4.2 are merged into the working file. I've tried this with CVS 1.5 and 1.6; both exhibit this bug. Here's a sample *complete* /tmp/cvslog.out dialog. Notice that the last message is Copy-file. The Merged (or Updated or Patched) request never comes. ======================================== Valid-requests Root Valid-responses valid-requests Repository Directory Max-dotdot Static-directory Sticky Checkin-prog Update-prog Entry Modified Lost UseUnchanged Unchanged Argument Argumentx Global_option expand-modules ci co update diff log add remove update-patches gzip-file-contents status rdiff tag rtag import admin export history release ok E RCS file: /cvs/repository/express/modules/rf/nt.mak,v E retrieving revision 4.1 E retrieving revision 4.2 E Merging differences between 4.1 and 4.2 into nt.mak Copy-file ./ /cvs/repository/express/modules/rf/nt.mak .#nt.mak.4.1 ok ======================================== I'll look into this problem, but I was hoping someone out there has a patch already. thanks, -- Gary Oberbrunner garyo@avs.com Advanced Visual Systems, Inc. http://www.avs.com/~garyo 300 Fifth Avenue (617)890-8192 x2133 TEL Waltham, MA 02154 (617)890-2887 FAX From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 18 13:58:03 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id NAA27773 for ; Wed, 18 Oct 1995 13:58:03 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id KAA07046; Wed, 18 Oct 1995 10:25:59 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA28158; Wed, 18 Oct 95 10:25:55 EDT Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA28145; Wed, 18 Oct 95 10:25:43 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id JAA19903; Wed, 18 Oct 1995 09:25:35 -0500 Date: Wed, 18 Oct 1995 09:25:35 -0500 From: Jim Blandy Message-Id: <199510181425.JAA19903@totoro.cyclic.com> To: preilly@shr.dec.com Cc: info-cvs@prep.ai.mit.edu Subject: Win-nt site In-Reply-To: <9510141036.AA25365@osfsrv.shr.dec.com> References: <9510141036.AA25365@osfsrv.shr.dec.com> Amphibian: newt Status: RO >There appears to be no windows-nt directory in ftp.cyclic.com:/pub/cvs. That is correct; all windows NT stuff has been integrated into the main release as of 1.6. Where did you find a reference to the now-deleted windows nt directory? From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 18 14:12:55 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id OAA30998 for ; Wed, 18 Oct 1995 14:12:54 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id KAA07040; Wed, 18 Oct 1995 10:24:58 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA28119; Wed, 18 Oct 95 10:24:55 EDT Received: from totoro.cyclic.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA28100; Wed, 18 Oct 95 10:24:41 EDT Received: (from jimb@localhost) by totoro.cyclic.com (8.6.9/8.6.9) id JAA19895; Wed, 18 Oct 1995 09:24:04 -0500 Date: Wed, 18 Oct 1995 09:24:04 -0500 From: Jim Blandy Message-Id: <199510181424.JAA19895@totoro.cyclic.com> To: del@babel.matra.com.au (Del) Cc: info-cvs@prep.ai.mit.edu Subject: CVS and OS/2 In-Reply-To: References: Gnu-Emacs: helpful to humans, harmless to dogs! Status: RO >I know that there was an OS/2 release of CVS some time >back (CVS 1.3 from the FAQ). Has anyone attempted to >get the current release of CVS up and running on OS/2? >With what success? I will have a port ready by the end of Novbember. From info-cvs-ownrr@prep.ai.mit.edu Thu Oct 5 17:03:08 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id RAA18893 for ; Thu, 5 Oct 1995 17:03:03 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id OAA15494; Thu, 5 Oct 1995 14:34:54 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA17297; Thu, 5 Oct 95 14:34:51 EDT Received: from gateway.sctc.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA17288; Thu, 5 Oct 95 14:34:35 EDT Received: from sccmailhost.sctc.com (sccmailhost.sctc.com [192.55.214.100]) by gateway.sctc.com (8.6.10/8.6.9) with SMTP id NAA04392; Thu, 5 Oct 1995 13:38:13 -0500 Received: from sccmailhost.sctc.com by sccmailhost.sctc.com id 039750000; 5 Oct 95 14:34 CDT Received: from sctc.com by sccmailhost.sctc.com id 155170000; 5 Oct 95 14:34 CDT Received: from dagobah.sctc.com (dagobah.sctc.com [172.17.192.121]) by spirit.sctc.com (8.6.12/8.6.10) with ESMTP id NAA12930; Thu, 5 Oct 1995 13:34:15 -0500 Received: (from koster@localhost) by dagobah.sctc.com (8.6.12/8.6.9) id NAA08079; Thu, 5 Oct 1995 13:34:14 -0500 From: Kirby Koster Message-Id: <199510051834.NAA08079@dagobah.sctc.com> Subject: Re: branch/merge problem To: "Daniel R. Arnold" Date: Thu, 5 Oct 1995 13:34:13 -0500 (CDT) Cc: info-cvs@prep.ai.mit.edu, dan@hilco.com In-Reply-To: <9510051630.AA09528@life.ai.mit.edu> from "Daniel R. Arnold" at Oct 5, 95 11:30:43 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 550 Status: RO -*- As spoken by Daniel R. Arnold -*- > > This is the problem that I have. I am having difficulty updating from a > branch to a new release of a product. If new files exist in the new > release that don't exist in the branch then the new files don't get merged > into the branch. They do get merged in if I update from the main line. > > Where have I gone wrong? Or is there a bug? Bug. Merging of new files between branches is broken. As you point out though merging to the main line does work. Kirby --- Kirby Koster, koster@sctc.com From gnu@prep.ai.mit.edu Wed Oct 18 22:47:03 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id WAA01282; Wed, 18 Oct 1995 22:46:54 -0400 Received: by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) id WAA08103; Wed, 18 Oct 1995 22:44:27 -0400 Date: Wed, 18 Oct 1995 22:44:27 -0400 From: GNU Mailing List Maintenance Message-Id: <199510190244.WAA08103@gnu-life.ai.mit.edu> To: lechner@cs.uml.edu CC: lechner@jupiter.cs.uml.edu, lechner@cs.uml.edu (Bob Lechner) In-reply-to: <199510170742.DAA31900@jupiter.cs.uml.edu> "lechner@cs.uml.edu" Reply-To: gnu@prep.ai.mit.edu Sender: gnu@prep.ai.mit.edu Organization: Project GNU, Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA +1-617-542-5942 Subject: unsubscribe info-cvs lechner@cs.uml.edu Status: RO Return-Path: Received: from jupiter.cs.uml.edu by life.ai.mit.edu (4.1/AI-4.10) for gnu id AA01263; Tue, 17 Oct 95 03:42:44 EDT Received: (from lechner@localhost) by jupiter.cs.uml.edu (8.6.11/8.6.9) id DAA31900; Tue, 17 Oct 1995 03:42:42 -0400 From: Bob Lechner Message-Id: <199510170742.DAA31900@jupiter.cs.uml.edu> Subject: unsubscribe info-cvs lechner@cs.uml.edu To: info-cvs-request@prep.ai.mit.edu Date: Tue, 17 Oct 1995 03:42:41 -0400 (EDT) Cc: lechner@jupiter.cs.uml.edu X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 40 unsubscribe info-cvs lechner@cs.uml.edu The address: lechner@cs.uml.edu (Bob Lechner) has been removed as you requested. You might remain on other gnu mailing lists on prep.ai.mit.edu It is possible that there is still some undelivered mail waiting in the pending delivery queues. If you are still getting messages in a week, please tell the -request address for this list. enjoy -len Member, League for Programming Freedom. Ask: lpf@uunet.uu.net From info-cvs-ownrr@prep.ai.mit.edu Wed Oct 18 15:59:42 1995 Received: from gnu-life.ai.mit.edu (gnu-life.ai.mit.edu [128.52.32.60]) by jupiter.cs.uml.edu (8.6.11/8.6.9) with ESMTP id PAA05692 for ; Wed, 18 Oct 1995 15:59:40 -0400 Received: from life.ai.mit.edu by gnu-life.ai.mit.edu (8.6.12/8.6.12GNU) with SMTP id MAA07114; Wed, 18 Oct 1995 12:34:43 -0400 Received: by life.ai.mit.edu (4.1/AI-4.10) for bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06642; Wed, 18 Oct 95 12:34:39 EDT Received: from caffeine.avs.com by life.ai.mit.edu (4.1/AI-4.10) for /usr/lib/sendmail -odb -oi -finfo-cvs-ownrr@prep.ai.mit.edu info-cvs-gnu-life@gnu-life.ai.mit.edu bug-cvs-gnu-life@gnu-life.ai.mit.edu id AA06627; Wed, 18 Oct 95 12:34:18 EDT Received: from darkstar.avs.com by caffeine.avs.com (5.x/SMI-SVR4) id AA20736; Wed, 18 Oct 1995 12:32:06 -0400 Received: by darkstar.avs.com (5.x/SMI-SVR4) id AA03607; Wed, 18 Oct 1995 12:30:11 -0400 Date: Wed, 18 Oct 1995 12:30:11 -0400 Message-Id: <9510181630.AA03607@darkstar.avs.com> From: Gary Oberbrunner To: info-cvs@prep.ai.mit.edu Subject: cvs update -j problems Status: RO We have noticed that in server mode, cvs update -j sometimes does not actually modify the working file, although if you use -t it seems to be running all the right commands on the server; it just never downloads the merged file to the client. See the cvslog.out trace file below for details. It seems to happen when I'm merging (say) changes between 4.1 and 4.2 into a working file which is on a branch with no members yet (so its sticky tag is 4.1.2 but there is no rev 4.1.2.1). If I create 4.1.2.1, then everything works fine; the changes between 4.1 and 4.2 are merged into the working file. I've tried this with CVS 1.5 and 1.6; both exhibit this bug. Here's a sample *complete* /tmp/cvslog.out dialog. Notice that the last message is Copy-file. The Merged (or Updated or Patched) request never comes. ======================================== Valid-requests Root Valid-responses valid-requests Repository Directory Max-dotdot Static-directory Sticky Checkin-prog Update-prog Entry Modified Lost UseUnchanged Unchanged Argument Argumentx Global_option expand-modules ci co update diff log add remove update-patches gzip-file-contents status rdiff tag rtag import admin export history release ok E RCS file: /cvs/repository/express/modules/rf/nt.mak,v E retrieving revision 4.1 E retrieving revision 4.2 E Merging differences between 4.1 and 4.2 into nt.mak Copy-file ./ /cvs/repository/express/modules/rf/nt.mak .#nt.mak.4.1 ok ======================================== I'll look into this problem, but I was hoping someone out there has a patch already. thanks, -- Gary Oberbrunner garyo@avs.com Advanced Visual Systems, Inc. http://www.avs.com/~garyo 300 Fifth Avenue (617)890-8192 x2133 TEL Waltham, MA 02154 (617)890-2887 FAX From info-cvs-request@gnu.org Thu Apr 27 22:49:20 2000 Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21]) by jupiter.cs.uml.edu (8.10.0/8.10.0) with ESMTP id e3S2nK305365 for ; Thu, 27 Apr 2000 22:49:20 -0400 (EDT) Received: (from slist@localhost) by mescaline.gnu.org (8.9.1a/8.9.1) id WAA23271; Thu, 27 Apr 2000 22:47:56 -0400 Resent-Date: Thu, 27 Apr 2000 22:47:56 -0400 Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id UAA17847 for ; Thu, 27 Apr 2000 20:56:02 -0400 Received: from l3107mxr.atl.hp.com (l3107mxr.atl.hp.com [15.19.254.19]) by atlrel2.hp.com (Postfix) with ESMTP id 75FC413D4; Thu, 27 Apr 2000 20:55:57 -0400 (EDT) Received: from hpaco.aus.hp.com (hpaco.aus.hp.com [15.19.209.0]) by l3107mxr.atl.hp.com (Postfix) with ESMTP id 739044FD8F; Thu, 27 Apr 2000 20:55:34 -0400 (EDT) Received: from hpaco (mjd@hpaco.aus.hp.com [15.19.209.0]) by hpaco.aus.hp.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA06015; Fri, 28 Apr 2000 10:55:32 +1000 (EST) Sender: mjd@hpaco.aus.hp.com Message-ID: <3908E184.4FE9@aus.hp.com> Date: Fri, 28 Apr 2000 10:55:32 +1000 From: Mitch Davis Organization: Hewlett Packard, Australian Calculator Operation X-Mailer: Mozilla 3.03 (X11; I; HP-UX B.10.20 9000/898) MIME-Version: 1.0 To: Noel L Yap Cc: info-cvs@gnu.org Subject: Re: A little off topic: CVS features within ClearCase? References: <852568CE.007A66C2.00@nyc-ntgw-n01.ny.jpmorgan.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"QdJEY3.0.BN4.Q7E2v"@mescaline.gnu.org> Resent-From: info-cvs@gnu.org X-Mailing-List: archive/latest/16854 X-Loop: info-cvs@gnu.org Precedence: list Resent-Sender: info-cvs-request@gnu.org X-Status: Status: RO Noel L Yap wrote: > > I'm planning to use ClearCase for a new project I'm sorry. If you can _possibly_ get away with using CVS, do so. > 1. Having ClearCase do unreserved checkouts by default. It's possible. But if you've made changes you don't want to check in yet, CC doesn't give you the equivalent of "cvs up" to keep up with the latest. The recommended way of doing it is for each developer to have a private branch. Then you can do reserved or unreserved checkouts on the private branch, and the CC merge tools will help keep the branch up to date and with merges back to the main. A wonderful example of how CC turns your every move into a saga. > 2. Having ClearCase infer which files to operate on (ie > similar to plain vanilla "cvs ci"). Don't know. How CC internally stores files depends on a heuristic which is pretty good, ie, binary files are stored compressed, etc. Note, there is no RCS keyword expansion. > 3. Having ClearCase do atomic operations (eg either all > entities specified get checked in or none of them do). I believe you can lock the vob to prevent others from using it, which makes it essentially atomic (ie, no half-way state is possible. But I don't believe it offers "transactions", where if something doesn't work, you can roll back to a known state. Regards, Mitch. -- | mailto:mjd@aus.hp.com | Not the official view of: | | mailto:mjd@alphalink.com.au | Australian Calculator Opn | | Certified Linux Evangelist! | Hewlett Packard Australia | From info-cvs-request@gnu.org Wed Apr 26 20:00:59 2000 Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21]) by jupiter.cs.uml.edu (8.10.0/8.10.0) with ESMTP id e3R00w315678 for ; Wed, 26 Apr 2000 20:00:58 -0400 (EDT) Received: (from slist@localhost) by mescaline.gnu.org (8.9.1a/8.9.1) id UAA17910; Wed, 26 Apr 2000 20:00:11 -0400 Resent-Date: Wed, 26 Apr 2000 20:00:11 -0400 Received: from heimdall.sdrc.com (heimdall.sdrc.com [146.122.132.195]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id QAA12908 for ; Wed, 26 Apr 2000 16:41:57 -0400 Received: from mailhub-cvg.sdrc.com (mailhub-cvg.sdrc.com [146.122.142.31]) by heimdall.sdrc.com (8.9.1/8.9.1) with ESMTP id QAA25740; Wed, 26 Apr 2000 16:41:39 -0400 (EDT) Received: from thor.sdrc.com (scjones@thor [146.122.62.108]) by mailhub-cvg.sdrc.com (8.8.8/8.8.5) with ESMTP id QAA09755; Wed, 26 Apr 2000 16:41:38 -0400 (EDT) Received: (from scjones@localhost) by thor.sdrc.com (8.9.0/8.9.0) id QAA12430; Wed, 26 Apr 2000 16:41:38 -0400 (EDT) Message-Id: <200004262041.QAA12430@thor.sdrc.com> Subject: Re: cvs add: warning: unrecognized response `'' from cvs server To: spyatt@selectica.com Date: Wed, 26 Apr 2000 16:41:38 -0400 (EDT) Cc: info-cvs@gnu.org In-Reply-To: <003b01bfafae$233ec5f0$2a02000a@selectica.com> from "Scott Pyatt" at Apr 26, 0 11:35:02 am From: larry.jones@sdrc.com (Larry Jones) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ygpby1.0.AA3.eIr1v"@mescaline.gnu.org> Resent-From: info-cvs@gnu.org X-Mailing-List: archive/latest/16830 X-Loop: info-cvs@gnu.org Precedence: list Resent-Sender: info-cvs-request@gnu.org X-Status: Status: RO Scott Pyatt writes: > > bash-2.02$ cvs add -m "Adding dirs that import missed" 0009-English > cvs add: warning: unrecognized response `'' from cvs server > cvs add: warning: unrecognized response `'' from cvs server > cvs add: warning: unrecognized response `'' from cvs server > cvs add: warning: unrecognized response `'' from cvs server > Directory /cvsroot/installers/InstallShield/ACEMobile/Setup > Files/Compressed Files/0009-English added to the repository My guess would be that it has something to do with the spaces in the path name. CVS doesn't really support spaces in file or directory names yet. -Larry Jones Pitiful. Just pitiful. -- Calvin From info-cvs-request@gnu.org Wed Apr 26 19:20:47 2000 Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21]) by jupiter.cs.uml.edu (8.10.0/8.10.0) with ESMTP id e3QNKk309036 for ; Wed, 26 Apr 2000 19:20:46 -0400 (EDT) Received: (from slist@localhost) by mescaline.gnu.org (8.9.1a/8.9.1) id TAA08546; Wed, 26 Apr 2000 19:19:57 -0400 Resent-Date: Wed, 26 Apr 2000 19:19:57 -0400 Received: from cindy.surveyorcorp.com ([63.201.6.119]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id OAA04299 for ; Wed, 26 Apr 2000 14:48:58 -0400 Received: (from chahn@localhost) by cindy.surveyorcorp.com (8.9.3/8.9.3) id LAA18504 for info-cvs@gnu.org; Wed, 26 Apr 2000 11:48:21 -0700 Date: Wed, 26 Apr 2000 11:48:21 -0700 From: Cindy Hahn To: info-cvs@gnu.org Subject: Re: cvs over ssh ugliness Message-ID: <20000426114821.A18501@surveyorcorp.com> References: <20000420151559.A859@surveyorcorp.com> <20000421141751.78C1DE4@proven.weird.com> <20000421103651.A3280@surveyorcorp.com> <39062B85.DCB57041@telus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <39062B85.DCB57041@telus.com> Resent-Message-ID: <"9AxQm2.0.P31.aep1v"@mescaline.gnu.org> Resent-From: info-cvs@gnu.org X-Mailing-List: archive/latest/16828 X-Loop: info-cvs@gnu.org Precedence: list Resent-Sender: info-cvs-request@gnu.org X-Status: Status: RO We finally found the problem. It was neither CVS or SSH that was the issue. The developer had recently had a couple of anti-virus programs run out of their evaluation periods. They were preventing the file transfer from occuring. *sigh* Thanks for the responses anyway, we'll keep them on file in case anybody else has any trouble. -- Cindy -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- Cindy L. Hahn chahn@surveyor.com Software Engineer Surveyor Corporation -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=- -=-