Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!spool.mu.edu!cs.umn.edu!kksys!edgar!brainiac!apertus!news
From: ivanp@mc.UUCP (Ivan Peters)
Newsgroups: comp.software-eng
Subject: Re: CVS-RCS
Message-ID: <1991May23.194137.4439@apertus.uucp>
Date: 23 May 91 19:41:37 GMT
References: <1991May21.135016.3671@apertus.uucp> <1991May22.142240.16480@newshost.anu.edu.au>
Sender: news@apertus.uucp (0000-news(0000))
Reply-To: apertus!ivanp@tenfwd.uci.com
Organization: Apertus Technologies
Lines: 82

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 *)
***PLEASE NOTE STATEMENT IN ()
|> >
|> >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 *
***PLEASE NOTE  :-)
|> 
|> 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.
|> 
|> If I haven't misunderstood the essence of what cvs is all about, then
|> I suspect you have :-) and you need to re-read the docs free from any
|> preconceptions about how RCS and SCCS behave. If I'm wrong then I
technically yes, at this point, a cvs ci * only checks in to the most
current as I pointed out in the first posting, and is included in your
re-post...
|> need to do so myself and would welcome somebody pointing this out.
|> 
I would suggest one re-reads a message (and ones' reply), before one posts
it.  :-)
I do apreciate the attempt!!

  Two points:
-The response was very short, and therefore could be misunderstood on my end.
 (my apologies! if true)
-My original description of the problem was apparently not clear enough.
 (It was the best description I was able to offer at the time.
  But, if anyone can misunderstand something, it is not clear enough so
  my apologies again)

I will atempt to clarify...
-I do not think I am missing a basic function, I think I am missing a
procedure, i.e. combination of functions.

What I have done is:
cvs tag -rTEST1_0 test             ; marking existing for continued support
                                   ; on 1_0
cvs ci -r2.0 *                     ; setting up devel on 2.0 files
cvs tag -rTEST2_0 test             ; mark devel with a tag for easy co
cvs co -rTEST1_0 test              ; get ready for support on 1_0

at this point I have my problem.
after some changes to test 1_0
if I try: cvs ci *    it requests an update.

if I try:cvs update -rTEST1_0     nothing significant changes, the following
cvs ci * will still request an update before proceding.

if I try:cvs update     it will default to  most current, and once more
merge me with 2_0, the TEST2_0 files, which I do not want yet.

if I try a file by file checkin on the 1.* revision level files,
cvs ci -r1.5.1.1 xx.c  (with the requirement to tag each file revision )
cvs does not appear to keep track of these revisions, it gives one a
WARNING that it will bypass all consistency checks whenever cvs ci -r is
used.  This does not allow a update sequence at any level other than the
top.

Which leaves me with... how can one branch, to do support, on files
previeous to ones most current/development track?

a seperate dir for support and devel under the repository is not very
desireable (but I would like to know if it is the only way people have done
it) for two reasons:
-ones' support repository/dir is a duplicate of ones' devel repository/dir (to
a major extent)
-merging between the two can easily become a problem.

I think that this info would be useful for anyone tring to use CVS and RCS
for a configuration management system.

Any help/suggestions would be APRECIATED!!
I don't think this is a trivial problem... (Though I hope it is)