Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] SCM perforce replacement was: Re: Grimoire Team Lead vote

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>
  • To: "sm-discuss AT lists.ibiblio.org" <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] SCM perforce replacement was: Re: Grimoire Team Lead vote
  • Date: Mon, 20 Mar 2006 13:00:57 -0600

Catching up on this thread...

On Mar 15, Pieter Lenaerts [e-type AT sourcemage.org] wrote:
> Op wo, 15-03-2006 te 09:32 -0800, schreef Andrew:
> > svn is still centralized, in other words, theres still "the
> > svn server". So that wouldn't fix one of perforce's major downsides, which
> > is that when the server goes down, we're stuck. We can still edit files
> > (as with p4) but cant submit, share easily, etc. I for one am really
> > nervous about having all our revision history on a central server. Yes,
> > we do have our own changelogs for mostly everything. And yes, we have good
> > backups on our web-machine and Im sure the sys-admins in the group will
> > make sure things are disaster-resistent. But it still makes me nervous.
>
> I think this is of course a good reason to go for distributed forced
> with a central repository. The main concern then becomes the size of the
> repositories imo. Can we somehow get an estimate on the size of the
> grimoires + their history? I'm a bit afraid that this would put a
> serious burden on diskspace for gurus, but I don't know just how big it
> would be...

Assuming we'd be putting this on the existing server(s) we have, and given
that I'm one of the ones admining those, I'll note that I'm not that
concerned about the issue of how the SCM wants to do distribution.
Anything can be made to have redundancy (even p4, frankly). It's all just
data, the only real issue is how long it takes to execute the failover
plan. Some systems can't fail over without a fair amount of downtime that
may be unacceptable for a 24x7 commerce application, but for us a bit of
lag to failover isn't that big of a deal.

I understand paranoia but it'd be silly to reject an SCM because it doesn't
let us be ultra-paranoid and have a fully-functional repository copy at
every development node unless we need that for other development purposes.

Anyway, don't get tied up in second-guessing how and where the backend does
storage, the front end usability issues are a lot more important for
developers, and we have plenty to worry about there. I've made even CVS do
some ridiculous things on the backend, I'm not that worried here. I prefer
filesystem-backed SCMs over DB-backed ones because it makes it easier to do
all manner of extra stuff when necessary, but I'm not going to be the one
to make an issue over that either, developer acceptance on the front end is
much more important.

A couple of other notes:

We should stick with one SCM for the whole project. As noted before, the
bar to entry for developers to do work shouldn't be figuring out our SCM
processes, it's just not worth it. At our size we can't afford to be so
picky about having $PERFECT_SCM for each component. The project is not the
SCM, the project is the developers and the values of the SC.

Please keep in mind the main issue right now is the Grimoire Lead vote.
The SCM issue is obviously important to a lot of you... pay attention to
how the candidates are approaching this issue if it matters to you and take
that into account when you vote.

Attachment: pgpT0k3tQaN8N.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page