Fri 17 Feb 2012 01:26:22 PM UTC, original submission:
A new project has been registered at Savannah
This project account will remain inactive until a site admin approves or discards the registration.
Registration Administration
While this item will be useful to track the registration process, approving or discarding the registration must be done using the specific Group Administration page, accessible only to site administrators, effectively logged as site administrators (superuser):
Registration Details
- Name: Condor Framework Specification
- System Name: cfs
- Type: Official GNU software
- License: GNU General Public License v3 or later (Condor Framework Specification "CFS" Copyright 2012 Joseph Pesco )
Description:
CFS is a very lite development enviroment run off the command line, and intentionally uses only the most primative tools as building blocks. CFS does not seek to be a GUI application when it grows up! Revision control is the first pillar of CFS. Also central to CFS is the concept of a the Gufee: a Gross Unique File Exchange Entity. Gross because every file in the CFS tree should have a Gufee, Unique because each file should have it's own unique Gufee, Exchange, because the Gufee is used to track the movement of files (and concepts) as they progress through the development process. The third pillar of CFS is an Incarnation. An, incarnation string kept as a directory, currently located as /opt/cfs/incarnation=< Incarnation String >, contains roughly the following infromation. <Operating system>.<physcial platform>.<Boot Storage Device>.<Installation Date of the Operation System>. Incarnations can be seen at use in the checkin process where each checkin comment is signed by the user with a string comprised of <User's log in name>.<Incarnation String>.<date of check in>. The Gufee is stored in the CFS header information at the top of each file and in rcs describtion in the rcs archive file.
Other Comments:
Dear Sirs;
There are two distinct installation types for CFS. The first is known as a Continuity installation. Root creates a user account known as continuity, and before the Continuity tarball, example provided (though not in the continuity configuration!) the previous continuity user's home directory is DELETED! and the contents of tarball replaces the continuity user's home directory. Continuity is intended as a Cloud Shell Account with the proper implementation. If a network is not available for transport of the Continuity archive file, a flash drive does nicely as a mechanism for transport between two physical machines.
The second configuration, an example provided in this tarball, is a user account directory labeled cfs. I suggest unpacking the tarball into a newly created user account (because the source is not the least bit mature.)
This will install cfs, modify .bashrc, and create ~/bin:
> cd $HOME/projects/cfs/utility
>./install_cfs.sh
Exit the shell, start a new shell, go to a directory create a RCS directory:
>new_file sample.sh
>co sample.sh
Congradulations you've just created your first cfs complient script file.
I have a to do list that includes a proper specification for a fully developed interface. A central rcs repository rather than a clutter of RCS directories is left as a trivial exersize. (I use: /opt/cfs/repository, though sometimes having the clutter of RCS directories has advantages.)
The installation script is called cfs/utility/install_cfs_II.sh, and creating the Incarnation string is very important and fell out of the script, so you'll have to mkdir -p /opt/cfs/incarnation=<incarnation script>.
I left install_cfs.sh in place in case anyone wants to see first effort. I have primative snapshots implemented though haven't included them here.
Mr. Joseph Pesco
(a.k.a. condor)
351 East 74 Street
New York, NY 10021
(646)709-7468
-unavailable-
condorlockandsafe.tripod.com
Tarball URL:
http://savannah.gnu.org/submissions_uploads/Continuity.021712.tgz
|