[tpm] RFC: Which Centralized VCS[s] are you using now or in future?
stuart at morungos.com
Thu Jul 8 07:52:18 PDT 2010
I know you don't want a contest, but Subversion is not as bad as
described, really. I've used it for 7 years, our team used it for three
now, and we have never had a real problem.
Having said what follows, starting today, I probably would use Git. The
command names are not easy to grasp, but merging for complex
non-hierarchically organized projects does appear to be very
significantly better than Subversion. For a well-structured single
project, though, Subversion is fine, stable, relatively efficient, and
very widely supported. There are many good clients, some of which are
On 7/8/2010 10:23 AM, Abram Hindle wrote:
> This is based on my experience:
> - perl enough
> - works fine in emacs
> - works fine in eclipse
> - Not very simple, has stupid URLs
They're not so bad - if you use HTTP/HTTPS, which almost everyone does,
as the Apache plugins are far the easiest way to handle a centralised
repository. (Our URLs are, like: http://svn.mydomain.com/svn/myproject).
You can run a builtin server with its own protocol, which is marginally
lighter in bandwidth, but Apache does make it easy to integrate into a
> - Works over HTTP
> - more flexible than CVS in terms of sharing a repo but still annoying
> to setup
> - Braindead heavyweight branching, it so bad that people worry about
> costs of using the feature
Branching is not heavyweight. An alias is made and subsequent deltas. A
branch of 100Mb of stuff takes less than a second. Believe me, we do
that a lot. The repository does not grow significantly for a branch.
> - Awful backend formats that are hard to fix and easy to corrupt
I've never had a single backend corruption in 7 years of running
Subversion. It's relatively easy to wedge a (local) working copy,
especially if you accidentally delete one of its hidden folders, or,
worse, copy a folder using the file system forgetting not to copy the
.svn crap. Then you may need to wipe the working copy and check out again.
(Obviously, someone as technically paranoid as I am does backups by
using the textual delta dump tool for safety; you can simply back up the
repository, but for the same reason I back up database data in text, I
do the same with Subversion. The backup file produced is textual and
contains all the deltas, so it is possible to edit the repository, and
rebuild it from this, if you really want to delete some stuff, for
example -- this is rare enough I have done it only 2-3 times ever.)
> - Random NFS glitches depending on your backend format
NFS is not always a good bet for file locks, but this would be bad for
any VCS. If you don't use file shares for the repository, not a problem.
An old/broken NFS could explain corrupted data. The safest centralized
way is *definitely* local file system access to the web server with the
Apache Subversion modules, and HTTP/HTTPS access from there.
> - Very little benefit over CVS
Far better handling of deleting and merging. Very good support for
binary files. (e.g., Word and Excel files are supported fine, and
changes are made as deltas even for binary files, so small edits are
handled well). HTTP/HTTPS support -- seriously, you need this to enable
access for off-site work, CVS ports are often blocked in wifi zones.
> - Commit tracking
The other thing I like about Apache access is that it has nice user
control systems. For example, I can allow some users read access to
parts of the system, and stop others tagging stuff. Believe me, with
some of our developers, it can be nice to stop them changing certain
All the best
More information about the toronto-pm