Sat, 09 Feb 2013 15:22:12 -0800 worker: count the number of CPUs
Bryan O'Sullivan <bryano@fb.com> [Sat, 09 Feb 2013 15:22:12 -0800] rev 18635
worker: count the number of CPUs This works on the major platforms, and falls back to a safe guess of 1 elsewhere.
Sat, 09 Feb 2013 15:22:10 -0800 tests: getremove test output changes (fold into previous patch)
Bryan O'Sullivan <bryano@fb.com> [Sat, 09 Feb 2013 15:22:10 -0800] rev 18634
tests: getremove test output changes (fold into previous patch)
Sat, 09 Feb 2013 15:22:09 -0800 merge: report non-interactive progress in chunks
Bryan O'Sullivan <bryano@fb.com> [Sat, 09 Feb 2013 15:22:09 -0800] rev 18633
merge: report non-interactive progress in chunks Instead of a monotonic count, getupdates yields the number of files it has updated since it last reported, and its caller sums the numbers when updating progress. Once we run these updates in parallel, this will allow worker processes to report progress less often, reducing overhead.
Sat, 09 Feb 2013 15:22:08 -0800 merge: handle subrepo merges and .hgsubstate specially
Bryan O'Sullivan <bryano@fb.com> [Sat, 09 Feb 2013 15:22:08 -0800] rev 18632
merge: handle subrepo merges and .hgsubstate specially In an upcoming patch, we will update .hgsubstate in a non-interactive worker process. Merges of subrepo contents will still need to occur in the master process (since they may be interactive), so we move that code into a place where it will always run in what will become the master process.
Sat, 09 Feb 2013 15:22:04 -0800 tests: update test output (will be folded into parent)
Bryan O'Sullivan <bryano@fb.com> [Sat, 09 Feb 2013 15:22:04 -0800] rev 18631
tests: update test output (will be folded into parent)
Sat, 09 Feb 2013 15:21:58 -0800 merge: split out mostly-non-interactive working dir updates
Bryan O'Sullivan <bryano@fb.com> [Sat, 09 Feb 2013 15:21:58 -0800] rev 18630
merge: split out mostly-non-interactive working dir updates In a later patch, we'll run these updates in parallel.
Sat, 09 Feb 2013 11:00:42 +0100 extensions: obsolete and remove interhg extension
Angel Ezquerra <angel.ezquerra@gmail.com> [Sat, 09 Feb 2013 11:00:42 +0100] rev 18629
extensions: obsolete and remove interhg extension With the addition of the websub filter extension this extension is no longer needed. We maintain a sort of backwards compatibility by reading the [interhg] section and using it as we would use the [websub] section.
Sat, 09 Feb 2013 16:48:21 +0100 hgweb: apply the websub filter to revision descriptions
Angel Ezquerra <angel.ezquerra@gmail.com> [Sat, 09 Feb 2013 16:48:21 +0100] rev 18628
hgweb: apply the websub filter to revision descriptions In order to use this, add a [websub] section to your configuration and add websub expressions such as: italic = s/\b_(\S+)_\b/<i>\1<\/i>/ bold = s/\*\b(\S+)\b\*/<b>\1<\/b>/ issues = s|issue(\d+)|<a href="http://bts.example.org/issue\1">issue\1</a>|i bugzilla = s!((?:bug|b=|(?=#?\d{4,}))(?:\s*#?)(\d+))!<a href="http://bz.selenic.com/\2">\1</a>!i This also adds documentation (proofed by Kevin!) to the config help section.
Fri, 08 Feb 2013 18:05:32 +0100 hgweb: add websub template filter
Angel Ezquerra <angel.ezquerra@gmail.com> [Fri, 08 Feb 2013 18:05:32 +0100] rev 18627
hgweb: add websub template filter The purpose of this new filter is to make it possible to partially replace the functionality of the interhg extension. The idea is to be able to define regular expression based substitutions on a new "websub" config section. hgweb will then be able to apply these substitutions wherever the "websub" filter is used on a template. This first revision just adds the code necessary to load the websub expressions and adds the websub filter, but it does not add any calls to the websub filter itself on any of the templates. That will be done on the following revisions.
Tue, 05 Feb 2013 14:36:19 -0800 addremove: don't audit the path for paths already in the dirstate
Durham Goode <durham@fb.com> [Tue, 05 Feb 2013 14:36:19 -0800] rev 18626
addremove: don't audit the path for paths already in the dirstate Now that dirstate.walk returns None for paths under symlink directories, addremove doesn't need to validate each path it sees to look for files under symlinks. On a large repository this brings addremove from 6.3 seconds down to 3.65 (42%) since addremove no longer has to stat every directory of every file to determine if the file is inside a symlink directory. I put it through our benchmark and see no perf hit to any other commands.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip