Configuration Management for Ada on Unix

Configuration Management for Ada on Unix

[David R. Ellison]

I am working on a project which has moved from VMS to Unix.  We
are using the Thomson (Alsys) Ada compiler on HP-UX.  We are using 
the AdaMake tool that came with the compiler to determine compilation 
order and rebuild libraries.

The compiler and AdaMake don't have any apparent way to access
source code stored in configuration management files (such as 
SCCS or RCS).  Our project is large enough (more than one file 
and one programmer) such that CM is a necessity.  However the 
Thomson documentation doesn't seem to acknowledge that CM exists.  

If anyone knows how to apply CM while using Thomson Ada on Unix,
please email me or post the information.  If there are other ways 
to apply CM to a Ada project on Unix, I would be interested even 
if it means giving up use of AdaMake.

Thanks,
Dave Ellison

-- 
| David Ellison                     | ellison@gdesystems.com    |
| GDE Systems, Inc.,                | Tel: (619) 592-5189       |
| P.O. Box 509008,    MZ 6100-D     | Fax: (619) 592-5420       |
| San Diego, CA 92150-9008          | http://www.gdesystems.com |

Re: Configuration Management for Ada on Unix

[Theodore E. Dennison]

David R. Ellison wrote:
> 
> I am working on a project which has moved from VMS to Unix.  We
> are using the Thomson (Alsys) Ada compiler on HP-UX.  We are using
> the AdaMake tool that came with the compiler to determine compilation
> order and rebuild libraries.
> 
> The compiler and AdaMake don't have any apparent way to access
> source code stored in configuration management files (such as
> SCCS or RCS).  Our project is large enough (more than one file
> and one programmer) such that CM is a necessity.  However the
> Thomson documentation doesn't seem to acknowledge that CM exists.

The project I worked on that had a UNIX/SCCS/Alsys setup just used
"sccs get" on every ada source file right before compilation. This
gets you a read-only working copy, which you can use to compile.

Every project I've worked on that was large enough to need engineering
CM did something roughly similar.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Configuration Management for Ada on Unix

[Robert Dewar]

Dave asked

"If anyone knows how to apply CM while using Thomson Ada on Unix,
please email me or post the information.  If there are other ways
to apply CM to a Ada project on Unix, I would be interested even
if it means giving up use of AdaMake."

If you are using a source based approach, then integration of this
kind with a CM is straightforward. GNAT can certainly do this today,
and presumably the new version of the Thomson Ada technology, based
on the Intermetrics front end which also uses a source based approach,
will be able to do the same thing.

With GNAT, the corresponding utility gnatmake just needs access to the
relevant source files and ali files, and these can certainly be obtained
from the appropriate CM space.

Re: Configuration Management for Ada on Unix

[Dave Wood]

Robert Dewar wrote:
> 
> Dave asked
> 
>> "If anyone knows how to apply CM while using Thomson Ada on Unix,
>> please email me or post the information.  If there are other ways
>> to apply CM to a Ada project on Unix, I would be interested even
>> if it means giving up use of AdaMake."
> 
> If you are using a source based approach, then integration of this
> kind with a CM is straightforward. GNAT can certainly do this today,
> and presumably the new version of the Thomson Ada technology, based
> on the Intermetrics front end which also uses a source based approach,
> will be able to do the same thing.
> 

It is true that ObjectAda 7.0 is source based, providing great
flexibility in access and control of program components, however
to answer the specific question of AdaWorld for HP, probably the
best solution is to hook it up with the best CM system available,
ClearCase from Atria.  Thomson offers an add-on called 
ClearCase/Ada for HP and other Unix platforms (and now also NT), 
which provides a clean and direct integration with ClearCase.

Contact your sales rep for more information, or check it out
on our web site at:

http://www.thomsoft.com/products/ada/cca_ds.html


-- Dave Wood
-- Windows Product Manager
-- Thomson Software Products (for the time being)
-- Home of $99 Ada for Windows
-- http://www.thomsoft.com
-- ObjectAda for Windows timeline:
--     Ada 95 validatable:  Tri-Ada 1995 (done)
--     Registered validation:  December 18, 1995 (done)
--     Alpha test:  December 31, 1995 (done)
--     Beta 1 test:  February 29, 1996 (done)
--     Beta 2 test:  May 31, 1996
--     Shipping:  Summer, 1996

Re: Configuration Management for Ada on Unix

[Bob Gilbert]

In article <4nvm27$e68@gde.GDEsystems.COM>, ellison@gde.GDEsystems.COM (David R. Ellison) writes:
> 
> I am working on a project which has moved from VMS to Unix.  We
> are using the Thomson (Alsys) Ada compiler on HP-UX.  We are using 
> the AdaMake tool that came with the compiler to determine compilation 
> order and rebuild libraries.
> 
> The compiler and AdaMake don't have any apparent way to access
> source code stored in configuration management files (such as 
> SCCS or RCS).  Our project is large enough (more than one file 
> and one programmer) such that CM is a necessity.  However the 
> Thomson documentation doesn't seem to acknowledge that CM exists.  
> 
> If anyone knows how to apply CM while using Thomson Ada on Unix,
> please email me or post the information.  If there are other ways 
> to apply CM to a Ada project on Unix, I would be interested even 
> if it means giving up use of AdaMake.
> 
> Thanks,
> Dave Ellison

I've got the very same desire, but using a Tartan comiler (Sun host,
C40 target).  I was spoiled on my first Ada project which used VAX Ada.
VAX Ada had a very nice feature which allowed you to specify that the
source code was in CMS (VAX version of SCCS) and a re-compile command
could be specified to search CMS to locate any updated versions of
the source and compile them while picking up all (but only) the 
obsoleted units.

I've asked Tartan about offering this sort of feature, but they claimed
that it is not practical since they support a variety of host environments
(not all would provide SCCS) and they would not want to lock themselves
into any particular CM tool.

