labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Subject: Re: Lab for distributed SCM?
Date Sat, 23 Feb 2008 05:39:17 GMT
On Fri, Feb 22, 2008 at 5:46 PM, Joe Schaefer <joe_schaefer@yahoo.com>
wrote:

> Stefano Mazzocchi wrote:
> >
> > Paul Querna wrote:
>
> > > If there is another significant purpose of this
> > > proposed lab, please tell me.
> > >
> > > But based on the original proposal, I believe that
> > > there isn't a need for a Lab.
> >
> > Paul, thanks for expressing your concerns clearly,
> > it does indeed help
> > in evaluating the situation better.
> >
> > Even after your well thought-out points, I still
> > find myself thinking
> > that collecting information, solutions,
> > state-of-the-art and general
> > practices about the difference between centralized
> > version control and
> > distributed
>
> That's already going on, at KDE.  For those of you
> who don't know, KDE has a larger svn repository than
> we do and is currently undergoing actual work to
> convert to git.  KDE's karma model is much like
> our own, except there once you get commit, you get
> it everywhere (aka the Henri model).  They're busily
> deciding how to convert that community into a
> collection of Benevolent Dictators and Lieutenants,
> because that's the way git works best.  git hardly
> works at all at scale with a large project doing
> consensus based development (it's push support sucks
> compared to svn).
>
> People doing actual work are far better at conducting
> research than those who do little more than evangelize
> their own weltanshauung.  Which is why the
> infrastructure team has tried to push this duscussion
> onto an infrastructure list and been rebuffed at each
> turn, due largely IMO to human reactance (nobody talks
> to the policemen when their "freedoms" are being
> trampled on).
>
> If people want to experiment with using git-svn or
> svk or anything else, and there's something about
> our infrastructure which prevents that, you need
> only talk to infrastructure about it to see if it
> can be resolved.  In most cases it can, rather easily.
> But the experimentation should be carried out in
> our projects where developers can evaluate
> the effects of their own tool choices on their
> peers, and listen to what their peers actually say.
>
>
+1

Mozilla has been going through the same steps and ended up with Mercurial.
The problem with Git is its very poor support for Windows (which probably
doesn't bother the KDE people) and as you mentioned the clunky push model.
On the other hand, both Mercurial and Bazaar have fairly good push support
and a decent server implementation (Mercurial is fastcgi and Python). I
don't know enough about Darcs to really say something (except that it's
Haskell, therefore it must be correct ;-) )

As for the process, to get back to everything that has been said before,
gSCMs don't force you to use a distributed models. They're just more
flexible, allowing for different styles of collaborations. You can very well
operate on a centralized development process using them. I've been using
Mercurial just like I used SVN for a while now. AFAIK Mozilla is doing just
the same. And the tool is so much better.

OpenSolaris is failing with Git but I'm not sure it's fair to put the fault
on gSCMs, it's Sun's management that's at fault. OpenOffice has similar
issues with CVS. For that matter there are quite a few scripts on SVN to
maintain vendor branches (aka forks).

Cheers,
Matthieu



>
>
>
>  ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.
> http://tools.search.yahoo.com/newsearch/category.php?category=shopping
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: labs-unsubscribe@labs.apache.org
> For additional commands, e-mail: labs-help@labs.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message