##// END OF EJS Templates
upstream » mercurial-mirror
RSS

Clone from https://www.mercurial-scm.org/repo/hg-all

changegroup: introduce requests to define delta generation...
changegroup: introduce requests to define delta generation Currently, we iterate through each revision we will be producing a delta for then call into 1 of 2 functions for generating that delta. Deltas are emitted as we iterate. A problem with this model is that revision generation is tightly coupled to the changegroup code. And the storage layer needs to expose APIs like deltaparent() so changegroup delta generation can produce a delta with that knowledge. Another problem is that in this model, deltas can only be produced sequentially after the previous delta was produced and emitted. Some storage backends might be capable of producing deltas in parallel (e.g. if the changegroup deltas are cached somewhere). This commit aims to solve these problems by turning delta generation into a 2 phase implementation where the first phase determines info about all the deltas that need to be generated and the 2nd phase resolves those deltas. We introduce a "revisiondeltarequest" object that holds data about a to-be-generated delta. We perform a full pass over all revisions whose delta is to be generated and generate a "revisiondeltarequest" for each. Then we iterate over the "revisiondeltarequest" instances and derive a "revisiondelta" for each. This patch was quite large. In order to avoid even more churn, aspects of the implementation are less than ideal. e.g. we're recording revision numbers instead of nodes in a few places and we don't yet have a formal API for resolving an iterable of revisiondeltarequest instances. Things will be improved in subsequent commits. Unfortunately, this commit reduces performance substantially. For `hg perfchangegroupchangelog` on my hg repo: ! wall 1.512607 comb 1.510000 user 1.490000 sys 0.020000 (best of 7) ! wall 2.150863 comb 2.150000 user 2.150000 sys 0.000000 (best of 5) And for `hg bundle -t none-v2 -a` for the mozilla-unified repo: 178.32user 4.22system 3:02.59elapsed 190.97user 4.17system 3:15.19elapsed Some of this was attributed to changelog slowdown. `hg perfchangegroupchangelog` on mozilla-unified: ! wall 21.688715 comb 21.690000 user 21.570000 sys 0.120000 (best of 3) ! wall 25.683659 comb 25.680000 user 25.540000 sys 0.140000 (best of 3) Profiling seems to reveal that the changelog slowdown is due to reading changelog revisions multiple times. First in the linknode callback to resolve the set of files changed. Second in the delta generation. Before, we likely had hit the last revision cache in the revlog when doing delta generation since we performed that immediately after performing the linknode callback. I'm not exactly sure where the other ~8s are being spent. It might be from overhead of constructing a few million revisiondeltarequest objects. I'm OK with the regression for now because it is in service of a larger cause (storage abstraction). I'll try to profile later and claw back the performance. Differential Revision: https://phab.mercurial-scm.org/D4215
timeless - - Load All Authors

File last commit:

r26805:e999ed21 default
r39054:e793e11e default
Show More
win32-build.txt
130 lines | 4.7 KiB | text/plain | TextLexer
/ contrib / win32 / win32-build.txt
History | Annotation | Raw |Copy content |Copy permalink
The standalone Windows installer for Mercurial is built in a somewhat
jury-rigged fashion.
It has the following prerequisites. Ensure to take the packages
matching the mercurial version you want to build (32-bit or 64-bit).
Python 2.6 for Windows
http://www.python.org/download/releases/
A compiler:
either MinGW
http://www.mingw.org/
or Microsoft Visual C++ 2008 SP1 Express Edition
http://www.microsoft.com/express/Downloads/Download-2008.aspx
Python for Windows Extensions
http://sourceforge.net/projects/pywin32/
mfc71.dll (just download, don't install; not needed for Python 2.6)
http://starship.python.net/crew/mhammond/win32/
Visual C++ 2008 redistributable package (needed for >= Python 2.6 or if you compile with MSVC)
for 32-bit:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf
for 64-bit:
http://www.microsoft.com/downloads/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6
The py2exe distutils extension
http://sourceforge.net/projects/py2exe/
GnuWin32 gettext utility (if you want to build translations)
http://gnuwin32.sourceforge.net/packages/gettext.htm
Inno Setup
http://www.jrsoftware.org/isdl.php#qsp
Get and install ispack-5.3.10.exe or later (includes Inno Setup Processor),
which is necessary to package Mercurial.
ISTool - optional
http://www.istool.org/default.aspx/
add_path (you need only add_path.exe in the zip file)
http://www.barisione.org/apps.html#add_path
Docutils
http://docutils.sourceforge.net/
CA Certs file
http://curl.haxx.se/ca/cacert.pem
And, of course, Mercurial itself.
Once you have all this installed and built, clone a copy of the
Mercurial repository you want to package, and name the repo
C:\hg\hg-release.
In a shell, build a standalone copy of the hg.exe program.
Building instructions for MinGW:
python setup.py build -c mingw32
python setup.py py2exe -b 2
Note: the previously suggested combined command of "python setup.py build -c
mingw32 py2exe -b 2" doesn't work correctly anymore as it doesn't include the
extensions in the mercurial subdirectory.
If you want to create a file named setup.cfg with the contents:
[build]
compiler=mingw32
you can skip the first build step.
Building instructions with MSVC 2008 Express Edition:
for 32-bit:
"C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86
python setup.py py2exe -b 2
for 64-bit:
"C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64
python setup.py py2exe -b 3
Copy add_path.exe and cacert.pem files into the dist directory that just got created.
If you are using Python 2.6 or later, or if you are using MSVC 2008 to compile
mercurial, you must include the C runtime libraries in the installer. To do so,
install the Visual C++ 2008 redistributable package. Then in your windows\winsxs
folder, locate the folder containing the dlls version 9.0.21022.8.
For x86, it should be named like x86_Microsoft.VC90.CRT_(...)_9.0.21022.8(...).
For x64, it should be named like amd64_Microsoft.VC90.CRT_(...)_9.0.21022.8(...).
Copy the files named msvcm90.dll, msvcp90.dll and msvcr90.dll into the dist
directory.
Then in the windows\winsxs\manifests folder, locate the corresponding manifest
file (x86_Microsoft.VC90.CRT_(...)_9.0.21022.8(...).manifest for x86,
amd64_Microsoft.VC90.CRT_(...)_9.0.21022.8(...).manifest for x64), copy it in the
dist directory and rename it to Microsoft.VC90.CRT.manifest.
Before building the installer, you have to build Mercurial HTML documentation
(or fix mercurial.iss to not reference the doc directory):
cd doc
mingw32-make html
cd ..
If you use ISTool, you open the C:\hg\hg-release\contrib\win32\mercurial.iss
file and type Ctrl-F9 to compile the installer file.
Otherwise you run the Inno Setup compiler. Assuming it's in the path
you should execute:
iscc contrib\win32\mercurial.iss /dVERSION=foo
Where 'foo' is the version number you would like to see in the
'Add/Remove Applications' tool. The installer will be placed into
a directory named Output/ at the root of your repository.
If the /dVERSION=foo parameter is not given in the command line, the
installer will retrieve the version information from the __version__.py file.
If you want to build an installer for a 64-bit mercurial, add /dARCH=x64 to
your command line:
iscc contrib\win32\mercurial.iss /dARCH=x64
To automate the steps above you may want to create a batchfile based on the
following (MinGW build chain):
echo [build] > setup.cfg
echo compiler=mingw32 >> setup.cfg
python setup.py py2exe -b 2
cd doc
mingw32-make html
cd ..
iscc contrib\win32\mercurial.iss /dVERSION=snapshot
and run it from the root of the hg repository (c:\hg\hg-release).