On his ``better SCM'' website, Schlomi Fish has decided to opine his reasons why Meta-CVS belongs in the category of ``nice try, but...''.
Here is the full original text:
I don't view attempts to keep CVS alive very optimistically. CVS is merely a group of scripts over RCS, that is very limited in what it can do, and so provide little room for improvement. Projects like Subversion aim to provide everythin CVS has and more, while requiring an upgrade of the server. I believe upgrading the servers is not such an issue that one has to try and create clients that overcome the servers' inherent deficiencies.
Another downside to Meta-CVS is that it is written in Common LISP. Granted, Common LISP is a very powerful and flexible language. However, it is not very common (pardon the pun) on UNIX and other systems, and few people could be expected to install a client if they need to install it first. If Meta-CVS' author wishes to make it more popular, I strongly advise him to re-implement it in C, Perl, Python or something more standard.
My responses:
Meta-CVS provides a sophisticated CVS client ...
This is wrong; Meta-CVS is not a CVS client; it's software that is built around the CVS client. Meta-CVS can't do anything with normal CVS projects; it stores its own data representation in a CVS repository.
The problem ... is that all the developers on your projects would have to use the Meta-CVS clients on their machines.
This is not a ``problem'' at all when one realizes that Meta-CVS is a version control system in its own right built on top of the CVS platform, and not a CVS client. Nowhere in the Meta-CVS documentation are claims made that CVS and Meta-CVS can be used interchangeably to work with the same project. It's completely unrealistic to expect that CVS can be extended to do the things that Meta-CVS does while remaining forward and backward compatible, whether or not the development work is done within the CVS codebase or as an external layer.
CVS is merely a group of scripts over RCS...
This was certainly true of the first version of CVS which was published in
1986. However, modern CVS does not work by invoking RCS, and contains a lot of
functionality which cannot be obtained by any combination of calls to RCS. The
cvs command is a binary executable compiled from C sources, not a
group of scripts. The algorithms to operate on RCS files, perform merging and
so on are integrated into CVS. CVS is not unique among version control systems
in its use of the RCS storage format. Some limitations of CVS are directly
linked to its dependency on the RCS storage format, but not all.
Meta-CVS does not repair the lack of atomic commits in CVS.
Meta-CVS is not the appropriate place for implementing atomic commits. One of the self-imposed constraints of the Meta-CVS project is that it shall not require any modifications to CVS at all. There is a good reason not to touch the CVS code; namely that it's quite well debugged and it's written in a fragile, error-prone programming language.
When CVS gets atomic commits, it will continue to work underneath Meta-CVS exactly as before.
Incidentally, I proposed a realistic, low-risk design for adding atomic commits to CVS, and it is being pursued by one of the CVS maintainers. We could see an ``atomic CVS'' in the not-too-distant future.
Update: The CVSNT project has added atomic commits to CVS. This work has not been merged to the mainstream CVS but there it is.
Another downside to Meta-CVS is that it is written in Common LISP.
Lisp is what has enabled me to write Meta-CVS. I had the ideas for Meta-CVS in my head before I learned this language. I did not write Meta-CVS then, despite being an expert C and C++ programmer, and reasonably well acquainted with Perl. I made an abortive attempt to write it in C++, but quickly scrapped that. So Meta-CVS was essentially once a project in search of a programming language. That search ended when I ``discovered'' Common Lisp, but the realization that it was the ideal implementation language for Meta-CVS only came after months of learning Lisp. When I look at the essential elements that constitute the Lisp source code of Meta-CVS, and how they rely on the language, it does not surprise me that I could not find the motivation to write in C++. To get the same behaviors out of C++, I would have to write mountains of irrelevant code which does nothing more than badly re-implement half of the semantics of Lisp. (The reader is invited to do a web search for ``Greenspun's Tenth Law of Programming'').
Regardless of what computing platform you write for, you can ``teach'' it to ``understand'' whatever programming language you want. Users don't care what programming language you used as long as the software works, and they don't have to know that programming language in order to use it. Of course, if you prefer a very rare and unusual programming language, or are targetting an obscure platform, you may have to write your own implementation of the language of choice, or compromise your preference by choosing another language.
With Common Lisp you don't run into this problem, at least on mainstream platforms, because there are many great implementations, both proprietary and free. It's easy to package a Lisp program for distribution, so that it can be installed and used by people that don't know Lisp. Just include your software and all of the necessary runtime support in a binary package.
If I had to target an embedded system for which no Common Lisp implementation is available, I would have to reconsider my preference. But Meta-CVS isn't embedded software. I care about running on Windows and UNIX.
Although no knowledge of Lisp is required to install or use Meta-CVS, its users can expect to occasionally interact with a text file containing data stored in Lisp form. The structure of this data is so obvious as to be largely self-explanatory. Lisp is absolutely the best markup language for structured data, so I would use it for storing data even in software that is not written in Lisp. PRCS is a version control system written in C++, yet uses Lisp notation to store its data in files. The well-known Rational Rose CASE tool for designing object-oriented software stores models in a format called ``Petal'', which is closely based on Lisp. The IMAP4 protocol by which millions of people access their e-mail boxes also uses a Lisp-like notation.
[R]e-implement it in C, Perl, Python or something more standard.
Of these three languages, only C has an ANSI/ISO standard. Common Lisp is an ANSI language. In fact it was the first object-oriented language to have an ANSI standard. I suspect that Fish uses the term ``standard'' to mean ``commonly installed by distributions of Linux'' or ``popular with the recent crop of Computer Science undergraduates''.
In conclusion, all that really needs to be said is this: there is currently but one program which enhances CVS in the way that Meta-CVS does, and its author produced it with Lisp. A non-producer cannot prescribe to the producer by which causes he ought to have produced the effects of his success.