Извините за вопрос, состоящий из многих частей, но мне трудно разобраться в предполагаемых методах использования очереди исправлений Mercurial с BitBucket, и Google мало чем помогает. Я надеюсь, что один ответ, описывающий некоторые концепции MQ, будет охватывать многие вопросы одновременно. я прочиталhttp://ches.nausicaamedia.com/articles/technogeekery/using-mercurial-queues-and-bitbucket-org, но, похоже, устарел и неполон. Мой общий план состоит в том, чтобы разрешить множество представленных изменений от множества пользователей без обязательной фиксации их в ветке. Эти патчи представляют собой необязательные модификации, которые игроки вносят в игру для улучшения и расширения игры. И я хочу, чтобы пользователи могли выбирать произвольный патч или набор патчей для игры и просмотра. Когда я получу четкое представление о том, как работает hg, я намереваюсь написать несколько сценариев PHP или что-то еще, чтобы вытащить ветку плюс выбранный набор исправлений в рабочее пространство, чтобы игрок мог запустить HTML5-код для проверки.

яhave мог:

Create a repository on SourceForge http://sourceforge.net/p/iotabuildit/wiki/Home, where I originally thought I would be hosting everything. Commit all my code to the SourceForge repository. Realize that BitBucket may be a better place to host this (thanks to Recommended DVCS mechanism for hosting many independent patches) given my requirements. Import my code directly from SourceForge's Mercurial repository into BitBucket http://bitbucket.org/bluemonkmn/iotabuildit/ Add the BitBucket URI to TortoiseHg so I can use the same local repository with either online repository. Enable mq in TortoiseHg QCommit a change into my local repository's patch queue. Create a patch queue repository on BitBucket http://bitbucket.org/bluemonkmn/iotabuilditmq/. Clone the patch queue repository to a local repository 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). Push the patches to the BitBucket patch queue repository by turning on the --mq switch before doing a push. See the patches listed in BitBucket. 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).

Вещи, которые яcan't выяснить или есть вопросы о:

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? 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? 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. 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. 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? 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.

Как вы можете сказать, я немного растерялся, не зная, какие вопросы задавать. Я подозреваю, что ответ проще, чем эти вопросы, но, не зная вопроса, трудно задать правильный вопрос. Надеюсь, один ответ, описывающий природу хранилища очереди исправлений, прояснит все это для меня.