Our current method is to perform an SCCS get on all files and perform
total re-compile using a command file.  Not the most efficient, but safe.

-Bob

Re: Configuration Management for Ada on Unix

[Laurent Pautet]

Theodore E. Dennison <dennison@escmail.orl.mmc.com> wrote:
>The project I worked on that had a UNIX/SCCS/Alsys setup just used
>"sccs get" on every ada source file right before compilation. This
>gets you a read-only working copy, which you can use to compile.

It seems to be a rather straightforward combination of RCS (or SCCS)
and make (something like):

%.ads : RCS/%.ads,v
        co -f $<

%.adb : RCS/%.adb,v
        co -f $<

-- 
-- Laurent

Re: Configuration Management for Ada on Unix

[Bob Crispen]

Laurent Pautet wrote:

>Theodore E. Dennison <dennison@escmail.orl.mmc.com> wrote:
>>The project I worked on that had a UNIX/SCCS/Alsys setup just used
>>"sccs get" on every ada source file right before compilation. This
>>gets you a read-only working copy, which you can use to compile.
>
>It seems to be a rather straightforward combination of RCS (or SCCS)
>and make (something like):
>
>%.ads : RCS/%.ads,v
>        co -f $<
>
>%.adb : RCS/%.adb,v
>        co -f $<

We got a little more involved on one project I'm thinking of.  We had
shell scripts to check modules in and out that added delta lines for us
and required us to describe changes, and so on.  It was homebrew and used
sccs for a delta engine, but it wasn't terribly complicated.  A man-month
or two for a serious shell programmer would give you the most baroque,
complicated configuration management system your managers could possibly
want.

I've worked with another system that used a database and was even more
complicated, running awk scripts to change individual lines in the code
depending on the version required, and that took some time to develop.

It really just depends on what you need.  If you've got a number of
simultaneous versions and targets and are doing a real product-line set
of builds, you'll obviously need one of the professional products, while
homebrew version control will do you if you have a handful of targets
and have only a rolling 3-version system (Test, Current, and Delivery).

Note that SCCS allows you to have several directory trees.  You can have
one tree for each version, and within that trees for platforms (e.g.,
common, vme, workstation).  SCCS can then load everything down to one
big directory for each build.  Unlike the flat(ter) VMS filesystem, Unix's
filesystem can be used as a serious helper for your configuration management
tool.

Bob Crispen
crispen@hiwaay.net
speaking for myself, not my employer

Re: Configuration Management for Ada on Unix

[Laurent Pautet]

In article <31A79E0A.2F99@hiwaay.net>, Bob Crispen  <crispen@hiwaay.net> wrote:
>
>It really just depends on what you need.  If you've got a number of
>simultaneous versions and targets and are doing a real product-line set
>of builds, you'll obviously need one of the professional products, while
>homebrew version control will do you if you have a handful of targets
>and have only a rolling 3-version system (Test, Current, and Delivery).
>
>Note that SCCS allows you to have several directory trees.  You can have
>one tree for each version, and within that trees for platforms (e.g.,
>common, vme, workstation).  SCCS can then load everything down to one
>big directory for each build.  Unlike the flat(ter) VMS filesystem, Unix's
>filesystem can be used as a serious helper for your configuration management
>tool.

Maybe I am wrong, but I think SCCS is very unefficient because it
stores patches between Version (N+1) - Version (N) and when you want
to access to version N, internally SCCS retrieves version 0 and
applies all the patches to obtain version N. RCS stores the last
version (rather than the first one) and differences between Version
(N) - Version (N+1).

Anyway, you should have a look at CVS. It provides a lot of nice
features, especially those you mentionned above. Basically, it's a
configuration and version system when RCS and SCCS are only version
systems.

-- 
-- Laurent

Re: Configuration Management for Ada on Unix

[Theodore E. Dennison]

Laurent Pautet wrote:
> Maybe I am wrong, but I think SCCS is very unefficient because it
> stores patches between Version (N+1) - Version (N) and when you want
> to access to version N, internally SCCS retrieves version 0 and
> applies all the patches to obtain version N. RCS stores the last
> version (rather than the first one) and differences between Version
> (N) - Version (N+1).
> 

That depends on what you mean by "inefficient". Assuming you aren't
making massive changes to files when you check them out, it is very
efficient for disk space, at the expense of checkout and checkin 
time.

One problem I have seen is that the SunOS 4.1 version we used had
a bug that rendered a file impossible to check back in if it was
checked out from an "su"ed session. I hope that has been fixed.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: Configuration Management for Ada on Unix

[Laurent Pautet]

Theodore E. Dennison <dennison@escmail.orl.mmc.com> wrote:
>Laurent Pautet wrote:
>> Maybe I am wrong, but I think SCCS is very unefficient because it
>> stores patches between Version (N+1) - Version (N) and when you want
>> to access to version N, internally SCCS retrieves version 0 and
>> applies all the patches to obtain version N. RCS stores the last
>> version (rather than the first one) and differences between Version
>> (N) - Version (N+1).
>> 
>
>That depends on what you mean by "inefficient". Assuming you aren't
>making massive changes to files when you check them out, it is very
>efficient for disk space, at the expense of checkout and checkin 
>time.

No, no. What I mean is to get the last version of a file, SCCS gets
the first version and applies all the patches to get the last
version. With RCS or CVS, the last version is always there. To get the
previous version, RCS applies a patch. My argument concerns the way
the storage space is structured. SCCS and RCS have different storage
models, different ways of building a given version. SCCS starts from
the first version, RCS starts from the last version. That's all. The
storage size is the same but the time to build the last version is
(N-1) * T for SCCS and 0 for RCS (T = average time to apply a patch, N
= number of file version). It is the difference between SCCS's
interleaved deltas and RCS's reverse deltas. Retrieving the last
version is a very common operation. So, RCS is more time efficient
than SCCS. Concerning disk space, it is almost exactly the same
efficiency based on difference between two successive versions.
-- 
-- Laurent

