Newsgroups: comp.software-eng
Path: utzoo!utgpu!cunews2!bnrgate!scrumpy!bnrmtl@bnr.ca!pat
From: pat@bnrmtl.bnr.ca (Patrick Smith)
Subject: Re: CVS-RCS
Message-ID: <1991May22.163101.26179@scrumpy@.bnr.ca>
Sender: news@scrumpy@.bnr.ca (USENET NEWS KJ)
Reply-To: bnrmtl!pat@larry.mcrcim.mcgill.edu
Organization: Bell Northern Research, Montreal, Canada.
References: <1991May21.135016.3671@apertus.uucp> <1991May22.142240.16480@newshost.anu.edu.au>
Date: Wed, 22 May 91 16:31:01 GMT

In article <1991May22.142240.16480@newshost.anu.edu.au>, cmf851@anu.oz.au (Albert Langer) writes:
|> In article <1991May21.135016.3671@apertus.uucp> apertus!ivanp@tenfwd.uci.com writes:
|> 
|> >One can not check in a release, other than the most current. (cvs ci *)
|> >
|> >Is there a easy process that I am missing? 
|> 
|> I haven't actually used CVS yet, so this response may be quite wrong,
|> but from my reading of the docs there is indeed an easy process that you
|> are missing.
|> 
|> Try using cvs ci *
|> 
|> I think you will find that it checks in on the same branch that you
|> checked out on, since a record of what you checked out is kept in the
|> local admin files with your checked out source.
|> 
|> --
|> Opinions disclaimed (Authoritative answer from opinion server)
|> Header reply address wrong. Use cmf851@csc2.anu.edu.au

Well, I haven't used CVS much myself (yet), but I've spent a
while figuring out how to set it up here.  It seems to me that
you're far better off using separate directories for different
releases.  If you try to combine them in a single directory,
with different RCS/CVS branches (releases), you wind up with
a number of problems:

First, a simple 'cvs ci' without the -r option will not work
to check changes into the old release.  cvs will try to commit
your changes into the newest release.  (If you checked the files
out from the old release before making any changes, cvs won't do
anything; it will just tell you that your copies are not up to
date - since you don't have the latest revisions from the new release.)

BUT - when you commit use the -r option, all the normal
consistency checks are skipped.  One of these checks for
multiple updates.  So if person A checks out a file from the
old release, then B checks out the same file (again from the old
release), makes some changes and commits the changes to the
old release, and then A makes some changes and commits those,
then B's changes will be lost.

-- 
Patrick Smith      Bell-Northern Research, Montreal, Canada
(514) 765-7914   bnrmtl!pat@larry.mcrcim.mcgill.edu   patrick@bnr.ca

... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.