CODEWITHSUNDEEP
mercurial
TheKeys
TheKeys

Reputation: 685

Using hg (Mercurial) for commiting to private development server without muddying history of shared repository?

I'm in the process of trying to improve our development process using Mercurial and private development servers but need some advice on best practice in our situation.

Now, I want each developer to be able to do development work, see the results on their private development server and when happy with a block to be able to push that up to the centralized repository with a nice commit message. This will then be tested on a staging server and then on to live.

How though should each developer share the changes they've made on their windows machine through their IDE with their own development machine. I have tried setting up a SAMBA share on the dev machines but over a remote connection it is painfully slow.

I've been told I should be using Mercurial for this part of the process also. However, if every developer commits every change to their local repo and then pushed this to their private dev server when it comes to pushing changes to the centralized repository we'll have huge volumes of very minor commits. This will dilute the quality of commit messages e.g. "added missing }", "fixed typo x", or missing commit messages altogether etc.

I've looked at verious hg extensions regarding consolidating commit history but believe I'm going to run into problems as commits will exist on 2 repos (the dev machine and the dev server) and removing commits from one of them seems like it will cause issues on the next push.

How do I use Mercurial to acheive this goal of continuous development / commits to a development server whilst not muddying the history of the shared repository?

Upvotes: 3

Views: 383

Answers (2)

Laurens Holst
Laurens Holst

Reputation: 21056

I don’t see the problem with those kind of granular commits that you mention. Why introduce a complicated workflow for the sake of a "cleaner history"? Granular commits also have many advantages, such as that the flow of changes is easier to understand and code review, and you can easily cherry-pick fixes that is are also useful for others.

If your developers enter a clear description of the work done in the merge commits when pushing to the main repository, then you can follow a relatively clean line of development by just following the merges on the main branch and ignoring all developer branches. And if you need more detail, e.g. because you want to code review or debug a particular issue, you can dive into the branch.

Re. empty commit messages, Mercurial will refuse to check in missing commit messages, and if your colleagues try to bypass that by entering "." or "-" then you should probably scold them ;p. Or add an incoming hook that blocks those if they’re really stubborn.

Upvotes: 1

Andrew
Andrew

Reputation: 14447

It looks like you want the Rebase feature with --collapse. This allows you to squash a branch into a single commit. Have a look at the RebaseExtension documentation, especially looking at the functionality of --collapse.

Upvotes: 3

Related Questions