![]() We can do this from the Patch Queue or from the context menu Changeset 4 “Modify History->Unapply patch”: This patch was pushed on top of the repository stack and corresponds to the selected changeset: After a successful import you should see a new patch was added to the queue named “. If MQ was properly enabled we should see a “Modify History” menu item in the context menu of the selected changeset. To view the Patch Queue window select “View->Show Patch Queue” from TortoiseHG Workbench: In order to manipulate changesets we must first add them to the Patch Queue. But In this case we will use patches to prevent making permanent changes to our revision history and so making it more clutter free. Long story short, patches deal with handling new code contributions from developers that do not have full commit access to a repository. But just the introduction without code samples, because they are not up to date. To fully understand Mercurial Queues and the history behind patch management I also suggest reading Chapter 12 from the official Mercurial guide. Since we will modify the revision history directly, we cannot rollback if something goes wrong so it’s better to have a cloned repository for the sake of backup before we start. Fold (merge) all changesets that represent topical commit feature A into one changeset.For example changeset 5 where we did some refactoring also contains logical changes that are part of the feature A implementation. This is useful if one commit contains changes related to multiple topics. ![]() Split a changeset by file or by content using the Shelve tool.Reorder changesets so that refactoring changeset 5 comes after feature A is implemented.Delete changeset 4 which was backed out.Using MQ Extensions we will modify our existing revision history, before we make it public. Check TortoiseHG->Repository settings->Extensions->mqĪfter the MQ Extension is enabled, Mercurial will include additional commands which we can print with hg help mq, but since this is a TortoiseHG tutorial, I will show you how to work with MQ through TortoiseHG Workbench.We can do this directly or through TortoiseHG repository settings dialog: ![]() In order to enable the MQ Extension, we modify the local. This functionality does not come out of the box, first we must configure the extension which is being distributed along with Mercurial. Using MQ we can remove, reorder or fold (merge) committed changesets. Mercurial Queues is an extension that rewrites history. It would be nice if you could change history a bit before you push the delivered feature to the public repository, so it would look something like this: How to make changesets mutable in Mercurial And I surely wouldn’t want to share code from revision 4 when I send my changes upstream and share them with other developers. The commits are not topical and there is a lot of cognitive noise just because of backup commits. This kind of spaghetti history is very difficult to review. I stumbled upon an interesting blog post titled “Segregate your commits into tiny topical changes” that made me think of how my current revision history on a project looks like… And that was sufficient for my needs….until recently. For controlling changes made to source code, as for backing up to a private repository hosted at Bitbucket I used the basic commands for committing, adding, pushing and pulling files to/from the local /remote repository on a daily basis. I have been using Mercurial revision control system as a weapon of choice for quite some time now. Keep your Mercurial revision history clutter free Mon, May 19, 2014
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |