Version 7 of pure tcl cvs client

Updated 2004-10-15 20:57:50 by SEH

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. make getting server responses asynchronous
  3. support commit and add
  4. documentation and tests
  5. :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?

15oct04 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.

<break in> SEH - Or just put a collate/broadcast virtual filesystem on top of this one and use the "collect" feature to designate a local directory as a cache. Then you just have to delete part or all of the cache directory and update from cvs will be automatic. </break in>

I would also consider using fileevent to make the interactions asynchronous (it'd be trivial to do), 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.

Thinking about it some more: there are already http tclvfs systems using the pure tcl http client so the tclvfs package can operate with a network backend.


"I implemented tclcvs because I was pissed off with tcl modules having to be distributed as 1 file ... they will be, a script which cvs-downloads the rest :)"