Using Mercurial patch queue repository on BitBucket for many users and patches

Question

Sorry for the many-part question, but I am having a difficult time understanding the intended methods to use a Mercurial Patch Queue with BitBucket, and Google isn't helping much. My hope is that one answer describing some MQ concepts will cover many of the questions at once. I have read http://ches.nausicaamedia.com/articles/technogeekery/using-mercurial-queues-and-bitbucket-org, but it seems to be out of date and incomplete. My overall plan is to allow a multitude of submitted changes from a multitude of users without necessarily committing them to a branch. These patches represent optional modifications players are making to a game to enhance and extend the game. And I want users to be able to cherry-pick an arbitrary patch or set of patches to play with and review. When I get a firm understanding of how hg works, I intend to write some PHP scripts or something to pull a branch plus a selected set of patches into a workspace for a player to be able to run the HTML5 code for review.

I have been able to:

1. Create a repository on SourceForge http://sourceforge.net/p/iotabuildit/wiki/Home, where I originally thought I would be hosting everything.
2. Commit all my code to the SourceForge repository.
3. Realize that BitBucket may be a better place to host this (thanks to Recommended DVCS mechanism for hosting many independent patches) given my requirements.
4. Import my code directly from SourceForge's Mercurial repository into BitBucket http://bitbucket.org/bluemonkmn/iotabuildit/
5. Add the BitBucket URI to TortoiseHg so I can use the same local repository with either online repository.
6. Enable mq in TortoiseHg
7. QCommit a change into my local repository's patch queue.
8. Create a patch queue repository on BitBucket http://bitbucket.org/bluemonkmn/iotabuilditmq/.
9. Clone the patch queue repository to a local repository
10. Copy the patch files from the original local repository into the patch queue repository (although I wonder if there's a better way to do this).
11. Push the patches to the BitBucket patch queue repository by turning on the --mq switch before doing a push.
12. See the patches listed in BitBucket.
13. Clone a fresh copy of the BitBucket patch queue repository and see the patches available in the local repository (along with the rest of the tree).

The things I can't figure out or have questions about are:

1. Do I need to keep both a main repository and a patch repository locally?
   • Can/should I use the patch repository with SourceForge? (If I can, I may abandon BitBucket.)
   • Does SourceForge support mq? (Will SourceForge ever give me a cloned repository with the patches sitting in it like I saw on BitBucket?)
   • Can/should I use the original repository with the BitBucket patch repository? (If I can, I may abandon the repository at SourceForge.)
   • Do I need to use one repository when working on code intended for patches and the other when working on code intended to be formally committed?
2. What is the best way to push a patch into an online repository?
   • Do I do a QCommit or QNew on the local patch repository, then Push with the --mq switch?
   • At some point during my process, I committed a series and a .diff file to the patch repository, which seemed a little off. Has this tainted my perception of how mq and BitBucket are supposed to work?
   • Should I ever be committing .diff files to source control on BitBucket or SourceForge? (In some cases, QCommit seems to want to commit .hgignore, series, and .diff files)
   • Are users supposed to be able to see pending applied and/or un-applied patches in a patch repository after cloning it?
3. Is there any way to pull available patches in a local or remote repository without cloning it?
   • Once I deleted a patch in my local repository, I wasn't able to figure out how to get it back from the remote repository without re-cloning it, nor was I able to figure out how to commit the delete of the patch.
   • I wasn't able to transfer the patch from my original repository into the patch repository without manually copying patch files.
4. Am I soon going to run into a problem where I won't be able to pick out some patches from the queue without getting other patches ahead of it in the same queue? I am concerned that some players will neglect to make their patches on a separate branch/queue/whatever which will put them in line with unrelated changes from the same (or maybe even another) user. Any suggestions in dealing with that potential problem are also appreciated.
5. Is it possible (to allow) for an arbitrary user to submit a patch without having to explicitly add every BitBucket user to have permissions on the patch repository?
6. Is it advisable and reasonable to have all (potentially hundreds of?) users sharing the patch queue repository? This would be ideal (rather than having each user create their own patch repository, if that's even possible) because I don't want this to be complicated for users, and given the amount of time I have taken in understanding Mercurial and BitBucket, I fear any complication will turn off a lot of users/players.

As you may be able to tell, I'm kind of lost, not knowing what questions to ask. I suspect the answer is simpler than these questions, but without knowing the question, it's hard to ask the right question. Hopefully one answer describing the nature of a patch queue repository will clear all this up for me.

Answer 1

Reviewing my old questions, I think my understanding of DVCS was too obscured by my familiarity with CVCS. In the end I simply allowed other SourceForge users to host their own clones of my repository and publish links to their repositories (see http://sourceforge.net/p/iotabuildit/wiki/reviews/).

Answer 2

I think I found the answer to the second bullet on question #3:

1. Make sure the patch is in the applied queue in the source (local) repository.
2. Now I can select "Copy patch" from the "Export" context menu in TortoiseHg Workbench.
3. Then I can switch to the other local repository and select "Import..." from the "Repository" menu.
4. Click "Import from Clipboard"
5. In the drop-down list of the targets where the patch can be applied, select "patches".
6. Click Import

Now the patch from the other local repository appears (un-applied) in the local repository, and can easily be applied.

Unless I find answers to all my other questions myself, I likely won't be accepting this (my own) answer. I hope someone can help me with the other questions.

Answer 3

I'm afraid, with SF heap of clones you went by "far from ideal" path to the "unmanaged chaos" milestone

• Yon can use MQ-queues with Bitbucket (see mercurial-crew-mq repo or hgsubversion-layout-hacks repo) without additional repo, only with dir inside .hg for patches
• I can't see any reasons to storing patches in own repo (changesets are almost unreadable - diffs of diffs, history of patch have near-zero value)
• With patches in one repo you can provide easy exchange and update of patches
• qclone | push --mq provide bidirectional exchange of patches on top of vanilla code
• Group-work and P2P communication around some patches for contributors may be provided with MQCollab extension