Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have a situation, when I'm working on a project, but at same time small issues arise which require quick fix. I would like to push just the fixes for these problems to the main repo while keeping the rest locally. Problem is that, as I've already found out, it's not possible to cherry pick changsets when pushing from my repository upwards.

So the question is, how to set up my Hg environment to have such a possibility. I want to preserve all the Hg metadata, so sending patches around is not a option.

BTW, if the whole thing can be managed directly from MercurialEclipse, that would be a big plus.

share|improve this question
    
This link illustrate on how to manage bug fixing with mercurial. ie: fix a bug in v1.x while working on v2.0 in the same trunk hginit.com/05.html –  JF Dion Jun 28 '11 at 12:49
1  
check this out and do something less complicated for your project –  Thanos Papathanasiou Jun 28 '11 at 12:51
    
@ThanosPapathanasiou - I guess, replacing it all with git is not an option too ;) –  Andreas_D Jun 28 '11 at 14:45
    
@Andreas_D I wasn't suggesting git, just the branching model. –  Thanos Papathanasiou Jun 29 '11 at 7:15
    
@ThanosPapathanasiou - ah, OK, looked to me like a contribution to the old "mercurial/git" fight ;) sorry for that! –  Andreas_D Jun 29 '11 at 7:21

6 Answers 6

I think, we should do it like this:

  1. clone the main repository (again)
  2. apply your fixes, check in sources locally
  3. push the changes back to main
  4. delete the clone (we don't need it anymore, so we delete it as soon as possible)
  5. synchronize your other repo with main (merge locally)
share|improve this answer
    
cloning from main repository takes quite long for me as it's over 100MB in 12000 files to be fetched from remote server. –  vartec Jun 28 '11 at 14:37
    
You could run a local main clone and use it for creating local project clones only. Although this requires additional synchronization. But cloning inside a local machine should be quite fast. And pushing/pulling only sends/receives changesets. –  Andreas_D Jun 28 '11 at 14:43
1  
@vartec: Instead of using hg clone you can also rsync the main repo -- much, much faster. The only thing you lose is the [paths] default = /path/to/main/repo in the clone's .hgrc file, which you can either edit in yourself, or just specify at push time. If you are pulling into the main repo, you'll have to specify the path anyway, so even this doesn't matter. –  Peter Rowell Jun 28 '11 at 15:53

This is exactly what branches are for -- use them. In this case, I would be developing in my branch while the main line of development was in default. Keep your fixes cleanly in the right branch, merge as necessary. If it is the sort of app where breaking flow and doing a hg update hurts, just keep 2 distinct copies locally, pointed at appropriate branches. Working on a hotfix is as expensive as another instance of the IDE.

share|improve this answer

If cloning remotely really does take too long, then this (based on Adreas_D's answer) could be much faster:

  1. Clone your local repo.
  2. Copy the hgrc from your local repo to your local clone (this will make the default path the same for both repos, so push/pull/incoming/outgoing will all point at the server)
  3. Update to the tip of your remote repo.
  4. Apply the fix and commit.
  5. Strip the changesets that you don't want to push (this may require you to enable the mercurial queues extension).
  6. Push the changes back up to the remote repo.
  7. Delete the clone (or keep it around so that you can do this type of fix more quickly in the future).
  8. Pull changes from the remote repo into your normal local repo and merge.

Alternatively, consider a workflow using named branches. That way, you can push your branch changesets up to the server whenever you like, as they won't become part of the default branch until they are explicitly merged in.

share|improve this answer

Mercurial Queues is the easiest and fastest way: 1. You have not create (and work with) additional (even local) clone 2. You have all non-bugfix changes stored only locally (in your repo)

Another solutions (acceptable) can be - Named branches (for "work-in-progress"); - LocalBranch extension.

share|improve this answer

After spotting this answer to this question, it looks like there is another option.

If you do hg push -r . then it will push the parent of the current working copy and all of it's ancestors, but nothing else. Using this, you could:

  1. Commit or shelve any uncommitted changes.
  2. Update to the tip of your remote repo.
  3. Apply the fix and commit.
  4. Push the just those changes back up to the remote repo.
  5. Update back to your local head.
  6. Merge in the bug fix.
share|improve this answer

The quick method would be : - to update to the last stable production changeset;

  • Make the change, then commit the change;

  • Create a version tag;

  • Export the patch;

  • Update to the working changeset;

  • Merge the working changeset with the tag previously create to bring back the fix;

For more detail see http://hginit.com/05.html

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.