I've been giving some thought to VCS lately. I have no happy news to report I'm afraid. I've looked at several that I know of, trying to decide which of them is the best of those which are available, etc. Let me first say that perforce and bitkeeper began in this comparison with about two and a half strikes against them because of their non-free nature. Neither managed to so completely and overwhelmingly impress me that I was able to look beyond that fatal aspect.
The other contenders:
Subversion
I must say that I really wanted to like subversion. It has traces of
CVS in its design because it's developed by people who worked on CVS.
It seems like it would be the least of a paradigm shift for us to adopt,
though we'd probably have to relearn several things anyway.
Subversion is not without its failings though. First, it depends on
Apache 2. We're using Apache anyway, but Apache 2 isn't out yet. While
I have installed sid on vickery, I have done so only because I cannot
with clear mind install potato on any machine, and because most of us
are pretty well familiar with Debian sid.
Currently with CVS, everyone is making their commits to trunk. This
does seem in the short run to be simpler, but in the long run it is
clear that lack of branched development is slowing down the project as a
whole. The best way to handle this is probably to limit commits to
trunk to a few people and have the larger group work out of branches.
Subversion does not allow this to be done as a matter of policy. I
think each of us who has ever worked with branches in CVS has made the
mistake at least once and committed something intended for a branch to
the trunk. It's a very common mistake for people who have not worked
with CVS branching much.
And despite CVSgui (WinCVS) being best described by all as a smelly
flaming turd, it is far more convenient for win32 users than opening up
a dos box for command line CVS. MacOS Classic users don't even have
that option, they must use CVSgui. Subversion is command line only at
this time, making it a great burden for our win32 developers, and if we
plan to support MacOS Classic in the future, we can't use it.
arch
I wanted to like arch even more than Subversion. It was designed to
make itself work with your existing development tools, particularly with
grep and diff for people with unix-style environments at their disposal.
It was also designed to maintain local copies of revision histories and
the like, so that you are not crippled if something happens to the main
server. An arch repository is as easy to mirror as an ftp mirror and
you are able to have and use more than one repository for a project with
many branches each.
The author of arch is very proud of his decentralized approach, and with
good reason. It truly does allow for several branches to be used, as
well as many servers. It is reasonably simple to set up local
repositories in which you can have changes that don't work yet (we all
know that committing stuff that doesn't work yet is a good way to get a
lot of people rather annoyed rather quickly..) and you can later merge
those changes, with history, with anyone else's servers before even
getting near the trunk. He is also proud that unlike Subversion, arch
does not depend on a bunch of untrusted, unreleased tools.
Unfortunately, his avoidance of dependencies is where arch falls short
of our needs. While arch comes with tools for the kind of web interface
we get with ViewCVS, its remote server mechanism is ftp. I don't like
or trust ftp, it's a glaring security risk. Secure ftp is nice where it
is supported, but it's not supported everywhere. Also, subversion was
developed with portability to unix systems in mind, not anywhere else.
Not only does it only provide command line tools, they are written in
sh, sed, and awk! Win32 support is possible, probably only with cygwin
though, since I happen to know how poorly those tools have been ported
by others to make win32 feel unixy. MacOS Classic? Forget it.
As cool as arch is, without a C implementation and perhaps some https
server implementation, I'm somewhat reluctant to even consider it for
our work. I'm sure it could probably be ported to C with libpcre. It
could certainly be implemented in perl, but perl is only marginally more
useful on our non-POSIX platforms than sh/sed/awk are. We're also in a
bit of a hurry.
CVS
We all know CVS at least a little. It's by far the most portable, and
likely also the most annoying. Diffs are a requirement for anyone
without write access to the trunk because they cannot make and store
local branches and revisions. If the central server goes down, all of
us are stalled until it comes back up again. Mirroring a repository is
possible if the repository is made mirrorable, but once mirrored it is
difficult to merge changes back in. It requires direct repository
access to move files or directories, and then it doesn't work smoothly.
Many people have tried to replace CVS. Some of the most successful
attempts are non-free. Others are not portable or not mature, But in
large, CVS remains the dominant version control system because despite
all its faults, it is the most widely supported, most portable, and most
understood tool out there. Someday subversion may change that. In unix
circles, arch may as well. But for now, love it or hate it (and most of
us DO hate it), CVS is still the only tool that we can really use.
I'd appreciate comments, and if someone wants to forward my comments to
the makers and maintainers of these and other VCS projects. It'd take us
months of development to replace CVS with something more suited to our
needs, and then twice as long again to make it usable on those gooeys like
win32 and Mac classic, and longer still to test everything to an extent
that we'd dare trust our code to it. That's a lot of time we just don't
have, and for the most part our team's experties lies in solving other
kinds of problems anyway.
We must, unfortunately, leave developing the next generation version
control system in the hands of those who have the skill and desire to work
in that field, and just have to hope that solutions they find will work
for us.
--
Joseph Carter <[EMAIL PROTECTED]> Hey, that's MY freak show!
<james> but, then I used an Atari, I was more likely to win the lottery in
ten countries simultaneously than get accelerated X
msg00896/pgp00000.pgp
Description: PGP signature
