![]() The visual diff system will use any existing extdiff configuration it finds. They only need to select the tools they wish use, or accept the defaults. The merge tool configuration file contains optimal command lines for each tool, so no further configuration is required by the user. However the user can still select a separate tool ( TortoiseHg ‣ Visual Diff Tool) for visual diffs if they chose. If the user has selected a merge tool ( TortoiseHg ‣ Three-way Merge Tool), that tool will also be used to perform visual diffs, bypassing the tool selection process. The new system uses tool descriptions in mergetools.rc to detect most common diff tools on your computer (including KDiff3, which ships in our installer) and select the best available tool. In TortoiseHg 1.0, the visual (external) diff infrastructure was refactored. Which may sound complicated, but is easier than it sounds. Push your changes to the group repository, TortoiseHg ‣ Workbench or thg log, select the path to group repository and then click the Push button.Ensure your merged work still builds and passes your extensive test suite.Finally, in the merge dialog, press Merge and then Commit. From the revision history viewer ( TortoiseHg ‣ Workbench or thg log) open the context menu over the changeset which you want to merge and select Merge with local…. If some changesets were pulled, merge those changes with your local changes and then commit the merge into your local repository.Pull changes from the group repository into your repository using TortoiseHg ‣ Workbench or thg log, select the Sync task tab, choose the path to the group repository in the syncbar and then click the Pull button.Commit your changes to your local repository (see above).When you’re ready to publish your changes, you Though it might be quicker to do that from the Commit task tab in the Workbench. You can traverse the directories to find specific changes and commit them from Explorer. Mercurial allows you to commit many changes before you decide to synchronize (share changes) with the group repository.Įxplorer: inspect the icons on the folders and files in your repositoryįolders or files in Explorer marked with one of the icons below are another way of indicating pending changes. The Commit task tab in the Workbench gives you a way to see differences within the files, or you can use your visual difference tool (kdiff3). Workbench: go to the Commit task tab and inspect the filelist at the leftĪny files marked with ‘A’ (added, green), with ‘?’ (unversioned but not ignored, fuchsia), with ‘M’ (modified, blue), or with ‘!’ (removed, red) indicate pending changes that should be committed. It is easy to discover what pending changes there are in the repository. ![]() It should be safe to uninstall the older TortoiseOverlay applications from Add/Remove Programs after you uninstalled the legacy (<=0.9.3) TortoiseHg installer, unless you have other Tortoise products that still use the separate TortoiseOverlay MSI approach (TortoiseCVS or TortoiseBZR). The new MSI installers for TortoiseHg include the TortoiseOverlay packages as “merge modules” so they do not appear as separate applications anymore. (On 圆4 platforms, there were two TortoiseOverlays, one for x86 processes and one of 圆4 processes). They installed a TortoiseOverlay package as a separate application, so you always saw both TortoiseHg and TortoiseOverlay as two applications in the Add/Remove Programs control panel program. Legacy TortoiseHg installers (prior to version 1.0) were built with InnoSetup. This is not a problem with the newer MSI packages. Legacy uninstallers (<=0.9.3) have a tendency to delete your user Mercurial.ini file, so backup your file before uninstalling the older TortoiseHg versions.
0 Comments
Leave a Reply. |