Re: Configuration Management for Ada on Unix

[Tucker Taft]

Laurent Pautet (pautet@email.enst.fr) wrote:

: ... What I mean is to get the last version of a file, SCCS gets
: the first version and applies all the patches to get the last
: version. 

This makes it sound worse than it is.  SCCS performs a single pass over
the archive, including only those lines that are in the desired version.
This makes it essentially constant time independent of which version
is desired.  RCS keeps the last version in a "pristine" form, so
it is probably quicker for retrieving the last version.  However, the
SCCS approach is probably faster if you want a "random" version (which
of course, you only rarely do).

: ... So, RCS is more time efficient than SCCS. 

Certainly for retrieving the last version, but probably not
for retrieving a random version.

: -- Laurent

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Configuration Management for Ada on Unix

[Chris Papademetrious]

pautet@email.enst.fr (Laurent Pautet) wrote:
>Maybe I am wrong, but I think SCCS is very unefficient because it
>stores patches between Version (N+1) - Version (N) and when you want
>to access to version N, internally SCCS retrieves version 0 and
>applies all the patches to obtain version N. RCS stores the last
>version (rather than the first one) and differences between Version
>(N) - Version (N+1).

 This inefficiency has a nice advantage, though.  Let's say you have
three modifications, A, B, and C, which affect the original version of
a program.  Using the method which stores only *modifications* to the
base file, you can selectively create a version which incorporates
only the modifications A and C, while leaving out those in B.  With
the way RCS works, the changes in B are inherently a part of C, and
cannot be bypassed.

 This can be VERY handy when many people make changes often to a large
body of source files.

>-- Laurent
 
 - Chris

Re: Configuration Management for Ada on Unix

[Laurent Pautet]

Tucker Taft <stt@henning.camb.inmet.com> wrote:
>
>Certainly for retrieving the last version, but probably not
>for retrieving a random version.

A study on several large projects has shown that 95% of the time
people retrieves the last or the last but one version. After this
study, the RCS implementors chose the current model. This model has
also a major advantage when you implement branches and merge of
branches.
-- 
-- Laurent

Re: Configuration Management for Ada on Unix

[Robert Dewar]

Chris says

" This inefficiency has a nice advantage, though.  Let's say you have
three modifications, A, B, and C, which affect the original version of
a program.  Using the method which stores only *modifications* to the
base file, you can selectively create a version which incorporates
only the modifications A and C, while leaving out those in B.  With
the way RCS works, the changes in B are inherently a part of C, and
cannot be bypassed."

This makes no sense at all. Of coures you can do this with RCS. The method
in which the informatoin is stored affects only the retrieval times for
various kinds of access, not what information can be accessed. You might
claim that the operation you suggest would be slower on RCS, which is true
since RCS optimizes the (by FAR most common) process of obtaining the last
version, but since you can obtain all versions, of course you can do this
operation. Just think for a moment. If you decide that the only way of
doing your operation is to have the modification steps, then just
create them from the appropriate versions.

So what you end up saying is "this inefficiency has a nice advantage, some
things are efficient." Yes, we know this already!

Re: Configuration Management for Ada on Unix

[Laurent Pautet]

Chris Papademetrious <st92j0gw@dunx1.ocs.drexel.edu> wrote:
>
> This inefficiency has a nice advantage, though.  Let's say you have
>three modifications, A, B, and C, which affect the original version of
>a program.  Using the method which stores only *modifications* to the
>base file, you can selectively create a version which incorporates
>only the modifications A and C, while leaving out those in B.  With
>the way RCS works, the changes in B are inherently a part of C, and
>cannot be bypassed.

That's absolutely wrong. You can do it with both RCS *and* SCCS. You
didn't understand the difference between RCS and SCCS. Do : rcs -oB
and B won't exist anymore and only the difference V(C) - V(A) will be
stored.
-- 
-- Laurent

Re: Configuration Management for Ada on Unix

[James A. Squire]

This thread, more often than not, seems to have nothing to do with Ada.
I believe there is a newsgroup for config-mgmt (something like
comp.software.config-mgmt, I think).

Not to mention the fact that RCS and SCCS are more appropriately
classified as Version Control tools.  Strictly speaking they do not meet
the requirements of Configuration Management.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Configuration Management for Ada on Unix

[Bob Crispen]

Sorry, I didn't mean to start an SCCS-vs-RCS war (which is surely a
little off topic?)

I merely meant to indicate that a delta engine, WHATEVER it is, is
a significant part of a configuration management system, but by no
means the whole system; and that I have seen systems that range in
complexity from shell script front ends to the delta engine up
through extremely complex database systems with roles and the
capability of generating single lines of code on the fly, and the
whole nine yards; and that the choice of which system to use is
greatly dependent on your requirements.

Duh!  Maybe three duh!s.  But if you think you can shortcut the
engineering process of requirements analysis, trade studies, etc., etc.
for the configuration management requirements of your program and
get off easy by saying "everybody uses XYZ" -- well, tough luck.

Hey!  We may have discovered the last domain for which the waterfall
model applies -- CM.  Or has someone used a spiral model for CM
(intentionally ;-)?

Bob Crispen
revbob@eight-ball.hv.boeing.com
Speaking for myself, not my company

Re: Configuration Management for Ada on Unix

[W. Wesley Groleau (Wes)]

> ... RCS keeps the last version in a "pristine" form ...

If I read this right, RCS keeps the last version in a form that will not
choke a compiler?  If so, then is there anything else about RCS that would
prevent using the RCS directory as your "official" compilation library?
Then "normal" builds would always use the latest checked-in files, and
compilers that check file dates would not have to recompile files that had
not been checked out and in again!

