Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] SCM perforce replacement

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Pieter Lenaerts <e-type AT sourcemage.org>
  • To: "sm-discuss AT lists.ibiblio.org" <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] SCM perforce replacement
  • Date: Thu, 16 Mar 2006 22:26:14 +0100

before anyone starts reading:

"I'll stop my rant if svn gets officially turned down, but it has all
features except for that it's not distributed"

see below

now, read on :)

Op do, 16-03-2006 te 15:17 +0100, schreef Arwed von Merkatz:
> Here's my incomplete list:
> - support for repeated merges between branches (devel->test, ...)

universal svn line for merging:
svn merge test@head devel@head test

> - support for cherrypicking changes on merge, this includes in-file
> cherry picking (for e.g. ChangeLog)

R=revision with "the cherry"

svn merge devel@R-1 devel@R test

> and in-tree cherry picking (integrating one spell from test to stable-rc)

svn merge stable-rc/spell@head test/spell@head stable-rc


> - support for partial submits (not submitting all changes one has in the
> local workspace)

svn submit path/to/file

> - support for file and directory renames

svn move source target

> - directory based access control

very easy with svn.

> - for distributed systems: support for push-based central repository,
> i.e. devs push their changes from their local repos to the central one

I'd like to get a conclusion on this distributed/centralized issue.

using distributed just to have a lot of backups around is stupid. you
can generate dumps on a regular basis, bz2 them and ftp them up 10
backup servers if you like, but asking that 1000 devs all have their
backup around is bad practice imo (I know...if we should get really
popular for that but it's about the principle of it)

if the central server crashes, everyone will still have their last
changes in their local repo's and will be able to merge them with the
last backup that's restored on another server.
the logs of those changes would have to be re-entered. if N changes were
submitted for a file between the crash and the last return point, those
N changes will all be in that one change

what other reasons did we have not to use centralized for the grimoire?
(not other teams)


> - scalability: our repository isn't exactly small, especially when it
> comes to directories; we have >76000 changes now, roughly 40 active
> user accounts accessing it
> - stability: we don't want major outages in the server, and the clients
> shouldn't crash too often either

--
Pieter Lenaerts
Source Mage GNU/Linux

http://www.sourcemage.org
"Linux so advanced it may well be magic"

Attachment: signature.asc
Description: Dit berichtdeel is digitaal ondertekend




Archive powered by MHonArc 2.6.24.

Top of Page