Privacy and Security Notice

Archived Messages for EGN_CALCOM_1996@cebaf.gov: Re: checking files out locked (fwd)

Re: checking files out locked (fwd)

James Muguira (muguira@clas01.cebaf.gov)
Tue, 23 Apr 1996 15:21:30 -0400 (EDT)

Sorry - I ment to forward this to all...

---------- Forwarded message ----------
Date: Tue, 23 Apr 1996 15:19:04 -0400 (EDT)
From: James Muguira <muguira@clas01>
To: Thih-Yuen Tung <tung@cebaf.gov>
Subject: Re: checking files out locked

On Tue, 23 Apr 1996, Thih-Yuen Tung wrote:

> Date: Tue, 23 Apr 96 14:14:32 EDT
> From: Thih-Yuen Tung <tung@cebaf.gov>
> To: James Muguira <muguira@clas01>
> Subject: Re: checking files out locked
>
> Hi,
>
> I think rcs is not 100% secure.
>
> (a) One can break the lock anyway.
> (b) one can orange it.

I'm not sure what orange means in this contexted but I guess this is ok!

Yes rcs is not very secure. We have the directory permissions such that
anybody can do anything they want to the code trees at any time.

>
> I have two more questions about the code management. Do we have a version
> number strategy, like when to has branch like 1.2.1.1 when to update to 1.4
> or even to 2.1.

We should not be using branches off the main tree (like 1.2.1.1)! The
whole package (recsis, gsim, ...) should be promoted as a whole. In this
case many new features have "grown" into recsis so I'm trying to promote
it (the whole package) to v2.0.

>
> The document that I am looking at there are ways to create symbol to bind
> different versions into a release. I thought it is a neat idea, why arn't
> we using it.

I tried using just symbols to manage our trees. I found symbols to not be
robust enough (these are a new addition to rcs). I think it would be better
to promote the entire package at periodic points in time. Version numbers
seem to operate as the manual says.

What we really need is a file that lists the filenames and versions of each
file that goes into a release. The file contents are checked in and out of
rcs just like source code. The file contents are used by the make system to
compile and link modules together (currently, all files *.f & *.c in the
source dir for a package are built together in a very brain dead way).
One implication of this scheme is that we have and audit trail of needed
modules in a library/program. Another implication: we would know
immedately when a new source file is added to a package.

>
> By the way, I looked at your web pages. I think it's getting better.
> --

Thank You TY - more work needs to be done here - I'll get the example
programs done this week!

> T.-Y
>