[tpm] RFC: Which Centralized VCS[s] are you using now or in future?

[Stuart Watt]

  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 
"manager friendly".

On 7/8/2010 10:23 AM, Abram Hindle wrote:
> This is based on my experience:
> SVN
> - 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 
development platform.
> - 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 
files...

All the best
Stuart