4

Sometimes when I am working on a code change, I need to make a corresponding change to the shared library code in my repository, which is itself a subrepository. When I want to commit the changes, I do so in the parent repository and Mercurial takes care of doing the coresponding commit in the subrepo.

However, I recently started using MQ to better track my own change history and give myself some more freedom to experiment and do large-scale refactoring work more safely. I have MQ enabled on both the parent and subrepo.

In the scenario describe above, am I correct in assuming that if I 'commit' to a new or existing MQ patch, then the subrepo gets ignored? This is what seems to happen in my testing. Does this mean I need to manually manage the patch queue in the subrepo? This gets unwieldy very quickly.

If this doesn't work, that's fine - I can adjust my workflow and avoid MQ when I have cross-repo work to do - but I wonder if I'm missing something or if others have a solution to this scenario they could share.

Update: Seems like this may be 'unsupported' at this point according to this thread: https://www.mercurial-scm.org/bts/issue2499

I tried the following:

  1. Committed the subrepo change manually.
  2. Updated the .hgsubstate file in the parent repository manually with the hash from the subrepo commit.
  3. Tried to qrefresh the parent repository.

The idea was that I could get the commit from the parent repository to always sync with the right subrepo version, even if I had to do it manually. Unfortunately Mercurial seems to want to protect me here (as it should!) and pits out the following when I try to qrefresh:

warning: not refreshing .hgsubstate

In order to 'fix' things I do an empty commit after the hgfinish on the parent repository to get things synced back up. But... that seems silly and makes the code history harder to grok.

Oh well, guess I'll go back to the stone age and stop using MQ in my workflow when there are sub-repositories involved.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Tyler Butler
  • 136
  • 5
  • 3
    You could write the update in your question as an answer, and accept it, so your answer wouldn't appear at the "unanswered" tab. – Somebody still uses you MS-DOS Mar 28 '11 at 21:35
  • the "official workaround" is to make your own clone of that subrepo so you could add a patchqueue to it. if you happen to have your code in bitbucket they have that stuff as an option (instead of forking you make your own patchqueue which is that repository + your patchqueue as a single repo which can be a subrepository) – Łukasz Gruner Jan 21 '13 at 22:53

0 Answers0