If your diff tool is launched directly to compare a working copy file, it will directly diff against the working file so you may modify it from within the diff tool. When your diff tool is launched directly, the temporary files are deleted when your tool exits. Thus it should be left open until you close all of your diff tool instances. When the visual diff window is used, the temporary files are cleaned up when the dialog is closed.
The file changes include renames or copies.The selected tool does not support three way comparisons.The selected tool does not support the required directory diffs.The selected tool forks detached background processes.The selection of files being compared require multiple tools.The visual diff system will directly use the selected diff tool unless the action you are attempting requires the use of the TortoiseHg visual diff window. Since extdiff did not support three way diff arguments until very recently and still does not support label arguments, you will likely have a better experience by disabling or deleting any extdiff configuration you may have. 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 kommentar(er)
