Josh Berkus wrote:
Folks,
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.
Brian
