Distributed Source Control - pushing individual changesets

Question

Working on a bit of a sticky problem and was hoping for some help from the community. Basically, our dev team is split up into two teams, lets say "Red" and "Blue"

3 repos:
1: Master
2: Red >> Clone of master
3: Blue >> Clone of master

Each developer is cloning red or blue on their local machine where they are working.

Both teams are working on various tasks for our main application. Each team has a clone of our Shared "Master" Repository on which they are applying their changesets. The changesets are verified at that level, at which point they are ready to be pushed into the Master.

To simplify, lets say developer A and B are both on Red team.

So the problem comes when developer A pushes changeset 1, then developer B pushes changeset 2. Then changeset 1 is verified and ready to go into Master but changeset 2 is not.

I want to push changeset 1 to Master as soon as possible, and not wait for verification to changeset 2, especially since changeset 3 could be being introduced in the meantime.

We're currently using mercurial and I like it - I would be willing to switch to git if the workflow for what I want to do would be easier.

Am i thinking about this wrong? I appreciate the help.

Answer 1

I'm not familiar with branching in mercurial, but here's how you'd do it in SVN - i'm sure there's an equivalent. You need to set up branches, and instead merge changesets into /trunk. This allows you to pick and choose which revisions go out, rather than just having to do "svn up" and get them all.

For example, you could have something like

/branches/dev
/trunk

In this case, /trunk is assumed to be the current stable code, which would run on production. Say you only wanted to push red team's revision 100, and blue team's revision 110. From inside /trunk, you would do:

svn merge <host>/branches/dev -r 99:100
svn merge <host>/branches/dev -r 109:110

And only the changes made in those specific revisions would be merged into /trunk.

Answer 2

• TeamA
• TeamB
• Master

When TeamA is ready to push changes, you merge TeamA into master, and when TeamB is ready, you merge TeamB into master.

Periodically down the line both TeamA & TeamB Should Fetch/Merge from Master to make sure thier versions have the latest code.

If you need more examples look at how Gitorious/Github are set up. Each developer has thier own clone of the project, then when they're ready they apply to be merged into the master repo.

This same principle can be applied to Merc, the key is making sure you fetch/merge to the Team Repos (Developer Repos) often to make sure new code is introduced to thier dev cycle.

Answer 3

In the specific case you're describing:

I want to push changeset 1 to Master as soon as possible, and not wait for verification to changeset 2, especially since changeset 3 could be being introduced in the meantime.

all you need to do is hg push -r cset1 where cset1 is the revision number or node hash of the cset you want.

When you push with -r it pushes that changes and all of its ancestors, so you can push changeset 1 without pushing changeset2, but not changeset 2 without pushing changeset 1.

If you need to push them out of order (two but not one) then you're into cherry picking with the TransplantExtension, but so long as you're going in order you've got an easy option.

(Note that to avoid the "two but not one" scenario the best plan is to have whomever wrote feature two do a hg update zero first. That way two and one will be siblings (both kids of zero) rather than parent-child, which more naturally reflects their true relationship, if indeed they are separable features. This can be done explicitly with branching, but doing it strictly with changeset parentage is a perfectly valid mode of operation too.)