Question

We have set up our repositories with lots of branch repositories for different projects and developers, somewhat like this. (This is all one Kiln project, with 3 fictional developers Luke, Han, and Leia:

• Group: Main
  • Repo: Prod
  • Repo: Dev
    • Branch Repo: Luke
    • Branch Repo: Han
    • Branch Repo: Leia
• Group: ProjectAlpha
  • Repo: Main
    • Branch Repo: Luke
    • Branch Repo: Han
    • Branch Repo: Leia
• Group: ProjectBeta
  • Repo: Main
    • Branch Repo: Luke
    • Branch Repo: Han
    • Branch Repo: Leia

Dev pushes to Prod, ProjectAlpha and ProjectBeta are like what SVN branches used to be, and push to Dev, and each branch repo pushes to its parent.

Every developer clones only repositories named after them to their filesystem.

So Luke clones:

• Main/Luke -> %ProjectsRoot%/Dev
• ProjectAlpha/Luke -> %ProjectsRoot%/ProjectAlpha
• ProjectBeta/Luke -> %ProjectsRoot%/ProjectBeta

This is done so that we don't need to do silly things like rename a repository to get it out of the way and constantly reclone, which takes awhile, and so for some things (like build scripts) we can count on absolute file paths.

When Luke is done with code, he commits, pushes, and asks for a code review in his Luke repository before it gets pushed up the tree. Code is supposed to get pushed up closer to Prod, and pulled back down from above.

The thing we didn't anticipate is all the merging that would be required once multiple changesets start flying around.

If Leia has already pushed changesets from ProjectAlpha/Leia to ProjectAlpha/Main, and then Luke tries to push changes in ProjectAlpha/Luke to ProjectAlpha/Main, Kiln gives up.

BigProj » ProjectAlpha » Main contains some changes that are not in Luke. You will need to manually merge them to complete the push.

Ugh Now Luke needs to go to the Synchronize tool, switch the url from Luke to Main, pull those changes from Main, then switch to the repository explorer to merge the two totally unconflicting changes together, and commit that merge, then push this to Luke, and only THEN can he push to Main like he wanted to in the first place. Then he will likely need to repeat this entire procedure in order to push those changes further to Dev, and now Han will have the same problem the next time he wants to push code.

Is this right? Does it have to be this hard? What are we doing wrong? Or does Kiln have a tool in the UI that I don't know about?

If not, why can't Kiln have a feature that will automate these merge-then-pushes when there are no conflicts?

Or, is there a better way to structure our repositories that will still allow us to isolate code for reviews but with less push/pull madness?

To end, a caveat for any solution: the command line hg tools are not really an option. It was hard enough to get people to abandon SVN without taking away graphical tools - if that's what it takes, that will break the camels's back.......and I like the camel. ;-)

Answer 1

This issue is one of the reasons that my team is using named branches instead of branch repositories. With all the changesets in a single repository, even if they are on separate branches, you eliminate most of the merging nonsense you are currently dealing with. (There are lots of other benefits to named branches, in my opinion.)

Everything we do with hg on a regular basis can be done with very quick and simple operations in TortoiseHG, mostly from the explorer view.

If you go that route, you should also consider using a branch-per-feature development process.

More detail on named branches and branch-per-feature here.