Question

My company is switching to Mercurial and considering using Kiln. We're coming from Subversion.

We're noticing that we're having to do a LOT of merging in our workflow. For instance, if I change a file, commit, pull, update, push, and then my co-worker changes a file, commits, pulls, and updates, he gets a "crosses branches" error and has to do an hg merge. We're having to do this pretty much every single time we want to push to our central repository.

Is something wrong with our workflow?? It seems wrong that in our history for a given file there are going to be a ton of history entries that say "Merging with [changeset id]" "Merging with [changset id]."

Is this just the way it is? Or are we doing something wrong?

Answer 1

"hg fetch" will do the whole pull/merge/update in one command which makes stuff a bit more streamlined.

In short though yes there will be a lot more change logs that we are used to in SVN so "thats just the way it is" but it is that way for a reason, HG tracks more changes and EVERYTHING you do to the file is trackable and recorded.

You can of course commit to your local repos as often as you like, you don't have to push for every single changeset, feel free to store them up and then do a push once you are happy that you have a complete chunk of work that you want to go into the main repos. That would also limit the number of merges you have to do. Depends of course on how much toe treading you guys are doing if you are working on the same code.

Answer 2

It seems like your workflow could benefit from each person having his or her own independent branch repository. The developers can then work on their own stuff without merging for a while and then merge every now and then with an upstream central repository. As long as each person is working on something that can be done independently of other features (and a surprising amount of problems can be broken down this way), this works rather well. I know this, for example, is how the Kiln team works and it holds up well.