A client for CVS in pure tcl. - CMcC 20041015

Released tclcvs in the Half Bakery

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.com/~colin/tclcvs.tar.gz

Future Work:

1. write a tclvfs wrapper for tclcvs
2. make getting server responses asynchronous
3. abstract the metadata layer - mkvfs can store it more efficiently than in CVS/ files.
4. support commit and add
5. documentation and tests
6. :ext: server support.
7. write a more sane CVS-like facility (client and server) in tcl.

---

MGS [2006/08/24] - I'm having trouble accessing the above url (sharedtech.dyndns.org). Would it be possible to make the tarfile available for download somewhere else? Thanks.

CMcC I moved it to another server, see above link.

---

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.

<interpolation> SEH - Or just put a collate/broadcast virtual filesystem on top of the CVS VFS 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.

<digression> CMcC I love collate/broadcast, I really do, because I love composition of vfs, like Plan9 [1]. Does it add value here, though?

To explain: CVS is built on the notion of there being a local snapshot copy of the backend repository. A checkout creates the snapshot with associated metadata (held in a CVS/ subdir of each directory) an update first reports the currently held version of each file, and the client's belief as to modifications of the file - to which the server responds with any modifications which have been committed to its repository.

So the definition of CVS requires a backing store/cache for the local snapshot. Of course that backing store can be any vfs ... but isn't collate redundant in this context? </digression>

</interpolation>

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 :)"

DKF: Just noting that that's not really following the spirit of Tcl modules. They're designed that way specifically to make them easy to manage by end users. It sounds to me like you're really after doing a full package; if so, do that and ignore the whole module scheme.

Is this another CLI (command line interface) wrapper?

---