next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects
Index of Subjects On Sun, 15 Apr 2001, Christopher Majka wrote: > Hi Mark et. al, > > On Sun, 15 Apr 2001, Mark Ronald Rushton wrote: > > > My best recollection is that we asked that some exploration be done for > > a method to turn RCS "off" for those who didn't need / want it. > > > > Also, my understanding is that currently directories that are created via > > FTP do not create RCS directories. > > Sadly, this is not so. I just created a directory remotely via FTP (in an > IP directory). As soon as I install (again remotely via FTP) an HTML file > - presto - the RCS directory with its *.html,v file appeared. ;-< Chris is correct. In the Tech Meeting today we were considering whether there are two distinct groups of users, i.e. those who manage their website using the text interface, and those who do everything by ftp... If there is a significant group in the latter category, and I haven't seen any statistics to verify that, and if there is not a significant overlap between the groups, then perhaps simply turning off the creation of RCS files for ftp users might work. However, and it is a BIG HOWEVER, there would be a real problem if a user does both ftp and text editing, because then the RCS files could get out of sync with the working files. Then there is a real danger of losing the latest version, as the RCS system "checks out" its stored version to be updated when editing in the IP directory. Some of you will have noticed that this often happens if you try renaming files in an RCS controlled directory. > > I believe (wrongly?) that this was a feature we endorsed as a general > > solution, the reasoning being that people who use FTP to maintain their > > sites would have an off-site backup and therefore RCS would not be > > useful to them. RCS was maintained for (I)nstall method of maintaining > > IPs. > > This would be a good approach. Would it be possible to implement RCS so > that, until such time as one attempted to edit a file via PICO, no RCS > equivalent would be created? To go beyond the simple solution of "no RCS for ftp'd files" will require a more substantial investigation of the interaction of the various parts of the system. However, that would be the only truly "safe" solution, as far as I can tell so far.. > My largere question, however, is this: I may be somewhat out of touch with > recent technical changes at the CCN, but I wondered if someone from the > tech team could summarize what RCS was currently being used for? > > My (perhaps also faulty) memory seems to indicate that: > > 1) It locks files during editing (hence no possibility of 2 editors > simultaneously editing it; Yes. This also means that if a user ftp's out their site, then it is locked until they ftp it back in. > 2) Keeps a cryptic *.html,v file recording all editing changes. Handy in > theory but in the absense of a front-end to the sytem of marginal use; Not cryptic, it's a cumulative record of changes to the file, including additions and deletions. It is formatted so that RCS's check out function and RCS's checkin function can track the changes, and re-create any version of the file. (check out sort of in the sense of a library book, for exclusive editing by one user; check in returns the record to the "repository". The version that is being worked on while you edit is not publicly viewable until you finish the edit, and check the file back in.) In a sense, then, this is a backup of the file. But you are right, there has never been any front-end built for editors to use. Would it be useful? Would something else be useful instead? > 3) Records who and when the file was last edited. Useful viz CCN recent > script, but how much does this get used? The who/when is embedded in the file, along with the "made" link, which provides the hook for Lynx's "c"omment function. I'm not sure if there are any other current browsers that use it. As some of you know, that link can be edited, and if you ftp up a file with the made link in it, the system does not change it. But the database for the "recent" function is kept separately. > 4) Anything else? The $64 question (no, Regis has made it a million, right? :) That's part of the research we need to do before just turning off the functionality, so we don't break things. > If this is all that it's doing, and its chewing up great gobs of > filespace, it hardly seems currently justified. Are most people installing > most files via FTP and making changes to the files thence (rather than > editing online)? Do we have any way of telling this? We don't currently collect/report any statistics on this. But as I said above, the critical part is the group who use both methods. > I guess if there was a clear answer to the above people could > intelligently weigh the pros and cons and decide on a course of action > accordingly. Here is your opportunity to think outside the box, brainstorm, ... come up with a better way of doing things. We don't need the technical solutions, just some ideas to explore at this stage. Ed Dyer aa146@chebucto.ns.ca Religion Page Editor, Chebucto Community Network http://www.chebucto.ns.ca
next message in archive
next message in thread
previous message in archive
previous message in thread
Index of Subjects