4

We are newbies to Mercurial, we got through evaluation, etc., and are now using it for real.

The issue is the way we are using it in our teams.

We have done some research and this link looks like the same issue, but the solution looks a bit convoluted to use in practice 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 -- nothing new there -- we stage pushes using a gatekeeper model.

One team member is doing a large change to "File A", this is taking a while, he has been working away, committing changes locally.

In the middle of doing work on File A, he is asked to sort out an issue and fix a problem in File B. This is to help out another developer. How can he do this? He does not want his incomplete changes for File A going into the Gatekeeper, yet he needs to get his File B changes pushed.

Troy J. Farrell
  • 1,252
  • 11
  • 18
user563251
  • 89
  • 5
  • 2
    Keep in mind that branches are __really__ cheap to make. As the one answer you've gotten has said, just have the developer clone another branch on his machine from the shared gatekeepered repository. – Omnifarious Jul 01 '11 at 21:40

3 Answers3

6

Have the developer create a new local directory called File_B_Fix or similar and then clone the shared repository to that. Make the fix to file B and then push the changes back to the shared repository.

Andrew Cowenhoven
  • 2,778
  • 22
  • 27
1

I like to use named branches. We currently create a named branch for each new feature. Then if you need a bug fix you can jump to stable or default (whatever you want to call it) with the update command. You can also use clones. So see some thoughts about the differences see Mercurial: Named Branches vs Multiple Repositories and A Guide to Branching in Mercurial.

Community
  • 1
  • 1
masebase
  • 4,915
  • 3
  • 24
  • 20
0

For this specific case, and for the added flexibility it gives in general, I'd suggest you to learn and use Mercurial Queues. It's an invaluable tool everyone using Mercurial should add to their workflow.

In your case, that team member would 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 for how to commit these changes to the repo.

An alternative to this would be the shelve extension, which would allow you to temporarily set aside any outstanding changes, work on file B, and then restore the changes. But using MQ gives you many additional benefits.

imiric
  • 8,315
  • 4
  • 35
  • 39