The down side is that malice and/or stupidity could get in and edit the
files without check in/out.  Can't do that in SCCS unless you're clever
enough to recompute and edit the checksum.

PLUG:  A low cost CM system (and more!) that adds functionality to
either SCCS or RCS is Razor.  It is also very customizable.
Even though written in C, it is reliable and robust--and the authors
originally started it to support an Ada project.  I have no personal
interest in it, just a satisfied user.

Find out more at http://www.tower.com

--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Configuration Management for Ada on Unix

[Samuel Tardieu]

>>>>> "Wes" == Wes  <W.> writes:

>> ... RCS keeps the last version in a "pristine" form ...

Wes> If I read this right, RCS keeps the last version in a form that
Wes> will not choke a compiler?  If so, then is there anything else
Wes> about RCS that would prevent using the RCS directory as your
Wes> "official" compilation library? Then "normal" builds would always
Wes> use the latest checked-in files, and compilers that check file
Wes> dates would not have to recompile files that had not been checked
Wes> out and in again!

No, you got it wrong; writing that RCS keeps a ready-to-extract
copy of the latest version doesn't mean that there is nothing more in
a RCS file, in fact there is :) Note that this would be wonderful,
this would mean that one could store the old revisions of a file in
zero byte :)

Wes> The down side is that malice and/or stupidity could get in and
Wes> edit the files without check in/out.  Can't do that in SCCS
Wes> unless you're clever enough to recompute and edit the checksum.

You better not edit yourself a RCS file. Unix permissions will prevent
you do this inadvertently anyway (RCS files are read-only be default).

Wes> PLUG: A low cost CM system (and more!) that adds functionality to
Wes> either SCCS or RCS is Razor.  It is also very customizable. Even
Wes> though written in C, it is reliable and robust--and the authors
Wes> originally started it to support an Ada project.  I have no
Wes> personal interest in it, just a satisfied user.

PLG: A *free* CM system (and more!) that is built on top of RCS is
     CVS. You can grab it from http://www.cyclic.com/ (I think)

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Configuration Management for Ada on Unix

[Brendan WALKER]

In article <qw6u3wytapf.fsf@gargantua.enst.fr>,
Samuel Tardieu  <sam@inf.enst.fr> wrote:
>
>PLG: A *free* CM system (and more!) that is built on top of RCS is
>     CVS. You can grab it from http://www.cyclic.com/ (I think)
>

My current project (~$50M, 120 man-years) is using CVS as the basis
for our developmental configuration management, and have found it to
be very good indeed.

Note that there are 2 main advantages of using CVS over SCCS/RCS alone.

The first is that CVS allows more than one user to be modifying a
file at a time, rather then the SCCS/RCS single file lock system. This
may sound crazy at first, but it is actually very good. What CVS does is
automatically "merge" the changes made on a particular version of the
file. If any "clashes" are found (Ie, the same line is modified by
more than one user), then the last one to check-in is warned of the
clash and it must addressed before that version of the file can be
checked-in to the baseline. The power of this is that you progress
from "file" change control to "line" change control.

The second advantage is that CVS allows the creation of subsystems, which
are a logical grouping of files and directories that together make
up a subsystem. Each subsystem can be "checked out" as a whole with
a single command. Using this mechanism configuration of a large baseline
becomes more manageable, particularily when you "tag" each file in a
subsystem to correspond to (for example) a complete unit tested "release",
or an "interface release", etc. 

All this with a "free" tool...... 

PS: It shouldn't make any difference because CM is CM, but our project
is C++, not Ada :-)

Best Regards,


-- 
Brendan Walker	        | The opinions expressed above are obviously
IASSF Project, 	        | the ramblings of a troubled mind, and 
GMS S3I (Australia)     | therefore not those of my employer.

Re: Configuration Management for Ada on Unix

[Samuel Tardieu]

>>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:

James> This thread, more often than not, seems to have nothing to do
James> with Ada. I believe there is a newsgroup for config-mgmt
James> (something like comp.software.config-mgmt, I think).

It depends: since many Ada95 compilers have adopted a source-based
system, most CM tools are now available for use with Ada. It may be of
some interest for the readers of this group to get a comparison of
these tools without having to read a new group. In particular, GNAT
users may want to know that free CM tools exist, so that a complete
build system can cost nothing (although, as Robert states often, it
might be crazy to use a compiler or a CM tool without support for real
development).

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Configuration Management for Ada on Unix

