Geek Answers Handbook

Mercury teamwork

We are new to Mercurial, we have been evaluated, etc., and now use it for real.

The problem is how we use it in our teams.

We did some research, and this link looks like the same problem, but the solution seems a bit confusing for practical use http://blogs.oracle.com/tor/entry/mercurial_tip_checking_in_regularly .

Our problem is that we have a team of people working on the same software project - there is nothing new there - we set the click using the gatekeeper model.

One member of the team makes big changes to "File A", it takes some time, he is already working, making changes locally.

In the middle of working on file A, he will be asked to deal with the problem and fix the problem in file B. This will help another developer. How can he do this? He does not need his incomplete changes for file A included in the gatekeeper, but he needs his changes in file B to be pushed.

+4
source share
3 answers

Ask the developer to create a new local directory named File_B_Fix or similar, and then clone the shared repository. Correct the file B, and then revert the changes to the shared repository.

+6
source

I like to use named branches. We are currently creating a named branch for each new function. Then, if you need a bug fix, you can go to stable or the default (no matter what you want to call) with the update command. You can also use clones. Therefore, see Some thoughts on the differences, see Mercurial: Named Branches vs. Multiple Repositories and the Mercurial Branching Guide .

+1
source

In this particular case, and for the added flexibility that it gives in general, I suggest you study and use Mercurial Queues . This is an invaluable tool that anyone using Mercurial should add to their workflow.

In your case, this team member will do:

hg qinit -c hg qnew changes-to-fileA # creates a new patch with the outstanding changes hg qnew changes-to-fileB # creates a new empty patch # work on file B hg qrefresh # updates the patch with changes to file B

Read the MQ tutorial on how to commit these changes to the repo.

An alternative would be the shelve extension, which allows you to temporarily delay any outstanding changes, work with file B, and then restore the changes. But using MQ gives you many additional benefits.

0
source

More articles:


All Articles