?

Log in

No account? Create an account

Tower of Babel, The Source Control Management Vendors don't get it...

« previous entry | next entry »
Oct. 24th, 2007 | 11:10 am

During my career I've used seven source control management systems. RCS, CVS, Subversion, Bitkeeper, Mecurial, Continuous, and one other I have forgotten the name of.

To date I've lost code to all of them. One of them cost me an entire year's worth of work once (and refuse I to use it any longer for this reason, though I think the developers are fine people).

I believe there is an opportunity in the source control world today if someone looks beyond the proprietary nature of all of the tools built today.

What is the proprietary piece to these tools which I am alluding to?

It is the protocol. Each of these systems are tied as client and server.

I want a really good, robust, and feature rich server. I want web interfaces, I want the ability to search, and I want interoperability.

I don't really care if one developer likes subversion and another likes Bitkeeper. They can use whatever tools they want to for their work. If they want distributed, let them use a tool that allows them to do that. If they want to commit to the main server on each commit, let them use subversion. I want the server to track change sets with as much information as the client can provide.

The server is the value to me as someone who administers projects and code trees. As a developer I want to use the best tools possible.

I've thought for a while now that the database vendors never got, whether on purpose or not, the concept of inter-opt-ability. ODBC is just plain awful. It misses the point that I as someone who is shipping an application do not want to deal with drivers, and I do not want my users to have to deal with them either (the either is the key part). If the database vendors had a been a bit wiser they would have shared a protocol, similar to how browsers share HTTP, and competed on the value of their servers. Less lock in obviously, which of course is why this would never happen (though I do not rule this out for the future).

Are the open source and closed source revision control management systems only interested in user lock in? I've tried having this conversation with a few of the SCM vendors to only walk away being surprised at how much they could not get over the idea that clients other then their own could talk to their systems. The Bazaar community seem to be the only group sniffing around this problem.

The separation of client from server projects seems to be a real hurdle for developers to get over.

Link | Leave a comment | Share

Comments {7}

Jamie McCarthy

(no subject)

from: jamiemccarthy
date: Oct. 24th, 2007 07:34 pm (UTC)
Link

"If the database vendors had a been a bit wiser they would have shared a protocol, similar to how browsers share HTTP"

Heh, instead we have DBSlayer... http://open.blogs.nytimes.com/2007/07/25/introducing-dbslayer/

Reply | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Oct. 25th, 2007 07:23 am (UTC)
Link

Do you think of that as a database abstractor to use different databases or just a means to avoid SQL, or simplify it?

Reply | Parent | Thread

Lover of Ideas

(no subject)

from: omnifarious
date: Oct. 24th, 2007 07:54 pm (UTC)
Link

That's an interesting view. I believe that WebDAV is such an attempt. I should look into it more, but my initial feeling is that it is very cluttered and overdesigned.


The protocol of Mercurial is pretty well documented and has remained largely static over time. But it is very geared towards Mercurial's particular view of the world.

Reply | Thread

Brian "Krow" Aker

(no subject)

from: krow
date: Oct. 25th, 2007 07:21 am (UTC)
Link

Webdav is just a transport medium though. You have to have some sort of "this is the message" and then a way to negotiate what will be saved.

Reply | Parent | Thread

(Deleted comment)

Brian "Krow" Aker

(no subject)

from: krow
date: Oct. 25th, 2007 03:13 pm (UTC)
Link

Hi!

Shared libraries are good, I completely agree with you on this. ODBC though still requires driver configuration and I have not seen that many setups that gets this right.

Why not skip the entire process though? Using a shared transport certainly has not hurt the web.

I agree, not all databases are networked, but what I am referring to is client server databases (which are SQL). As far as network services go I suspect that there are common paradigms here (aka discovery, routing, proxy...). With an open protocol you would still see multiple client libraries. Some would do more then others, but all would be able to talk to the server.

Reply | Parent | Thread

Ted Tso

(no subject)

from: tytso
date: Oct. 27th, 2007 05:56 am (UTC)
Link

The problem with interoperability is lowest common denominator. You can do things in Bitkeeper that can't even be expressed via the SVN client interface. And how merging works between BitKeeper, Mercurial, Git, and SVN are so different that I just don't think it's possible. Simply dealing with the fundamentally distributed nature of BK, Git, and Mercurial which don't have an architectural notion of a single central server distinguishes them fundamentally from other SCM's. How would you even begin?

Reply | Thread