[Richard A. O'Keefe]

bjw@f111.iassf.easams.com.au (Brendan WALKER) writes:
>The first is that CVS allows more than one user to be modifying a
>file at a time, rather then the SCCS/RCS single file lock system. This
>may sound crazy at first, but it is actually very good. What CVS does is
>automatically "merge" the changes made on a particular version of the
>file.

A method of merging deltas was described some years ago.
It sounded to me like a really bad idea then, and does now.
The assumption here is that changes that affect different lines are
independent.
I have never known this to be the case.

> The power of this is that you progress
>from "file" change control to "line" change control.

If this were "natural unit" change control, things might be different.
Changes to different procedures stand a chance of being independent;
changes to the same procedure are very very likely to conflict even
if they don't actually affect the same lines.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Re: Configuration Management for Ada on Unix

[David Weller]

In article <4omf1q$jaq@goanna.cs.rmit.EDU.AU>,
Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
>bjw@f111.iassf.easams.com.au (Brendan WALKER) writes:
>>The first is that CVS allows more than one user to be modifying a
>>file at a time, rather then the SCCS/RCS single file lock system. This
>>may sound crazy at first, but it is actually very good. What CVS does is
>>automatically "merge" the changes made on a particular version of the
>>file.
>
>A method of merging deltas was described some years ago.
>It sounded to me like a really bad idea then, and does now.
>The assumption here is that changes that affect different lines are
>independent.
>I have never known this to be the case.
>

I felt the same way before I started using CVS.

The real issue is how much _control_ you can have over how sources are
changed and how versions are tracked.  There is already a lot of
empirical evidence, covering hundreds of thousands of lines of code
(admittedly, most if it in C).  

The common "fear"(myth) of "merge-based" CM is that you could end up
with a change history like this:

		Module Version
			1.1
		       /   \
                      /     \
      User A changes         User B changes 
      lines 5-10	     lines 20-56
		      \     /
		       \   /
		Resulting "remerged" file
		is a mess because the changes
		from User A "hosed over" User
		B's changes.

This is actually _not_ how the system works.  In general, one user (A
or B, you choose) will notice the repository has a changed version of
the file.  The person should inspect the changes (easily done) and
determine how/if it affects their changes.  No CM system in the world
replaces programming discipline.

Further, CVS provides mechanisms to force "sequentializing" of
checkin.checkout, just like you would get with "vanilla" RCS.  Having
had several people using CVS on my project, many working with the same
packages, I can confirm that the "line oriented" approach (versus
"file locking oriented") works wonderfully.  More to the point, it is
very easy to roll a change out if there are unexpected conflicts
(we've never had that situation come up -- CVS will _force_ a user
into Merge mode if their changes conflict with any new changes in the
repository).

The "theory" that "line oriented" CM is error prone holds about as
much water as the "theory" that somebody can write more efficient code
in C than in Ada because C lets them "get close to the machine" --
it's simply a misplaced "will to believe".

>Fifty years of programming language research, and we end up with C++ ???

Fifty years of CM and people still use SCCS :-)



-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Configuration Management for Ada on Unix

[Fergus Henderson]

dweller@dfw.net (David Weller) writes:

>Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote:
>>A method of merging deltas was described some years ago.
>>It sounded to me like a really bad idea then, and does now.
>>The assumption here is that changes that affect different lines are
>>independent.
>>I have never known this to be the case.

The assumption necessary is not that strong.  The assumption used by
CVS it is that if you have a group of changes which are semantically
related to each other, and another group of changes which are
semantically related to each other, and none of the changes in the
first group changes any of the lines near lines changed by the second
group of changes, (where "near" means within a distance of about two
lines), then it is probably safe to merge these two groups of changes
based on the assumption that they are independant, subject of course to
revision by the programmer if the changes turn out to not be
independent.

>I felt the same way before I started using CVS.
>
>The real issue is how much _control_ you can have over how sources are
>changed and how versions are tracked.  There is already a lot of
>empirical evidence, covering hundreds of thousands of lines of code
>(admittedly, most if it in C).  

Well, I'll add my 2c worth.  My experience with CVS in developing a
100,000 line system over two and a half years has been extremely
positive.  This system was developed by a team initially comprising
three core developers, but other the two and a half years eleven people
have been involved in adding or modifying code.  To be honest, I can
hardly imagine how we would have coped without CVS. 

The main language we used was not C, it was Mercury, a logic/functional
language which shares some of the philosophy of Ada -- in particular it
has strong static checking.  (The system in question was in fact the
Mercury compiler, which is written in Mercury.)

>The common "fear"(myth) of "merge-based" CM is that you could end up
>with a change history like this:
>
>		Module Version
>			1.1
>		       /   \
>                      /     \
>      User A changes         User B changes 
>      lines 5-10	     lines 20-56
>		      \     /
>		       \   /
>		Resulting "remerged" file
>		is a mess because the changes
>		from User A "hosed over" User
>		B's changes.
>
>This is actually _not_ how the system works.  In general, one user (A
>or B, you choose) will notice the repository has a changed version of
>the file.  The person should inspect the changes (easily done) and
>determine how/if it affects their changes.  No CM system in the world
>replaces programming discipline.

Right.  Neither does any programming language.  However, languages with
strong static checking such as Mercury and Ada will ensure that even
when the above scenario *does* occur, the resulting inconsistency is
usually caught by the compiler.

In all my experience over the past two and a half years of using CVS on
a daily basis, as far as I can recall we have not had a single bug
caused by this sort of scenario.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Configuration Management for Ada on Unix

[James A. Squire]

Samuel Tardieu wrote:

> >>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:
>
> James> This thread, more often than not, seems to have nothing to do
> James> with Ada. I believe there is a newsgroup for config-mgmt
> James> (something like comp.software.config-mgmt, I think).

Now that I think about it, the above was a dumb suggestion, because ...
[see my next statement below]

> It depends: since many Ada95 compilers have adopted a source-based
> system, most CM tools are now available for use with Ada. It may be of

I see now the connection you were making.  I stand corrected (about this
thread being off-topic, that is).

As I also indicated in my other message, I don't think SCCS and RCS (nor
CVS having looked at it) qualify as CM tools.  They are version control
tools.  In fact CVS does not call itself CM but rather "source control".
In my neck of the woods, such tools do nothing to help an organization
achieve SEI level 2, much less 3.  That's just an example - I understand
that not everyone is bound by SEI.  But configuration management tools
provide baseline capabilities, for one thing.  With SCCS or RCS, in
order to effectively manage baselines, you have to add some kind of
extra intelligence to the tool (be it a wrapper, whatever).  Or you have
to set some hokey convention about the proper use of major and minor
version numbers on individual files.  I seem to recall using SCCS once
and there was some kind of convention built into the tool such that an
individual version was <rel>.<delta> or something like that, and if you
called your baseline "release 2", you could use a -r 2, but while that
would be certain to pick up the latest version for those files that were
still at 1.x, additional gymnastics were needed to exclude developmental
versions of the form 2.x from being included.

My point is that there was no explicit mechanism for saying, "stick
<this> version I just checked in in <that> baseline."

