NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/unix/programm/5899

Text File | 1993-01-12 | 5.8 KB | 115 lines

Newsgroups: comp.unix.programmer
Path: sparky!uunet!zaphod.mps.ohio-state.edu!howland.reston.ans.net!usc!cs.utexas.edu!torn!utzoo!utdoe!torag!robohack!woods
From: [e-mail] (Greg A. Woods)
Subject: Re: Revision control by directory tree
Organization: Elegant Communications Inc.
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
Keywords: sccs rcs cvs directories
Date: Tue, 12 Jan 93 06:46:14 GMT
Lines: 103

In article <[e-mail]> [e-mail] (Michael Salmon) writes:
> In article <[e-mail]>
> [e-mail] (Pierre Asselin) writes:
> |> I am maintaining libraries of in-house code and I want to place the
> |> files under revision control.  My boxes (AIX 3.[12]) only have sccs.
> |> I have been using sccs for single-file programs, but a library source
> |> is typically spread over many files.  I want all the files to have the
> |> same revision number.  Sccs won't do that.  I don't have large teams of
> |> programmers to manage;  all I need at this point is per-project
> |> revision numbers.

No, unless you want to lose the ability to control, identify, and
measure changes to each file, you most definitely do not want all
files in a given library to have the same "revision number".  Perhaps
what you meant to say was you want to be able to identify the revision
(number) of a given file by a version label for the final product, such
that the revision (number) of each file necessary to build a given
version of the product (library) may be identified.

Revision numbers of individual files have no meaning outside of being
simple sequential markers of change management events for each file.

SCCS and RCS manage chages to individual files, not groups of files
(though both have some features which permit common identification of
a given configuration of files, and both can be used on a group of
files such that simultaneous, possibly empty, deltas can be done in
order to maintain identical revision numbers).

This simple idea is crutial to understanding how to effectively and
practically use such tools.

A simple configuration management scheme can be constructed with SCCS
(or RCS) by keeping a release manifest which identifies the files
present in a given configuration, together with the revision numbers
of each of file.  A *very* simple script, when given the release
manifest for a give version of the library, will then suffice to
generate the source files necessary to build the product.

In the simple cases this manifest may itself be submitted to change
management, and perhaps its revision number will then suffice as the
version number for the entire product.

> |> According to the c.u.questions FAQ, RCS has a feature (symbolic names)
> |> that might come close enough to what I want.  I lifted some BSD docs
> |> from uunet but they weren't specific enough.

Indeed, this is one such configuration management feature, though it
does not address the issues surrounding addidion or deletion (or
re-naming) of source files from the product configuration definition.
To do this a manifest is still required.

> |> Surely this is a common problem.  How do you handle it?  Should I
> |> install RCS?  Should I get CVS instead?

Yup, it's a common problem.  Unfortunately it has until recently been
a poorly understood problem, and most everone has had a different view
and various opinions as to how best to solve it.  Only recently have
folks begun to pay serious attention to the (not so) recent developments
in the software engineering disciplines.

You should most definitely get CVS (1.3), but you'll have to get RCS
(5.6) and GNU-diff (2.0) installed first.  It has a few quirks, and
requires some TLC by the admin/librarian/whatever, but makes
coniguration management a breeze, and regardless of the number of
programmers working on a product (i.e. from one to ????), it permits a
great deal of freedom, while still strictly enforcing merging of
simultaneous changes and facilitating easy sharing of changes for
multi-programmer products.  In addition, CVS is an essential tool to
helping maintain local modifications to on-going releases of
third-party sources.

Send mail to [e-mail] to join the mailing
list!  There's been lots of good discussion lately, and even a few
patches!

> Hence when you edit a file for the first time in a release e.g. 5 set
> the revision to 5.1 then follow the normal edit/delta cycle and when
> you make the library simply set SCCSFLAGS to -r5. Alternately you can
> check out all sources at the beginning of the release with the correct
> revision and then check them back without changes, personally I prefer
> the first method though it does require some thought. This isn't quite
> what you asked for but I hope that it is what you want.

Indeed this will work, though it's only practical for a small group of
files which can be clearly identified as source for a single given
product.  In addition, this scheme also lacks the file manifest...

Another option, which has far more flexibility, is to use cutoff dates
for the version identification.  I.e. the source file revisions for a
given version of a product release might be identified by finding the
most recent revision prior to a given date (and time).  This can be
done with the '-c<cutoff>' option to SCCS's get command.  The drawback
to this approach is that it requires that all development be frozen
while testing and QA verifies that the current code is in working
order.  In other words, this scheme is best used by single-developer
projects.  An example of how you can tie all of this together with
make(1) can be found in the forthcoming release of uutraf-2.0 in
comp.sources.unix.
--
                        Greg A. Woods

[e-mail], [e-mail]  VE3TCP    UniForum Canada & ECI
[phone] [home] +1 416 362-XRSA [work]    Toronto, Ontario; CANADA