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: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • 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: Wed, 15 Mar 2006 09:32:31 -0800

On Wed, Mar 15, 2006 at 12:57:15PM +0100, Pieter Lenaerts wrote:
>
> please fire away with good arguments, so no "svn is crap", but "svn is
> crap because..." :)
>

:-)

I'll bite. 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.

As for distributed scm's, that of course cant be a problem since the
client is heavy, the server is just http/ftp/sftp/etc. Theres a lot of
redundancy for free. Some distributed scm's suport centralized development
fairly well too, with the option of switching a working tree to commit
to another location or locally. I think that would be ideal for
us. If the server goes down, we can just setup something else ad-hoc
without much overhead. The downside to distributed scms has been
usability, but some may have matured over the past year to the point
where that isnt a problem.

I think theres enough advantages with distributed scms that we should
pursue them, and like it or not, thats where most of the open-source
community is putting their efforts. Theres been dozens of (distributed)
scm's that have come out in the past year, almost all of whom can do
merging better than subversion. It's disappointing that such a key
feature is on the back-burner for svn.

--- onto alternatives

Bzr is pretty nice, looking at the competition it's definitly at the
front of the pack right now. I was following their development for a
while but stepped away for a while. The main issues I found with it
boiled down to lack of a remote submits. They seem to at least have a
push command now which might be enough to eliminate that issue. The only
other thing that comes to mind is support for cherry-picking, but thats
probably not an insurmountable issue.

Having read their ML for a while, they definitly put a lot of thought
into keeping the interface simple and not overcomplicating things. They
also put a lot of thought into design and keeping the design simple,
refactoring where necessary. They have however gotten hung up on
details users dont care as much about, such as how data gets stored. An
active development community is definitly something I think is important
criterion. If this is something we want to pursue I can help re-evaluate
it (I may use it with sorcery if my issues with it are fixed).

Svk, another distributed scm, is pretty nice too. It is probably the
closest thing to perforce I've seen. Over-generalizing, its perforce
with the option to be distributed. Thats very neat of course, because it
requires the least amount of change on our part. Downsides as mentioned
are stability, slowness due to poor/over use of perl modules, and
confusion because it uses svn as a backend versioned-fs (people often
ask if they can just use svn). Supposedly they're working on cleaning
up the issues with perl modules.

-Andrew


--
_________________________________________________________________________
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page