labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Lab for distributed SCM?
Date Fri, 22 Feb 2008 20:55:54 GMT
On Feb 22, 2008, at 11:35 AM, Santiago Gala wrote:
> I had a number of responses to your comments in previous emails about
> the distributed tools forcing isolated behavior, which you can  
> imagine I
> disagree with, but I think it makes no sense to keep on with this kind
> of discussion. I would just repeat a mantra about forks that I  
> heard (to
> Sam?): the easiest you make forking, the most difficult is for it to
> happen. The same, I think, applies to distribution here: the  
> easiest to
> move patches around, the more they will "come" to the central point.

Umm, no, patches are text files.  I think you mean the easier it is to
identify and apply patches, the more likely they won't be lost or left

> The fact that people finds easier to do a clean checkouts to work on
> different features, commit and delete, does not ask necessarily for
> different work flows. For instance, I used to have two different svn
> checkouts for this kind of split between small fixes and a longer term
> "feature". Keeping the changes synced to both was mostly tedious.
> Most patches I keep from gajim, which is a project I track "from the
> outside", have been sent upstream and not accepted, for one reason or
> the other. I got a lot accepted, but sometimes people does not have  
> the
> same perception that I have, or just the same configuration. I *run*
> the tools (a python jabber client) hours a day with those patches, so
> I'm confident that they work. What should I do? trust them and throw
> the patches away to get a less functional version? What I'm doing now
> is keeping quilt and merging the patches every time I update svn from
> them. I'm migrating to use git for that task after I tested git-svn  
> import
> with the repository.

That is isolated development.  If you participate within the project,
instead of outside it, then the presence of everyone's private tree
makes it very hard for anyone to know what has been accepted, let alone
test with the same configuration, plan for the same features, and
generally help each other out with the small stuff.  What happens next
is that the trees become their own distributions, just like Debian and
Ubuntu and Redhat are not actually based on Linus' tree.

>> Likewise, if you intend to analyze the parts of gSCM systems that  
>> don't
>> scale in the hope of finding fixes/workarounds, then by all means  
>> do so.
> As an example of the kind of experiments I think we can do here:  
> today I
> did a (couple of) git-svn "clone" of incubator/shindig. It is much
> smaller than a clean svn checkout, *while having full history*. It is
> way faster to process because it is smaller. It is faster to process
> because the depth of the history is much smaller than the whole ASF
> tree, etc:
> $ du -sh shindig git-shindig*
> 6,7M	shindig
> 2,9M	git-shindig  <- read only, http
> 2,9M	git-shindig2 <- can commit to svn, https
> I can navigate and search the whole history, fast, etc.
> Obviously git-svn is not a mature tool, git-svn has problems (or I am
> stupid enough to blow it and make it fail silently), and even more
> problems appear because there are impedance mismatches between the
> stores of both tools. Also, fame is git is not exactly well supported
> under windows. Not that I care for myself, I have not used windows  
> in a
> number of years, but this is a problem for everything except
> experimental usage.
>> Just don't assume that the folks who built Subversion (or people like
>> me,
>> who just did a lot of research on gSEE back in the 90s) are somehow
>> unaware of the advantages/disadvantages of dSCM.
> Cool, I would ask you in exchange to don't assume that tools that are
> used to manage several of the most dynamic projects in the world (the
> linux kernel is one such) with a lot of success, and tools used by
> companies such as Redhat or Ubuntu for a number of years are used  
> out of
> masochism.

Dude, I already have Hg installed, watched Linus' rant the week
it was posted, and was well aware of bitkeeper, TeamWare, DARCS, and
several other long-abandoned dSCM tools years ago (I tried to install
git, but at the time it didn't work on anything but Linux).  Most of
the dSCM legacy came directly or indirectly out of Solaris engineering's
tool groups and ex-Sun employees, which is one of the reasons they are
so friggin incapable of collaborating on even the simplest of tasks.

When you get to the part where you look at the storage formats and see
the trade-offs that have been deliberately chosen to benefit isolated
development at the cost of consensus development, then you will
understand where I am coming from.  If you can fix that trade-off
without failing both models, then you'll have bettered both Linus
and the Subversion team.  I'm not saying its impossible -- I am just
saying it is naive to think that the trade-offs weren't chosen
for a good reason.

Good luck,


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message