In the CM tool that I use, I can ask the tool directly to do just that.
That, just to give one example, is the difference between a CM tool and
what you guys have been talking about.

> these tools without having to read a new group. In particular, GNAT
> users may want to know that free [version control] tools exist, so that a

On the other hand, CM tools do cost big bucks, so I understand your
point.

I just wanted to tweak everybody on their sloppy terminology.  I'll go
away now ;-)
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Configuration Management for Ada on Unix

[Robert Dewar]

James Squire said

"My point is that there was no explicit mechanism for saying, "stick
<this> version I just checked in in <that> baseline.""

That's easy to do even with RCS, I don't see this as a limitation at all.

Re: Configuration Management for Ada on Unix

[Jim Kingdon]

> What I mean is to get the last version of a file, SCCS gets
> the first version and applies all the patches to get the last
> version. With RCS or CVS, the last version is always there.

I've done a certain amount of tweaking CVS performance, and the time
involved in applying deltas does not dominate.  The big performance
bottlenecks are (1) figuring out what files to operate on.  I would
guess that by now this has been tweaked in CVS to the point where
fairly fundamental changes (which are not out of the question) will be
needed for further improvements, and (2) getting to the point of being
ready to actually apply deltas for a particular file.  In the current
implementation, this requires way too much fork/exec and other system
calls, and could be improved a lot in relatively straightforward ways.

Incidentally, Cyclic (a CVS support company, see
http://www.cyclic.com) is starting to look at the Ada market.  If
anyone has any particular opinions they would like to share about what
the Ada community wants from configuration management, I'd be
interested in knowing them (by email please; post the message as well
if you so desire).

Re: Configuration Management for Ada on Unix

[Laurent Pautet]

Jim Kingdon <kingdon@harvey.cyclic.com> wrote:

>I've done a certain amount of tweaking CVS performance, and the time
>involved in applying deltas does not dominate.  The big performance
>bottlenecks are (1) figuring out what files to operate on.  I would
>guess that by now this has been tweaked in CVS to the point where
>fairly fundamental changes (which are not out of the question) will be
>needed for further improvements, and (2) getting to the point of being
>ready to actually apply deltas for a particular file.  In the current
>implementation, this requires way too much fork/exec and other system
>calls, and could be improved a lot in relatively straightforward ways.

Point (1). You're right this is an issue, but unfortunatly, a given
solution has always its advantages and its drawbacks, and there is no
clear difference between the different systems. At the opposite, the
difference between SCCS and RCS is so huge (1 to N) that it should be
mentionned.

Point (2). The less you have patches to apply, the less you require
fork system calls, don't you ?
-- 
-- Laurent

Re: Configuration Management for Ada on Unix

[Jim Kingdon]

> My point is that there was no explicit mechanism for saying, "stick
> <this> version I just checked in in <that> baseline."

In CVS, one way to do this would be with branches.  One branch would
be the baseline, and non-baseline changes would happen on other
branches.  It is a *big* step up from RCS or SCCS in this respect,
because of its ability to operate on an entire directory tree in one
operation.

> I just wanted to tweak everybody on their sloppy terminology.  I'll go
> away now ;-)

Unfortunately, there is no standard terminology.  From "Spectrum of
Functionality in Configuration Management Systems", CMU/SEI-90-TR-11,
http://www.sei.cmu.edu/~case/scm/tech_rep/TR11_90/1.4_TermClarification.html:

    As to what constitutes a CM system, there is no agreement. . . . But
    it should be noted that existing CM systems provide their own
    combination of functionality rather than a standard set.

Re: Configuration Management for Ada on Unix

[James A. Squire]

Robert Dewar wrote:

> James Squire said
>
> "My point is that there was no explicit mechanism for saying, "stick
> <this> version I just checked in in <that> baseline.""
>
> That's easy to do even with RCS, I don't see this as a limitation at all.

Mind telling me how?  I didn't know RCS had a construct called
"baseline".  How do you create one?
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Configuration Management for Ada on Unix

[James A. Squire]

Jim Kingdon wrote:
>
> > My point is that there was no explicit mechanism for saying, "stick
> > <this> version I just checked in in <that> baseline."
>
> In CVS, one way to do this would be with branches.  One branch would
> be the baseline, and non-baseline changes would happen on other
> branches.  It is a *big* step up from RCS or SCCS in this respect,
> because of its ability to operate on an entire directory tree in one
> operation.

Well, right there in your description - you have to use make the word
"branch" double as the word "baseline".  It seems to me that the concept
would break down, unless of course you can version control the directory
itself.  <today> you can call it a baseline.  But once I establish that
the baseline is correct, it becomes frozen.  I need to be able to
retrieve it later, plus I need to get on with the latest version - which
will mean changes right there in that same branch and directory.

> Unfortunately, there is no standard terminology.  From "Spectrum of
> Functionality in Configuration Management Systems", CMU/SEI-90-TR-11,
> http://www.sei.cmu.edu/~case/scm/tech_rep/TR11_90/1.4_TermClarification.html:
>
>     As to what constitutes a CM system, there is no agreement. . . . But
>     it should be noted that existing CM systems provide their own
>     combination of functionality rather than a standard set.

Thanks for the reference.  I'll go check it out.  I'm a little
disappointed, I would have thought someone would have defined this
better.  However, I did not make up the distinction between CM and VC,
I've seen it elsewhere.

To me, one of the aspects of a CM product should be that one of the many
objects it operates on is called "baseline" - and this should be a
separate construct apart from branches or labels or whatever.  It's
cleaner and safer.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Configuration Management for Ada on Unix

[Samuel Tardieu]

>>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:

James> Mind telling me how?  I didn't know RCS had a construct called
James> "baseline".  How do you create one?

