Question

Having myself found in a role of a build engineer and a systems guy I had to learn end figure out a few things – namely how to set up our infrastructure. Before I came on board they didn’t have any. With this in mind please excuse me if I ask anything that should have been obvious.

We currently have 3 level distributed mercurial repositories: level one on each of developer machines, level two on central (trunk) server – only accessible from local network and the third layer on BitBucket. Workflow is as follows:

1. Local development: developer pulls change-sets from local network server. developer commits to local and pushes to our local server once merge conflicts are resolved. A scheduled script overnight backs everything up to BitBucket.

2. Working from home: developer pulls change-sets from BitBucket. Developer comits to their local repo and push to BitBucket.

3. TeamCity picks up repo changes from local network server for each project and runs a build / automated deploy to test environment.

The issue I’m hitting is scenario 2: at the moment if someone pushes something to bitbucket it’s their responsibility to merge it back when they’re back in office. And it’s a bit of a time waster if it could be automated.

In case you’re wondering, the reason we have a central repo on local network is because it would be slow to run TeamCity builds of BitBucket repositories. Haven’t tested so it’s just an educated guess.

Anyhow, the script that is scheduled and pushes all changes from central repository on local network just runs a “hg push” for each of repositories. It would have to do a pull / merge beforehand. How do I do this right?

This is what the pull would have to use switches for:
– update after pull
– in case of merge conflicts, always take newer file
– in case of error, send an email to system administrator(s)
– anything extra?

Please feel free to share your own setup as long as it’s not vastly different to what’s described.

UPDATE: In light of recent answers I feel an important aspect if the intended approach needs to be clarified. The idea is not to force merges on our local network central repo. Instead it should resolve merge conflicts in same was as per using HgWorkbench on developer machines with post pull: update + merge. All developers have this on by default so it should be OK.

So the script / batch file on server would do the following:

1. pull from BitBucket
2. update + auto merge

3. Any merge auto conflicts?

   3.1 Yes -> Send an email to administrators to manually merge -> Break

   3.2 No -> Cary on

4. Get outgoing changesets. Will push create multiple heads? (This might be redundant because of pull / update)

   4.1 Yes -> Prompt administrators. Break.

   4.2 No -> Push changes

Hope this clears things up a bit. Now, can this be done using hg commands alone – batch – or do I have to script it? Specifically can it send emails?

Thanks.

Answer 1

So all your work is available at BitBucket, right? Why not make BitBucket (as available from anywhere) you primary repo source and dropping your local servers? You can pull changes from BitBucket with TeamCity for your nightly builds and developers whould always work with current repo at BitBucket and resolve all merging problems themselves so there wouldn’t be any subsequent merges for you.