8/22/2023 0 Comments Tortoisehg shelve changes![]() =/Applications/Xcode.app/Contents/Applications/FileMerge. =-left $other -right $local -ancestor $base -merge $output When I run hg config, which is supposed to show the combined settings from all hgrc files, it does the following entries, but I do not know where they come from =/Developer/Applications/Utilities/FileMerge.app/Contents/MacOS/FileMerge Pom_merge.executable = /Users/username/codebases/apm/hg/secondbase/tools/hg-tools/pom_merge.pyĮditor="/Applications/kdiff3.app/Contents/MacOS/kdiff3" Pom_merge.args = -o $output $base $local $other Kdiff3.args = $base $local $other -o $output The configuration in ~/.hgrc looks as follows Ĭmd.kdiff3="/Applications/kdiff3.app/Contents/MacOS/kdiff3" I do not want hg to use the file merge tool and have not done any change for this to happen except install xcode. I just upgraded to macOS High Sierra(10.13.4) to install Xcode.īefore the upgrade, my mercurial was set up to use kdiff3 as the diff tool and I was happy with it.Īfter the upgrade, mercurial is now using the file merge tool that comes with xcode. I have big-push, caseguard, fetch, gestalt, kbfiles, kiln, kilnauth, kilnpath, mq, purge, and transplant extensions enabled.Īny ideas where to start figuring out how to speed stuff up? The slowness is driving us crazy.This is perhaps a question for hg as much as it is for macOS. The max file size in the sub-repo is 132 MB. The average file size in the sub-repo is 23KB. The max file size in the main repo is 170 MB. The average file size in the main repo is 563 KB. The contents of default in the sub-repo is 642 MB. The contents of default in the primary repo is 7.05 GB. The repository is actually two repositories: a primary repo and a sub-repo that contains all our third-party binaries. Tried in on varying hardware, most of it reasonable quality: Core 2 Duo GHz, 8Gb Ram.Tried it on 3 different versions of windows.But even if you assume no shelving and no opening cost (maybe you just leave it open), it still takes 2 and half minutes of meticulous clicking to get the latest stuff.Īnd that doesn't even count the more significant stuff like cloning and whatnot. One consequence of this is that people tend to commit stuff they aren't sure will go anywhere just in order to avoid the shelving cost. Twelve of those minutes are spent shelving and unshelving. Wait for merge (assuming no conflicts): 10 seconds.Wait for "Clean" verification: 15 seconds.Accept incoming changesets: 40 seconds.Check for incoming changesets: 10 seconds.Select important files and type a commit message.Click on "Working Directory": 5 seconds.Commit local changes that need committing:.Open the appropriate repository by double-clicking in the repository registry: 5 seconds.It looks like this (only listing the time spent waiting on the computer, rounded): embedded Mercurial to v3.7.3, updated hgflow, switched shelving to use. For example, a typical task is "get the latest stuff my coworker just pushed". SRCTREEWIN-7862 In some circumstances the changes to the loaded Mercurial. The command-line times seem to jive with the workbench times, but the workbench makes the delay much more frustrating, because it is synchronous with the use of the program. For reference, here are the command line tool times: Time to check for incoming changes: 12.8 secondsĪll this really adds up to a very slow feeling application. ![]() Time to "Refresh Current Repository": 6.4 seconds.Response time when clicking on a revision: 2.8 seconds.Open TortoiseHg Workbench: 8 minutes 13 seconds.(In part to take advantage of Kiln for Code Reviews) One of the things we've noticed is that interacting with Mercurial through TortoiseHg is painfully slow. My team moved from Subversion to Mercurial recently. ![]() Basically, what it says on the tin: TortoiseHg is slow. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |