Re: GNOME DVCS Survey Results

[Max Kanat-Alexander <mkanat bugzilla org>]

	So, I'm not a GNOME contributor, but I am the author of VCI, a
Perl module that interacts with version control systems (currently CVS,
Svn, Hg, Git, and Bzr), and so I wanted to chime in a bit on this
thread.

	The first thing to understand is that the git server protocol
is very simple. When I was writing VCI, I talked to the git developers
and asked if they were going to add any more features to the server.
They said no, it's only supposed to allow you to clone from it, and
that adding any other features would increase the attack surface (a
particularly valid concern when writing servers in C).

	Now, I am a very definite bzr user, so that should be kept in
mind, but I also have a lot of experience with various VCSes, so I do
have somewhat of an objective viewpoint.

On Mon, 5 Jan 2009 07:00:52 -0700 "Elijah Newren" <newren gmail com>
wrote:
> * As James H. mentioned on John's blog, you'd likely end up with "the
> intersection of the features of the two version control systems rather
> than improving things."

	For most operations, no, that's not true. git does not do any
actual operations over the wire, it does all of its operations on your
local repository, so you wouldn't lose any git functionality, there.

> * John's bridge would have to be updated whenever either the bzr or
> git formats changed

	Unless he uses bzrlib or calls the bzr/git binaries directly,
which I imagine he would?

> * It would introduce extra lag between when new features become
> available, since the bridge would need to be updated for each such
> change.

	Well, there will be no new features in the git server. git
never works remotely, it always works locally. So that wouldn't be a
problem there.

> * I believe bzr proponents even admit that bzr is still slow for
> network operations.

	It depends. It's more of a latency thing currently than
anything else. With a low-latency connection, I find it just as fast as
Git or Hg. And I haven't personally experienced the low-latency thing
recently, just heard reports.


	One question that should also be considered in this whole
discussion is--what sysadmin is going to maintain the server? If you
can't get anybody who will actually *maintain* a Git repository (I mean,
you can point out tools or talk about it, but...) for the next 10 years
or so, then it'd be pretty hard to move to it. That includes
maintaining all the integration around the repository. Remember that
Git really has no API, you just run the commands and get the output.
*Subversion* actually had the best API when I was writing VCI, FWIW.
Git and CVS had the worst API, in terms of integration. There may be
better modules available now, though--I wrote VCI in 2007.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.