(No Subject)

nor the exception, I remember a response to a request for 'real' shell
access so some one could do programing on CCNs systems. The polite reply
was the CCN is not a public /computing/ resource, its a public
/information/ resource.

next message in archive
no next message in thread
previous message in archive
Index of Subjects


It is, I think, universaly agreed that some revision control system is a
good idea. However, the CSuite frontend to RCS only implements the cons of
RCS (things being slower, and opens the possibility for problems), and
none of the pros (any front end to viewing logs, or easily recovering old
versions, showing diffs of arbatrary versions....).

Your arguments for RCS seem to be twofold: first that RCS can be used to
recover files that users have screwed up, and secondly - a stronger
argument - that it can be used to recover files that the system has
screwed up. If RCS wasnet in place to screw up files then you wouldnt need
it to recover them in the frist place.

Online editing of files for anything but the most trivial of changes
should be discourged anyway. Interactive sessions consume presious system
resources, and you cant produce non-trivial HTML that is valid by hand.

On Tue, 17 Apr 2001, Tony Cianfaglione wrote:

> 
>    In summary, RCS is a valuable resource for the many who do not use ftp
> and who do not keep their own backups.  It would be difficult to
> constantly restore editor-skewed files from system nightly backups when
> we're talking only one file and not a whole directory.  For this reason,
> Userhelp has always told users (without RCS) that if they lose a file in
> their home directory, they're on their own.  The simple logistics of
> trying to find someone's lost file in the multitude of user files in a
> nightly system backup would eat up a ton of volunteer time.

I disagree. Depending on the backup system we put in place the command to
recover a file would be a oneliner. We can with the FCS doing our backups
recover files now. And if we do backups localy it would be that much
easier.

> 
>    I would prefer to see the stripping out method of removal for ftp users
> with a notice that RCS will be turned off in their particular directories 
> as of a certain date and that from that date on, they will be responsible
> for their own backups.  Blanket shutdown of RCS would be a travesty for
> the many editors still editing online (and not just IP editors but any
> system editors as well).
> 

RCS, so far as Im concerned is only hurting the system. It could be good,
but it isnt.

Rightnow, the plan is to untech the ftp server all it knows about RCS. The
major problems with RCS now are ftp and text figiting with each other via
RCS. Not having FTP know about RCS should decrese the problems.

No one has the time, or inclination , to build the CSute text front end to
RCS to make it usefull. For CSuite 2.x some revision control system 
shuold be included, but it will br provided via webdav, and the effort
will be spent polishing that. 


next message in archive
no next message in thread
previous message in archive
Index of Subjects