labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <>
Subject Re: Lab for distributed SCM?
Date Fri, 22 Feb 2008 19:35:30 GMT

El vie, 22-02-2008 a las 09:32 -0800, Roy T. Fielding escribió:
> On Feb 21, 2008, at 10:53 PM, Mike Heath wrote:
> > I have to respectfully disagree with Roy.  I understand a lot of his
> > points but I don't see how today's dSCM tools and the Apache Way are
> > mutually exclusive.  Yes, dSCM facilitates the "Linux Way" but dSCM  
> > does
> > not mandate a decentralized process.  There are a lot of features
> > available in today's dSCM tools that are completely orthogonal to any
> > particular open source philosophy.
> Well, if you could come up with those features and experiment with them
> in a meaningful way, then I have no objection to using a Lab for that.
> What I don't want to see is a pocket full of advocacy for isolated
> development -- just because the tools make it easier doesn't make it  
> good.

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.

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. 

> 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

> ....Roy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
Santiago Gala

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

View raw message