Re: Versioning from another perspective
Bill Bumgarner (bbum@codefab.com)
Mon, 20 Dec 1999 17:06:53 -0500
Message-Id: <199912202206.RAA12400@bjork.codefab.com>
To: "Ben Laurie" <ben@algroup.co.uk>
Cc: ietf-dav-versioning@w3.org
Date: Mon, 20 Dec 1999 17:06:53 -0500
From: Bill Bumgarner <bbum@codefab.com>
Subject: Re: Versioning from another perspective
[This is off topic, but bears some relevance in that it addresses specific
problems with the use of CVS that I would like to solve in a clean manner with
a WebDAV based solution]
In no particular order:
- The maintainers are not interested in supporting non-concurrently
versionable resources. As such, patches to improve and/or fix the support for
either binary files (i.e. gifs and such) or "wrappers" (directories whose
contents should be treated as a single lump o' binary data) have not been
rolled back into the "master" distribution.
- The implementation of CVS-- the actual internal architecture-- is
pathetically bad. For example, the behaviour of binary files can change in
subtle ways between different operating systems and/or authentication
mechanisms. The change in behaviour may likely be invisible to the user
until corrupted files are discovered in the repository at some later date. In
particular, one subtlety is that keyword expansion ($Id$) may silently be
enabled if the cvswrappers file is in just the wrong place-- this can lead
directly to corruption of binary files.
- The same operation may change in behaviour between commands that should do
the same thing. Example; add and import both represent the same basic
operation with a slightly different tag behaviour. However, the actual
implementation is such that the behaviour for binary files and/or wrapper can
be slightly different-- again, this can also be affected by the use of local
vs. client/server [RSH] vs. pserver vs. kerberos authentication modes.
- The CVS client/server support is ugly; pserver is grossly insecure in that
it uses base64 encoded passwords to avoid sending data in clear text... but
rsh/ssh requires the user to have a full blown login account on the server
machine.
- The support for configuration maps in cvs-- the modules file-- is quite
thouroughly broken. Or maybe it isn't. Either way, I have known very few
people that have ever successfully been able to make it work correctly across
all of the common operations.
- We are perpetually finding ourselves in a situation of having to edit
various CVS administrative files to "fix" corruption of the repository or of a
workarea.
- The "wrapper" mechanism is complete junk. It is poorly supported and the
integration with the rest of the system is all over the place and completely
cryptic. As a result, CVS's support for
directories-that-should-be-treated-as-opaque-resources is really bad.
(Basically; such a directory is a directory whose contents cannot be
inventoried. Example: several desktop applications save "documents" that are
actually directories full of various random files. The contents of these
directories cannot be predicted nor can the assumption be made that an
administrative file/directory like CVS's admin directory will be preserved)
- The user interface to cvs is cryptic, inconsistent, and the source of much
confusion. There are a couple of promising GUIs around, but they break on a
regular basis as new versions of the core executable are released-- of course,
we can't use any of the core executables because the maintainers haven't rolled
a number of changes back into it.
- A cvs repository is basically useless without CVS (or RCS-- if that is even
directly supported anymore). I.e. If the repository is disconnected from CVS
through corruption or the lack of a CVS binary, it is a huge amount of work to
recover working revisions.
- CVS has no concept of a document structure. Actually, the real problem is
that CVS treats directories as nothing more than something that may be recursed
into some of the time-- with the default behaviour changing across different
commands. As such, CVS doesn't maintain information regarding the state of a
directory over time. A commit operation is generally performed against more
than one resource in a given directory or set of directories. Prior to a
commit each directory is in a particular state that is basically the
combination of the versions of all resources in a particular directory.
- The change notification / log reporting mechanisms are awful. It is
extremely complex to implement a simple notifier that will coalesce all cvs
operations related to a single, say, commit into a single, intelligently
formatted message. This is related to the previous node-- because any
operation performed against a directory is a non-atomic operation, it is
extremely difficult to perform atomic tasks against any single operation.
Tags don't cut it as tags are tied to a resource and never a collection....
- The various mechanisms via which filtering / validation / notification are
completely inconsistent. Compare the file formats of all the various random
administrative files in CVSROOT.
- There is no way to have a separate set of administrative files or
configuration per node within the repository. End result; we basically need
to maintain a totally separate repository for every single one of our
clients.... problem is; several of our client projects share part of the same
source trees (internal libraries).
- It is very difficult to prevent whitespace / newline related conflicts from
arising when moving between Unix and NT.
---
Yes-- CVS is a useful tool and it is certainly more useful than basically
anything else we have found. However, we feel very strongly that the
implementation and current feature set leave a huge amount to be desired.
There are a number of exciting projects in this space-- prcs, aegis, and
others-- but we would prefer to have a system based around standard protocol
designed to manage versioned resources. This will guarantee a maximum level of
compatibility and portability into the future as well as allowing us to
leverage off of all kinds of cool HTTP/XML based tools that are freely (and not
freely) available.
b.bum
From: Ben Laurie <ben@algroup.co.uk>
Date: 1999-12-20 21:23:11 +0000
To: bbum@codefab.com
Subject: Re: Versioning from another perspective
CC: ietf-dav-versioning@w3.org
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
Organization: A.L. Group plc
Bill Bumgarner wrote:
> In particular, it is my goal to obsolete CVS. CVS has cost myself
> and my company many many hours of frustrating maintenance effort to keep it
> working at an acceptable level. Worse, the CVS maintainers are not at all
> interested in supporting features that are necessary for the management of web
> related projects [binary files, in particular].
?? In what sense? We use CVS all the time and have near zero
maintenance.
Cheers,
Ben.
--
SECURE HOSTING AT THE BUNKER! http://www.thebunker.net/hosting.htm
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi