Thoughts on a redesigned CVS client

The CVS command line interface is riddled with problems. There are all kinds of non-orthogonality, things which should be simple but which aren't, and so on. While it may be desirable to work on some of this in an evolutionary manner, this page is about more revolutionary approaches to building a CVS client.

Some of the goals as I see them:

1. talk to an unmodified CVS server. Extending the server to better meet the needs of this client and other clients hopefully will also happen, but when talking to a server without such extensions, clients would continue to operate, in some cases with reduced functionality.
2. provide a command line interface. This is primarily for use from scripting languages, but it should also be usable interactively. Although some kind of API is probably cleaner, a command line interface is hard to match for portability to a wide variety of scripting languages.
3. provide some kind of API(s), at least for perl.

And here are some of my thoughts on specific design features:

• My thinking on command line syntax is to use something analogous to make/dd. For example, "client diff rmod=ccvs/TODO context rev1=1.3 rev2=1.6" which (probably) could also be legally given as "client rev2=1.6 rev1=1.3 context rmod=ccvs/TODO diff".
• There would be 3 basic modes. By default, the client would operate on the current working directory, and files could be specified explicitly as "file=foo.c file=foo.h". With the "mod=" argument, it would operate on a module, and also on the current working directory (analogous to "cvs get"; question: try to solve the common problem people have in terms of not figuring out to cd to top level to run "cvs get"?). With the "rmod=" argument, it would operate on a module, but not touch any working directories (analogous to "cvs rdiff", "cvs rtag", &c).
• At API level, returns a data structure. For example, "cvs log" returns a hash where keys are header names, revision numbers, &c, and then the contents have the stuff (maybe just a string for now, probably wants more thought).
• Does API level write to stdout? Probably yes, for now. Might think about callback, stream, &c, for the future. Don't want to make everything fit in memory.
• My first thought was to write the whole library in perl and provide a perl API. But now I'm starting to wonder whether writing a library in C would be a win in terms of being able to write bindings for python, tcl, &c. Performance probably isn't a big issue in this particular context, and writing in C might not gain much (you'd still need to write bindings for each language).

The status of this project? Pure vaporware. Given how busy I've been, I'm not sure I have any great optimism about whether I'll have any significant amount of time available for it. So take this with as many grains of salt as desired.

- Jim Kingdon