Read the RCS man page and look for the word 'branch'.

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Configuration Management for Ada on Unix

[Ken Garlington]

James A. Squire wrote:
> 
> To me, one of the aspects of a CM product should be that one of the many
> objects it operates on is called "baseline" - and this should be a
> separate construct apart from branches or labels or whatever.  It's
> cleaner and safer.

If it's important to you, you might want to look at Product Configuration
Management System (PCMS) from SQL*Systems. It has an explicit "baseline"
construct, separate from the concept of "variants". The newer versions of
PCMS also add a "work package" concept that may be of interest.

-- 
LMTAS - "Our Brand Means Quality"

Re: Configuration Management for Ada on Unix

[John McCabe]

Ken Garlington <garlingtonke@lmtas.lmco.com> wrote:

>James A. Squire wrote:
>> 
>> To me, one of the aspects of a CM product should be that one of the many
>> objects it operates on is called "baseline" - and this should be a
>> separate construct apart from branches or labels or whatever.  It's
>> cleaner and safer.

>If it's important to you, you might want to look at Product Configuration
>Management System (PCMS) from SQL*Systems. It has an explicit "baseline"
>construct, separate from the concept of "variants". The newer versions of
>PCMS also add a "work package" concept that may be of interest.

>-- 
>LMTAS - "Our Brand Means Quality"

Another one is SCM (Source Code Manager) from UniPress. I don't know
much about it, I was just looking at a glossy today, but it might be
worth a look!

Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Configuration Management for Ada on Unix

[Simon Wright]

In article <qw67mtohuyp.fsf@gargantua.enst.fr> Samuel Tardieu <sam@inf.enst.fr> writes:

> >>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:
> 
> James> Mind telling me how?  I didn't know RCS had a construct called
> James> "baseline".  How do you create one?
> 
> Read the RCS man page and look for the word 'branch'.

Actually, I think `symbolic name' is closer.

  % rcs -nYour_Baseline_Name: RCS/* 

associates `Your_Baseline_Name' with the current latest revision of
all the files.

-- 
Simon Wright                    Work Email: simon.j.wright@gecm.com
Ferranti Naval Systems                     Voice: +44(0)1705-701778
GEC-Marconi S3I Combat Systems Division      FAX: +44(0)1705-701800

Re: Configuration Management for Ada on Unix

[James A. Squire]

Samuel Tardieu wrote:
>
> >>>>> "James" == James A Squire <m193884@CSEHP3.MDC.COM> writes:
>
> James> Mind telling me how?  I didn't know RCS had a construct called
> James> "baseline".  How do you create one?
>
> Read the RCS man page and look for the word 'branch'.

I just searched all of the rcs man pageS for the word 'baseline'.  Never
found it once.  'branch' <> 'baseline' is not only an inequality, it is
a constraint error.  Talk about chaos.

Seriously, using 'branch' as a 'baseline' is exactly the kind of kludge
that I said before I am not interested in.  I don't want to have
millions of different branches.  Moreover, what if I also want to use
branches what they were designed for, namely variants supporting
multiple platform or bug fixes to old versions?  Now I've got to come up
with an extra naming convention to distinguish traditional branches from
those that I am using to represent baselines.  Now I've got a mess.

No thanks.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Configuration Management for Ada on Unix

[James A. Squire]

Ken Garlington wrote:

> If it's important to you, you might want to look at Product Configuration
> Management System (PCMS) from SQL*Systems. It has an explicit "baseline"
> construct, separate from the concept of "variants". The newer versions of
> PCMS also add a "work package" concept that may be of interest.

Why do you think I've been chafing at calling rcs and sccs CM tools ;-)

My statement was meant to express what I expect any CM tool to do (and
what sccs, rcs, and cvs, not to mention others do not do), not solicit
advice on finding such a thing.  Sorry if I misled you.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Configuration Management for Ada on Unix

[James A. Squire]

Jim Kingdon wrote:

> > To me, one of the aspects of a CM product should be that one of the many
> > objects it operates on is called "baseline" - and this should be a
> > separate construct apart from branches or labels or whatever.  It's
> > cleaner and safer.
>
> If I recall correctly, last time the term "baseline" was discussed on
> comp.software.config-mgmt, people could not agree on what it meant.
> So I'm not sure that using that word would decrease confusion rather
> than increasing it.

I can cure that - bring Software Quality into the project, and terms
like "baseline" will get defined REAL fast, either at gunpoint or
voluntarily.  Admittedly there are different kinds of baselines and what
some of those nuances are is often up for grabs, though it has more to
do with "when" you do them than with "what" goes in them.

Actually, there is another way to clear up the confusion.  Imagine what
you would need to do to reproduce something if it got accidentally
deleted in its entirety.  All of a sudden you become motivated real
quick to figure out exactly what a baseline is and what it should
contain.

The fact that a small group of people could not agree on what something
means does not diminish the importance of that "something", nor does it
make tools like sccs, rcs, et. al. qualify as configuration management
tools.
--
James Squire
MDA Avionics Tools & Processes
ja_squire@csehp3.mdc.com
Opinions expressed here are my own and NOT my company's
"one of these days I'm going to better myself by going to Knight school"
"You'll be a web knight instead of a web page!"

Re: Configuration Management for Ada on Unix

[Robert Dewar]

James Squire says

"Seriously, using 'branch' as a 'baseline' is exactly the kind of kludge
that I said before I am not interested in.  I don't want to have
millions of different branches.  Moreover, what if I also want to use
branches what they were designed for, namely variants supporting
multiple platform or bug fixes to old versions?  Now I've got to come up
with an extra naming convention to distinguish traditional branches from
those that I am using to represent baselines.  Now I've got a mess."

I don't understand this at all. I see two different uses of this same
fundamental concept. But at the tool level it is silly to have two names
for the same thing. You can call a branch anything you want, surely we
are not spending this energy arguing just about terminology? especially
when we know that no one agrees on this terminology.

