Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: Subversion vs other source control systems
From: Upayavira <uv@odoko.co.uk>
To: general@incubator.apache.org
In-Reply-To: <47BAB4CB.70608@Stolsvik.com>
References: <NBBBJGEAGJAKLIDBKJOPGEOICKAD.noel@devtech.com>
	 <A7B1BC35-87C7-483A-B5F2-4E5483197707@leosimons.com>
	 <1203291270.27742.56.camel@marlow>
	 <5c902b9e0802171724i36696280r882b7d9bd98f554c@mail.gmail.com>
	 <1203360481.23493.78.camel@marlow>
	 <5c902b9e0802181719n601b2406ne567f1c91dd40233@mail.gmail.com>
	 <47BAB4CB.70608@Stolsvik.com>
Content-Type: text/plain; charset=utf-8
Date: Tue, 19 Feb 2008 19:54:27 +0000
Message-Id: <1203450867.6994.35.camel@urgyen>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit


On Tue, 2008-02-19 at 11:51 +0100, Endre Stølsvik wrote:
> Justin Erenkrantz wrote:
> > On Feb 18, 2008 10:48 AM, Santiago Gala <sgala@apache.org> wrote:
> >> outright FUD? Sorry but I don't think there is Fear, Uncertainty or
> >> Doubt in this thread. There are several testimonies of good experiences
> > 
> > I feel there has been lots of FUD and if you don't realize that, then
> > I recommend taking a step back.
> 
> Please define FUD for us, will you? Because I haven't seen one single 
> iota of FUD on this thread - it has stayed strangely on topic, with good 
> arguments from both sides, and not once has the discussion gone into 
> "SCM XYZ often ruins the code base by introducing strange bit 
> errors"-style "half-lies" which is what I associate with FUD.
>    A/k/a "The Microsoft Tactics" in regards to Linux.

I'm not going to argue whether there specifically is "FUD", but there is
_serious_ underestimation of what it takes to roll out something as
crucial as source control within an organisation the size of Apache, and
with a repository the size of Apache.

Justin put it very well in a related thread elsewhere (permission
sought):

                           - o -

"The JAMES PMC knows that if they want to run on apache.org, they have
to handle *all* of the list traffic - not just their list.  So far,
they've not made a request to do so.  In some cases, it doesn't have
to be total conversion - for example, in infra, we're very hopeful
that we can run Harmony in some cases where we run Java - but Harmony
is not yet capable of running Confluence, so we can't switch over.
But, for a SCM, it *must* be on a path towards total conversion -
nothing less is acceptable, IMO.  We will *not* have a fractured
repository system like FreeBSD or Perl.

"If a PMC asked to run their own individual SCMs, they'd simply be
turned down.  If we switch our SCM to anything else, *everything* must
switch over.  IMO, at this point, we simply do not have anything other
than a few people who may have used git a few times - but we certainly
don't have any folks who appear willing to step up and realistically
and soberly consider what it means to change *everything* over.
Compare and contrast our experience with Subversion and let that
*truly* sink in if you're even a bit flippant about what it means to
switch.  Converting from CVS to Subversion took *years* to accomplish
and it took a *lot* of us getting deep inside the SVN community and
codebase to make sure it'd work for us.  Converting to something else
would take a realistically long time as well with a concomitant set of
expectations that folks will actively improve the tool to meet our
requirements.  So far, all I'm seeing is a few people saying, "It'd be
nice if someone else converts the ASF to git."  Those comments are
completely irrational and misguided as to how we work.  If you're so
bent on getting us on another SCM, then join the infrastructure list
and start proving that it's better than SVN.

"FWIW, git and mercurial (mercurial is *far* better than git in my
experience; it's not even close, to be honest) do not scale well to
*really* *really* large repositories.  If you look at KDE's trial
migration to git (which Joe and myself and others are watching
closely), they are separating every KDE deliverable into a separate
git repository.  (That is, every KDE library gets its own git
repository - so kdelibs and kdedesktop are treated separately.)  KDE
is explicitly willing to lose history when they move things between
repositories.  I'm frankly not sure that we'd find that acceptable.
Mercurial has sketched out a concept of 'forests' (of related
repositories), but again they're not thinking in terms of anything
other than an individual codebase - certainly not 25GB+ and across 60+
TLPs.  And, AFAICT, the concept of 'forests' is sketchy and not a part
of the core Mercurial codebase (think svn:externals and you've got an
idea how they implemented 'forests').  Again, with those SCMs, they're
perfectly willing to sacrifice history as it moves across those small
repositories as cross-project history is not something they care to
support."

                          - o -

Now, that, in my impression, puts the situation very well. If we were to
switch to git, or anything else, there would be huge issues involved,
and would be probably years of work to manage the transition. If that is
what is generally wanted, then we need volunteers who will put
themselves behind the task. No small feat. I have seen such changes
happen at Apache - they can, but the issues involved from an
infrastructure point of view are invariably an order of magnitude (if
not two orders) harder than those you see on one's own, typically
smaller, installations.

Regards, Upayavira
 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org