🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.groupware
Article #242

Re: Distributed authorship

#242
From: Neal Baker
Date: Fri, 24 Aug 1990 13:46
279 lines
9057 bytes
I am in a team which has exactly the requirments of a joint authoring package 
as you, and we find that 'rcs' under unix is adequate.  We hold our central
master files on a server and each work on our own copies on individual
workstations.  When an update is complt5ete we check the file back to the 
server, an action overseen by rcs.  Rcs will maintain a tree structure of
versions, any historical version or lineage can be retrieved.

Remote file access (rfa) allows the workstations each to mount the remote
server disk so that it appears as part of the workstation's directory
structure.  The version of unix that we use is Hewlett Packard's HP-UX v7.0
but I don't know whether rcs is provided by other vendors.  The manual entry
for rcs follows.

Neal Baker
Hewlett Packard Laboratories
Filton Road
Bristol, England
ngb@hplb.hp.co.uk

_________________________________________________________________________

     RCS(1)							RCS(1)




     NAME
	  rcs - change RCS file attributes

     SYNOPSIS
	  rcs [ options ] file ...

     DESCRIPTION
	  Rcs creates new RCS files or changes attributes of existing
	  ones.  An RCS file contains multiple revisions of text, an
	  access list, a change log, descriptive text, and some
	  control attributes.  For rcs to work, the caller's login
	  name must be on the access list, except if the access list
	  is empty, if the caller is the owner of the file or the
	  superuser, or if the -i option is present.

	  The caller of the command must have read/write permission
	  for the directory containing the RCS file and read
	  permission for the RCS file itself.  Rcs creates a semaphore
	  file in the same directory as the RCS file to prevent
	  simultaneous update.	For changes, rcs always creates a new
	  file.  On successful completion, rcs deletes the old one and
	  renames the new one.	This strategy makes links to RCS files
	  useless.

	  Files ending in ",v" are RCS files, all others are working
	  files. If a working file is given, rcs tries to find the
	  corresponding RCS file first in directory ./RCS and then in
	  the current directory, as explained in rcsintro(5).

	Options
	  -alogins	 Appends the login names appearing in the
			 comma-separated list logins to the access
			 list of the RCS file.

	  -Aoldfile	 Appends the access list of oldfile to the
			 access list of the RCS file.

	  -cstring	 Sets the comment leader to string.  The
			 comment leader is printed before every log
			 message line generated by the keyword $Log$
			 during check out (see co(1)).	This is useful
			 for programming languages without multi-line
			 comments.  During rcs -i or initial ci(1),
			 the comment leader is guessed from the suffix
			 of the working file.

	  -e[logins]	 Erases the login names appearing in the
			 comma-separated list logins from the access
			 list of the RCS file.	If logins is omitted,
			 the entire access list is erased.




     Hewlett-Packard Company	   - 1 -  HP-UX Release 7.0: Sept 1989






     RCS(1)							RCS(1)




	  -i		 Creates and initializes a new RCS file, but
			 does not deposit any revision.  If the RCS
			 file has no path prefix, rcs tries to place
			 it first into the subdirectory ./RCS, and
			 then into the current directory.  If the RCS
			 file already exists, an error message is
			 printed.

	  -l[rev]	 Locks the revision with number rev.  If a
			 branch is given, the latest revision on that
			 branch is locked.  If rev is omitted, the
			 latest revision on the trunk is locked.
			 Locking prevents overlapping changes.	A lock
			 is removed with ci(1) or rcs -u (see below).

	  -L		 Sets locking to strict.  Strict locking means
			 that the owner of an RCS file is not exempt
			 from locking for check in.  This option
			 should be used for files that are shared.

	  -nname[:[rev]] Associates the symbolic name name with the
			 branch or revision rev. Rcs prints an error
			 message if name is already associated with
			 another number.  If rev is omitted, the
			 symbolic name is associated with the latest
			 revision on the trunk.  If :rev is omitted,
			 the symbolic name is deleted.

	  -Nname[:[rev]] Same as -n, except that it overrides a
			 previous assignment of name.

	  -orange	 Deletes ("obsoletes") the revisions given by
			 range.  A range consisting of a single
			 revision number means that revision.  A range
			 consisting of a branch number means the
			 latest revision on that branch.  A range of
			 the form rev1-rev2 means revisions rev1 to
			 rev2 on the same branch, -rev means from the
			 beginning of the branch containing rev up to
			 and including rev, and rev- means from
			 revision rev to the head of the branch
			 containing rev.  None of the outdated
			 revisions may have branches or locks.

	  -q		 Quiet mode; diagnostics are not printed.

	  -sstate[:rev]  Sets the state attribute of the revision rev
			 to state. If rev is omitted, the latest
			 revision on the trunk is assumed.  If rev is
			 a branch number, the latest revision on that
			 branch is assumed.  Any identifier is



     Hewlett-Packard Company	   - 2 -  HP-UX Release 7.0: Sept 1989






     RCS(1)							RCS(1)




			 acceptable for state.	A useful set of states
			 is Exp (for experimental), Stab (for stable),
			 and Rel (for released).  By default, ci(1)
			 sets the state of a revision to Exp.

	  -t[txtfile]	 Writes descriptive text into the RCS file
			 (deletes the existing text).  If txtfile is
			 omitted, rcs prompts the user for text
			 supplied from the standard input, terminated
			 with a line containing a single "." or
			 control-D.  Otherwise, the descriptive text
			 is copied from the file txtfile.  If the -i
			 option is present, descriptive text is
			 requested even if -t is not given.  The
			 prompt is suppressed if the standard input is
			 not a terminal.

	  -u[rev]	 Unlocks the revision with number rev.	If a
			 branch is given, the latest revision on that
			 branch is unlocked.  If rev is omitted, the
			 latest lock held by the caller is removed.
			 Normally, only the locker of a revision may
			 unlock it.  Somebody else unlocking a
			 revision breaks the lock. This causes a mail
			 message to be sent to the original locker.
			 The message contains a commentary solicited
			 from the breaker.  The commentary is
			 terminated with a line containing a single
			 "." or control-D.

	  -U		 Sets locking to non-strict.  Non-strict
			 locking means that the owner of a file need
			 not lock a revision for check in. This option
			 should NOT be used for files that are shared.
			 The default (-L or -U) is determined by your
			 system administrator.

	Access Control Lists (ACLs)
	  Do not add optional ACL entries to an RCS file, because they
	  are deleted when the file is updated.  The resulting access
	  modes for the new file might not be as desired.

     DIAGNOSTICS
	  The RCS filename and the revisions outdated are written to
	  the diagnostic output.  The exit status always refers to the
	  last RCS file operated upon, and is 0 if the operation was
	  successful, 1 if unsuccessful.

     EXAMPLES
	  The command:




     Hewlett-Packard Company	   - 3 -  HP-UX Release 7.0: Sept 1989






     RCS(1)							RCS(1)




	       rcs -ajane,mary,dave,jeff vision

	  adds the names jane, mary, dave, and jeff to the access list
	  of the RCS file vision,v.

	  The command:

	       rcs -c'tab*' vision

	  sets the comment leader to tab* for the file vision.

	  The command:

	       rcs -Nsso/6_0:38.1 vision

	  associates the symbolic name sso/6_0, with revision 38.1 of
	  the file vision.

	  The command:

	       rcs -l38.1 vision,v

	  locks revision 38.1 of the file vision,v so that only the
	  locker is permitted to check in (see ci(1)) the next
	  revision of the file.  This command prevents two or more
	  people from simultaneously revising the same file and
	  inadvertently overwriting each other's work.

     AUTHOR
	  Rcs was developed by Walter F. Tichy, Purdue University,
	  West Lafayette, IN 47907.
	  Revision Number:  3.0; Release Date: 83/05/11.
	  Copyright 1982 by Walter F. Tichy.

     SEE ALSO
	  co(1), ci(1), rcsdiff(1), rcsintro(5), rcsmerge(1), rlog(1),
	  rcsfile(4), acl(5).

















     Hewlett-Packard Company	   - 4 -  HP-UX Release 7.0: Sept 1989
Technical Details
Message-ID: <20040001@otter.hpl.hp.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!ngb
References: <PATERRA.90Aug23170244@raedwald.cs.odu.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!ngb
From: ngb@otter.hpl.hp.com (Neal Baker)
Newsgroups: comp.groupware
Subject: Re: Distributed authorship
Message-ID: <20040001@otter.hpl.hp.com>
Date: 24 Aug 90 13:46:07 GMT
References: <PATERRA.90Aug23170244@raedwald.cs.odu.edu>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 279