Re: Configuration Management for Ada on Unix

[David Weller]

In article <31B5E734.2582@csehp3.mdc.com>,
James A. Squire <m193884@CSEHP3.MDC.COM> wrote:
>Jim Kingdon wrote:
>
>> > To me, one of the aspects of a CM product should be that one of the many
>> > objects it operates on is called "baseline" - and this should be a
>> > separate construct apart from branches or labels or whatever.  It's
>> > cleaner and safer.
>>
>> If I recall correctly, last time the term "baseline" was discussed on
>> comp.software.config-mgmt, people could not agree on what it meant.
>> So I'm not sure that using that word would decrease confusion rather
>> than increasing it.
>
>I can cure that - bring Software Quality into the project, and terms
>like "baseline" will get defined REAL fast, either at gunpoint or
>voluntarily.  Admittedly there are different kinds of baselines and what
>some of those nuances are is often up for grabs, though it has more to
>do with "when" you do them than with "what" goes in them.
>
>Actually, there is another way to clear up the confusion.  Imagine what
>you would need to do to reproduce something if it got accidentally
>deleted in its entirety.  All of a sudden you become motivated real
>quick to figure out exactly what a baseline is and what it should
>contain.
>
>The fact that a small group of people could not agree on what something
>means does not diminish the importance of that "something", nor does it
>make tools like sccs, rcs, et. al. qualify as configuration management
>tools.


Hmm, there's a lot of suppositions here.  And this has been hashed out
MANY times by people who do CM as their profession (I don't think
denigrating them as "a small group of people" who couldn't agree on
something helps matters).  

This has been a very intersting conversation, and one that merits
further discussion on comp.software.config-mgmt.  Much to my
disappointment, I had tried to get this thread crossposted to c.l.a
and c.s.c-m, only to find that each group wanted to stay within their
own newsgroup, effectively reducing some very useful
cross-pollination.

I have set followups to c.s.c-m, and have crossposted this message to
that newsgroup.  This entire thread now has very little to do with Ada
and much to do what definitions like "baseline" are and whether
certain CM tools can or cannot support it.

ObOpinion:  CVS _does_ support baselines as well as branches.  We do
it all the time. :-)





-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Configuration Management for Ada on Unix

[Jim Kingdon]

> It seems to me that the concept would break down, unless of course you
> can version control the directory itself.

Yes, CVS can version control directories as of version 1.5 (the
so-called "death support" features).

> But once I establish that the baseline is correct, it becomes frozen.
> I need to be able to retrieve it later, plus I need to get on with the
> latest version - which will mean changes right there in that same
> branch and directory.

If that is what you want, then you just need a tag, not a branch.

> To me, one of the aspects of a CM product should be that one of the many
> objects it operates on is called "baseline" - and this should be a
> separate construct apart from branches or labels or whatever.  It's
> cleaner and safer.

If I recall correctly, last time the term "baseline" was discussed on
comp.software.config-mgmt, people could not agree on what it meant.
So I'm not sure that using that word would decrease confusion rather
than increasing it.

Re: Configuration Management for Ada on Unix

[Kevin F. Quinn]

Ken Garlington wrote:

> If it's important to you, you might want to look at Product Configuration
> Management System (PCMS) from SQL*Systems. It has an explicit "baseline"
> construct, separate from the concept of "variants". The newer versions of
> PCMS also add a "work package" concept that may be of interest.

It does have the user interface from hell, though.  The X interface is
somewhat less brain-dead, but the Forms interface is just appalling.

That said, it does the job, which counts for something ;)

Re: Configuration Management for Ada on Unix

[Ken Garlington]

Kevin F. Quinn wrote:
> 
> [PCMS] does have the user interface from hell, though.  The X interface is
> somewhat less brain-dead, but the Forms interface is just appalling.
> 
> That said, it does the job, which counts for something ;)

Actually, the user interface is quite intuitive... after you use it every day 
for about six months, that is. Sorta like Unix... :)

-- 
LMTAS - "Our Brand Means Quality"

Re: Configuration Management for Ada on Unix

[Kevin F. Quinn]

Ken Garlington wrote:

> > [PCMS] does have the user interface from hell, though. [esp. Forms]
> 
> Actually, the user interface is quite intuitive... after you use it every day
> for about six months, that is.

Heh - "Q.E.D." is the relevant phrase here, I think :)

I haven't seen anything off-the-shelf that does the whole Config. Man. job as
completely as PCMS though, and it does have a command-line interface which
saves a _lot_ of heart-ache.

[pause]

Hmm - comp.software.config-mgmt anyone? :)

Re: Configuration Management for Ada on Unix

[John & Susan Edge & Farrina Wilson]

PCMS does the job, no arguement about that. But what job and at what cost 
(including the learning curve)?

The crowd I work with are adapting a large Ada command and control system 
and are using at least three different configuration management systems 
that I know of (as a mere developer), maybe more!

It is horses for courses. Different strengths are appropriate to 
different levels of the project. 
- At the individual developer level, version control is SCCS on a day to 
day basis with lots of good tool support, easy to use for small amounts 
of code.
- Integration and build uses PCMS for many variants of many libraries of 
multiple packages only after individual development and formal reviews 
are completed. Not so easy to use, but not everybody needs to know how to 
provide CM for millions of lines of Ada.
- A non-software specific system at company level that provides CM for 
releases to customers of deliverable hardware, software, documentation, 
everything. This one requires a full time department to control.

The important thing is that this approach works well and definately 
focuses attention on defining procedures to get from one system to the 
next. Yes, there is a common understanding of what 'baseline' means.

The fact that it works, and is cost effective, doesn't mean that I don't 
miss the Ada CM of Rational APEX from my old job. You always remember 
your first love.