Log in

No account? Create an account

Why Non-Distributed Systems Suck

« previous entry | next entry »
Feb. 1st, 2008 | 12:56 pm

I have a patch that I just emailed to an upstream committer.

The main repository is in Subversion.

Now I want to work on a second patch.

What to do?

Toss my current patch out, revert, and work on another patch.

If this was a distributed system?

I would just commit locally. I would then work on a new patch. When the patch was committed to the main system I would just pick it up with a pull. I would never notice the issue because the remote patch would come in and be merged locally.

And what about the process where I work on a patch in pieces and commit along the way?

Well you can forget about that with a non-distributed system.

The solution to my problem? It looks like Fedora has SVK packages. With those I should be able to get around all the limitations for the remote server being Subversion.

What do I want?

The remote server to be Mercurial (or any other modern system...).

If you go back a decade I adored CVS. Compared to the options at the time it was a winner.

Today? Not so much.

Link | Leave a comment |

Comments {10}

Ted Tso

(no subject)

from: tytso
date: Feb. 6th, 2008 05:15 am (UTC)

But *how* the merge is done is dependent on the data storage model of the DSCM, and Bzr, Hg, and git all have different data storage models. So if the merge is done locally, then the "universal client" by definition needs to understand every DSCM's data storage model, and the merge algorithm used by each DSCM. In particular, BitKeeper, Bzr, and git use *different* merge algorithms, all different from the simple, stupid 3-way merge.

So how would you unify the different merge algorithms in your "universal client". People are already innovating in the client-side merge algorithms, and people like Larry McVoy will tell you that this is one of the most important parts of BitKeeper. You could have a least-common-denominator "universal client", but it wouldn't be able to handle directory renames, for example. And if you try to do a superset of features, and different DSCM's store the information differently, it effectively means that the universal client need to implement the union of all DSCM's clients.

If your goal is you're tired of needing to learn 3 or more different DSCM's, then it's really more about UI integration than anything else, and it maybe it wouldn't be hard to have a front-end shim in front of git, bzr, and hg so that as long as the developer only need to use the least common demoinator features. That wouldn't be hard to do, and it's far easier than trying to design the theoretical universal client.

Reply | Parent | Thread