sue@WJ.COM (Sue Chung) (03/30/91)
Thank you very much for all the people who reply to my post on newsnet and
valuable suggestions. I really appreciate your taking time to send
all the informations to us.
After playing with CVS for two weeks, I have come to conclusions that CVS is
the tool we should use to control our future releases.
As some pepole requested for summary, please find following are all
the clippings.
Sue
Date: Thu, 21 Mar 91 08:29:51 MST
From: berliner@Central.Sun.COM (Brian Berliner)
Message-Id: <9103211529.AA01830@rmtc.Central.Sun.COM>
Received: by nogger.Central.Sun.COM (4.1/SMI-4.1)
id AA03012; Thu, 21 Mar 91 08:30:10 MST
To: sue@WJ.COM
Cc: berliner@Central.Sun.COM
Subject: Re: CVS revision control system
Newsgroups: comp.software-eng
References: <1991Mar20.202359.16009@WJ.COM>
Status: R
In comp.software-eng you write:
>We are using RCS currently to control our software releases. We must
>support two different hardware platforms and three different releases
>(sub-sets of files from the master repository). We are evaluating CVS
>to see if it will meet our requirements and ease our pain a little
>bit. However, in reading the CVS manual, it seems that using CVS to
>control production of binaries for multiple architectures is not well
>addressed. We are starting our efforts to use CVS, if there is anyone
>out there who would like to throw some of their experience or advice
>our way we would greatly appreciate it.
Building multiple binary releases in CVS is no different than building a
single binary release in CVS. You just need to check out multiple copies
of the sources.
The hard part comes when your sources have to share certain pieces, but not
all pieces, with the different releases. The CVS modules database can help
put this together. Try to make a single module name that will describe
each of your three releases. If you have to, use symbolic links in your
source repository to grab pieces from the right places to build exactly the
hierarchy that you need (with the appropriate sharing) for each release.
The modules support has been redesigned for the next major release (ship
date unknown) and is MUCH more flexible in doing this stuff for you. But,
that release is not ready for public consumption yet.
Also, consider building a few "release tools" -- shell scripts that sit
atop CVS and help make building and controlling binary release production.
CVS is the tool, and you need to tell it what to do by customizing a script
to meet your particular needs. That's what we do here.
>Other than the manual pages provided with the sources, we have not found
>any books on RCS or CVS.
Nope... the publishers have not been breaking my doors down to write a book
for CVS. And my management always wants me to produce other products, so
the CVS development and documentation is always lacking what a "funded" and
supported product can produce. Such is life. But, the price is right :-).
I must also point out that Sun's NSE product (Network Software Environment)
might suit your needs better than the current version of CVS. It also
comes with a pile of ducuments.
Best of luck in your source code control pursuit.
-Brian
Date: Thu, 21 Mar 91 01:54:52 -0800
From: Greg Onufer <greg@cheers.Bungi.COM>
Message-Id: <9103210954.AA01836@cheers.Bungi.COM>
To: sue@wj.com
Subject: Re: CVS revision control system
Newsgroups: comp.software-eng
References: <1991Mar20.202359.16009@WJ.COM>
Status: RO
The CVS paper documents how Prisma used CVS to control sources
for common programs (cat, ls, etc.) coming from multiple sources:
System V (AT&T), SunOS (Sun), and 4.3BSD (Berkeley). The
solution is to make multiple vendor branches and tag them with
names (S7K, S9K, etc.) and even go as far as to create branches
with the serial numbers of machines if there are any that require
that level of customization. The checkin script (a C-Shell
program) doesn't inherently support this at this time (checking
in complete trees), but 1) WJ is making the repository as they
go at this point and 2) my checkin script allows the user to
specify the branch number explicitly with a command line switch.
CVS 2.0 will help out quite a bit in doing this (right now you
have to watch your command line arguments, but, then, using the
lower level SCCS or RCS commands you would anyways). It's expected
"Real Soon Now" from Brian Berliner (who now works at Sun since
they bought Prisma or something like that).
Cheers!greg
Date: Thu, 21 Mar 91 10:27:24 MST
From: Michael T. Rampson <rampson@flash.uswest.com>
Message-Id: <9103211727.AA18721@flash.uswest.com>
To: sue@WJ.COM (Sue Chung)
Subject: Re: CVS revision control system
Status: R
We have been using RCS here for quite some time. We have built up a suite of tools on top
of RCS (written in perl). We don't have enough collision on file to warrant the use of
CVS (although there are some nice features that CVS has that would make life easier).
To handle building the software on multiple platforms, we use imake to generate our
makefiles for the given platform (we rewrote the templates to trim them down and make
them work with our directory structure). Imake is available with X. We use NFS to
mount the source directories (all source for a project is stored on one machine and is then
exported to whatever machine needs it). We can then use the berkeley rcmds to do
remote builds and get reporting back to one location (clear as mud?).
Hope this helps,
mike
__
"There is no dog" -- A dislexic atheist.... rampson@uswat.uswest.com
From: smd@rehder.larc.nasa.gov (Steve Dahmen)
Date: Thu, 21 Mar 1991 14:59:35 EST
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: sue@wj.com
Subject: RCS, etc.
Status: R
Sue,
In regards to your posting in comp.soft-eng...
We have written a fairly thorough set of tools on top of RCS called
LARCS (Langley Revision Control System) and we have it controlling
a number of projects here. It is basically a system of shell scripts,
aliases, and Environmental variables
which call RCS low-level routines, keep a log of all activity with the
master source, and cross-reference changes with MR/bug numbers or ids.
Unlike CVS, it does not handle parallel development. :-(
One thing that turned us off about CVS is that you have
to check out ALL the source into your local directory and compile the
whole bloody thing! (At least this is what i gathered). LARCS uses
a central repository for object files, too, so that developers can
just link them in to the few object files they have compiled in their
own directory. This conserves enormous amounts of disk, which was
important to us. Seems a lot of people don't care much, tho.
Currently we do not simultaneously support different versions. We only have
successive releases of the same product, evolving it continuously.
But with minor modifications, you could easily (?) make LARCS do what you
need.
As developers put back tested modules, the record of the ci is put in
a special log. When it is time to do the integrated product build,
this log is run through a program that co's the latest revision of
each file changed. After the build, I run a program that goes through
and, using the symbolic labeling facility of RCS, creates a label
corresponding to that release or version for every .c file present.
This allows me to fetch the source for any version with one command.
The system has a fairly thorough set of manpages, and is good with
error and interrupt handling. And since its written in shell, it
should run well on all versions of UNIX.
If you should want more info, I have the overview manpage for LARCS
that I am sending behind this letter. Feel free to call or write with
any questions, etc.
Best of Luck!!!
Steve Dahmen
Status: R
I've never heard of CVS, but we use RCS to control software libraries that
are used to build five different products on seven different platforms (six
of which don't run UNIX). If you're interested, I can outline how we go
about doing that.
--
Larry Campbell The Boston Software Works, Inc., 120 Fulton Street
campbell@redsox.bsw.com Boston, Massachusetts 02109 (USA)
Date: Mon, 25 Mar 91 11:06:23 PST
From: Alan Wright <alan%cwi.uucp@ICS.UCI.EDU>
Message-Id: <9103251906.AA09364@>
To: sue@wj.COM
Subject: Re: CVS revision control system
In-Reply-To: your article <1991Mar20.202359.16009@WJ.COM>
News-Path: cwi!ucivax!jarthur!bridge2!mips!daver!watjo!sue
Status: RO
> We are using RCS currently to control our software releases. We must
> support two different hardware platforms and three different releases
> (sub-sets of files from the master repository). We are evaluating CVS
> to see if it will meet our requirements and ease our pain a little
> bit. However, in reading the CVS manual, it seems that using CVS to
> control production of binaries for multiple architectures is not well
> addressed. We are starting our efforts to use CVS, if there is anyone
> out there who would like to throw some of their experience or advice
> our way we would greatly appreciate it.
>
> Other than the manual pages provided with the sources, we have not found
> any books on RCS or CVS.
>
> E-mail replies will be appreciated.
> Thanks to all who reply.
I can only suggest that you consider using a tool designed to solve the
problems you face. This does require a considerable investment, but
will probably pay off in the long term. Tools such as RCS, CVS, and
others may ease your pain a little in the short term, but can create
a maintenance problem, and actually introduce more problems and limitations
that they solve.