Tailor <trac-tailor <at> arstecnica.it> writes: > I'm not sure to understand the meaning of the proposal: would you really > wanna track a single file where the original is kept under RCS?
I saw this in your tracker and couldn't figure out how to reply there, so I'm taking this route instead. (Sorry for any inconvenience.) While RCS as such is inherently file-oriented, this does make sense. Minimal spec: treat a directory in the local file system as a "repository". Any *,v or RCS/*,v files are the repo files, and can by and large be handled the same way as CVS *,v files. Since there is no real concept of a patch set, I would even consider dropping the CVS patch-set heuristics and treat each check-in as a separate change. I don't know if it's documented, but you can give a separate parameter to `co' which indicates the path to get the ,v file from. So you can `cd /tmp/import; co -r 1.1 file /path/to/file,v' to get something very similar to cvs -d /path/to co -r 1.1 file (Also I'm wondering if you couldn't use -p and just pipe the output to your process, thus obviating the need for any storage in the local file system prior to importing the file's contents. This IMHO ought to work both for CVS and RCS. But I digress.) If you want to go advanced, you could recurse directories under /path/to and grab any *,v file you find in the tree, truncating any RCS/ directory which is the immediate parent of a *,v file -- this would already be quite useful. Yet more advanced: retrofit http://server/path/to and [ssh:[EMAIL PROTECTED]:/path/to to this backend. With this, RCS would almost be useful in its own right again (-: _______________________________________________ Tailor mailing list [email protected] http://lists.zooko.com/mailman/listinfo/tailor
