Josh Berkus wrote:<br /><blockquote cite="mid200710231551.14349.josh@agliodbs.com" type="cite"><pre wrap="">Folks,
</pre><blockquote type="cite"><pre wrap="">You are way ahead of us here. And my vote *still* goes to Mercurial, if
we're picking SCMs. </pre></blockquote><pre wrap="">
Will a new SCM actually make this easier, or are people just using it as an
excuse?
</pre></blockquote> 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
andmerge 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
compilesrepository, but push changes back to the staging repository. Then we have a script that pulls recent changes
fromthe 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.<br /><br /> A
similiarprocess 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.
<br/><br /> Note that everything I'm talking about here is not unique to Mercurial- you can do this just about as
easilyin darcs or git (I'd advise against Bazaar/bzr)- so don't take this as being pro-Mercurial, just pro-SCM.<br
/><br/> Brian<br /><br />