A client for [CVS] in pure tcl. - [CMcC] 20041015

The intention is to embed this in other applications, rather than support it as a stand-alone application.  In particular, a [cvsvfs] will be written to provide a [virtual filesystem] which keeps itself in sync with a CVS repository.

At the moment, it only supports :pserver: read access, sufficient to '''checkout''' a module from a repository, and '''update''' it ... so it can be used to keep a directory hierarchy up-to-date with a cvs server.

The snapshot can be downloaded here: http://sharedtech.dyndns.org/~colin/tclcvs.tar.gz

'''Future Work''':

   1. write a [tclvfs] wrapper for tclcvs
   2. support '''commit''' and '''add'''
   3. documentation and tests
   4. :ext: server support.

----
'''Note''': CVS is a horrible, horrible protocol.  The justification for implementing it is its omnipresence.  It should be possible, with this code, to implement self-updating packages.

15oct04 [jcw] - Wow.  Do you see any potential issues with tying a slow CVS access to VFS?  In other words, do you expect VFS to work ok with high latencies and timeout failures, or will VFS itself need further work to get to that stage?

[CMcC] I think I'd consider two modes, one where you'd start a checkout or update only on initial mount) and the other where you update per open.  I don't think it'll be *too* bad if your network connection is reasonably fast.

I would also consider using fileevent to make the interactions asynchronous, but I'm not sure whether blocking inside a file operation won't block the rest of the interpreter anyway.

Certainly async (if it is possible) would hide a lot of the latency.

Another thing to consider is that update bandwidth is rougly proportional to the size of the changes, so once you've checked out something you only pay for the diffs.