Slime project considering Mercurial

Paul Franz theandromedan at
Fri Mar 7 12:04:27 CST 2008

John D. Mitchell wrote:
> On Fri, Mar 7, 2008 at 3:46 AM, Paul Franz <theandromedan at> wrote:
> [...]
>>  So the local India developers would pull from the local gate repository
> Yes.
> And from each other, if they please.  I.e., remember that Hg is a
> distributed SCM. :-)
>>  but push to the one in the US, correct?
> That's up to you and how your development process works.
> For example, they could have a local *outgoing* repository. Or, you
> might treat the remote folks as non-committers and have them send
> their patches to a committer.
> For outsourcing-ish relationships, I'd have a them have a shared,
> local, incoming repository (mostly likely on a per-project basis) that
> they have periodically pull from a designated corporate-side repo;
> along with a shared, local, outgoing repo (most likely on a
> per-project basis) that they push their proposed changes to.  On the
> corporate-side, I'd then have the internal technical team responsible
> for e.g., each project, have a repository that they pull the changes
> from the outsourced group's outgoing repo (and then vet the changes,
> run tests, etc. before integrating that with the corporate repos.
> Hope this helps,
> John
Kinda. The current process is based-on ClearCase. And one of the things 
the ClearCase enforces is that when you commit a change to the repository:

1) It must be the HEAD/tip of the branch. If it is not, then you need to 
merge your changes to the HEAD/tip, resolve any conflicts and then commit
2) There is no gatekeeper. The developers are responsible for running 
tests and making sure things do not break. If they do break things, it 
will be noticed on the first build after the checkins (there are builds 
once a day that take 6 hours to run) then the offending person will be 
contacted and told to fix the problem.

This is process that I want to keep in place for the moment.

BTW, these are all internal developers, so in theory that should be 

Paul Franz

More information about the Mercurial mailing list