Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] scm next steps

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] scm next steps
  • Date: Wed, 24 May 2006 00:56:35 +0200

On Tue, May 23, 2006 at 05:38:03PM -0500, Jeremy Blosser wrote:
> On May 23, Jeremy Blosser [jblosser-smgl AT firinn.org] wrote:
> > I do have the git repo with the last couple years of history for devel and
> > test imported from p4, so I did some comparisons with that against the
> > history-less hg as well to test the claim that the gap would close with
> > more history. git's still running faster *with* history than hg does
> > without history; however, the operations I've tried so far aren't really
> > history-intensive, so the file size benefits of git are still primarily at
> > work. The thing is, I'm just not sure how much of what we do is really
> > going to be history-intensive beyond the raw data that git does so well
> > with. The overriding performance factor is still going to be the size and
> > composition of our tree.
>
> I should clarify that I don't yet have reason to believe that hg actually
> would be faster on history-intensive stuff either, I'm just saying that
> even if they did, I'm not sure how much it would matter for our 90% usage.
> The merges I did so far certainly don't seem to indicate that hg would be
> faster. The git crowd seems to think they should do well in that
> comparison as well, because git also does a lot of optimization around
> encoding deltas.
>
> Note that I'm also not including svk (or svn) in these benchmarks because
> there doesn't seem to be much point; a remote checkout via svk takes hours.
> Of course, performance isn't the only issue, and I primarily ran these
> benchmarks because I was surprised hg wasn't doing better. However, it's
> not a minor issue either; this is not the first time we've found that the
> composition of our tree presents a unique scalability challenge to scms.
> git's already got several patches thanks to our tree demonstrating
> bottlenecks.
>
> Nevertheless, I would like to see more people testing sections in svk. So
> far we just have video in there. We should get as much data as is
> reasonable so when we make a decision we don't have need to second guess it
> later.

I agree.
As a note about svk performance, it gets a lot better if you limit your
commands. Running svk diff or svk status on a single spell or section
makes it a magnitude faster than full branch or even full tree. Of
course there are quite some cases where you need full tree or at least
branch info, but for common spell or section maintenance, just running
the commands in (or on) the relevant directories will speed up the
normal workflow.

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page