Josh Berkus wrote:


You are way ahead of us here. And my vote *still* goes to Mercurial, if
we're picking SCMs.

Will a new SCM actually make this easier, or are people just using it as an excuse?

We use mercurial here at work, having switched to it recently, and while I don't claim to be an expert, it does seem nice. For example, you can have a local repository you're checking code into, and can pull from and merge up with some shared repository. Also, you can pull from one repository and check into another- so, for example, we have a staging repository and a compiles repository (unless you welcome the pain)- you pull from the compiles repository, but push changes back to the staging repository. Then we have a script that pulls recent changes from the staging repository, make sure they compile and the unit tests run, before moving them over to the compiles repository. This way, the version you're pulling at least compiles and passes some minimal unit tests.

A similiar process could work for postgres- except instead of "staging" and "compiles" you'd have a "sumbitted" and "accepted" repositories. And instead of a compile daemon, it'd be reviewers who would move code from one to the other. Note that everything I'm talking about here is not unique to Mercurial- you can do this just about as easily in darcs or git (I'd advise against Bazaar/bzr)- so don't take this as being pro-Mercurial, just pro-SCM.


Reply via email to