Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 03 Jul 1999 01:37:15 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Mike Smith <mike@smith.net.au>, Alexander Langer <alex@cichlids.com>, Nick Hibma <nick.hibma@jrc.it>, Matthew Jacob <mjacob@feral.com>, freebsd-current@FreeBSD.ORG
Subject:   Re: this of interest to anyone? 
Message-ID:  <19990702173715.0C28F64@overcee.netplex.com.au>
In-Reply-To: Your message of "Fri, 02 Jul 1999 10:20:20 MST." <199907021720.KAA57460@apollo.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> :This doesn't mean it's OK for committers to screw things up for fun, but
> :we're only human.  We do try and keep it in fairly good condition
> :(remember, the developers depend on it working for development), but
> :mistakes happen..
> :
> :Cheers,
> :-Peter
> 
>     Hey, I just had a thought... and a question.  When we are using cvsup to
>     keep a local CVS reposity in sync, can we tag our local CVS resposity 
>     without cvsup deleting the tags?
> 
> 					-Matt

Yes...  And you can even branch the local cvs repo and have cvsup work
around it..  The trick is to have a non conflicting magic branch number.
Try setting CVS_LOCAL_BRANCH_NUM=1000 or so in the environment and do a
tag -b.  If I remember correctly, you need to disable the 'delete' mode.
Hmm:

     delete      The presence of this keyword gives cvsup permission to delete
                 files.  If it is missing, no files will be deleted.

                 The presence of the delete keyword puts cvsup into so-called
                 exact mode.  In exact mode, CVSup does its best to make the
                 client's files correspond to those on the server.  This in-
                 cludes deleting individual deltas and symbolic tags from RCS
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                 files, as well as deleting entire files.  In exact mode,
                 CVSup verifies every edited file with a checksum, to ensure
                 that the edits have produced a file identical to the master
                 copy on the server.  If the checksum test fails for a file,
                 then CVSup falls back upon transferring the entire file.

I recall testing this when John was first working on cvsup (that's where
the CVS_LOCAL_BRANCH_NUM hack came from :-), and it worked then.  I don't
know how well (or if) it works now.

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990702173715.0C28F64>