Re: Feature Freeze date for 8.4

Brian Hurt <bhurt@janestcapital.com>

From: Brian Hurt <bhurt@janestcapital.com>
To: josh@agliodbs.com
Cc: pgsql-hackers@postgresql.org
Date: 2007-10-24T12:57:42Z
Lists: pgsql-hackers
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