Differences between revisions 60 and 61
Revision 60 as of 2007-03-25 03:09:08
Size: 326
Editor: adsl-75-19-152-159
Comment: None
Revision 61 as of 2007-03-25 03:35:22
Size: 10568
Editor: user-38q432f
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Topic-starter of the rights, this acknowledgement there is here is this sites -
 [url=http://www.mlanet.org/am/photo/albums/edit/index.html]Xanax[/url]
  <a href="http://wwww.mlanet.org/am/photo/albums/edit/index.html">Xanax</a>
  http://www.mlanet.org/am/photo/albums/edit/index.html
Thanks!
----
<No addition>
'''Note:''' you probably want the prepackaged Windows version from BinaryPackages!

To install Mercurial from sources under Windows, you need

 * a Python interpreter (such as the one from [http://www.python.org python.org], or [http://www.activestate.com/Products/ActivePython/ ActivePython])
 * a C compiler (this is needed to compile some extensions used by ["Mercurial"], so it's needed at setup-time only and not to run Mercurial itself)
 * Mercurial's own sources, of course
 * a three-way MergeProgram

If you are using [http://www.python.org python.org]'s Python, you will find that the [http://sourceforge.net/project/showfiles.php?group_id=78018&package_id=79063 win32 API extensions] make a huge performance difference when you use the {{{clone}}} command (but see the caveats below about hardlinks on Windows). If you are using Python 2.4, you will also need [http://starship.python.net/crew/mhammond/win32/Downloads.html mfc71.dll]. (These extensions are already shipped as part of [http://www.activestate.com/Products/ActivePython/ ActivePython], but Active``Python is not completely open source software.)

There is a file {{{contrib/win32/win32-build.txt}}} that comes with Mercurial that has instructions to build a Mercurial executable.
-------
This pages describes some issues you may meet when trying to install Mercurial, and how to solve them.

Normally, you would only need to run

{{{
python setup.py install --force
}}}
in the directory where you unpacked the sources, and everything would "just work". The use of {{{-f/--force}}} switch makes sure that any old installation is overwritten.

== Other Windows Tips ==
[[TableOfContents]]

=== Where is my Mercurial? ===

By default, Mercurial (the executable) gets installed in a {{{Scripts}}} folder under your Python installation folder.

You can create a small batch file in a folder which is present in your path (e.g. your Windows installation folder) to help you launch Mercurial.

If you are running a Windows of the 9x series (Windows 95, 98 or ME), create a file called {{{hg.bat}}} with the following content:

{{{
@echo off
shift
python <path-to-Scripts-folder>\hg %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
}}}
For example, if you installed Python in {{{c:\python}}}, the content of the file would be

{{{
@echo off
shift
python c:\python\hg %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
}}}
Under Windows NT, create a file called {{{hg.cmd}}} with the following content:

{{{
@python <path-to-Scripts-folder>\hg %*
}}}
For example, if you installed Python in {{{c:\python}}}, the content of the file would be

{{{
@python c:\python\Scripts\hg %*
}}}

An alternative scheme that works better for some is to search for hg on the PATH.
If you are using hg.exe it should work fine. For the python version of hg you
should be able to simply rename 'hg' to 'hg.py' and assuming you have the .py extension
configured it will be invoked. It is invoked, but there is a long standing redirection
bug in Windows, and on XP there are sometimes problems with exit statuses being lost
with this form of execution. So the following batch file is a solution -- place it in
your PATH and it will find 'hg' without a .py extension in you PATH and invoke it
properly: (name the file '''hg.cmd''')
{{{
@echo off
for /f %%i in ("hg") DO set HGSCRIPT="%%~$PATH:i"
if %HGSCRIPT% == "" (
 echo Cannot find hg on PATH
 exit /b 1
)
python %HGSCRIPT% %*
}}}

=== Python and MingW32 ===

By default, Python and Active``Python will look for Microsoft Visual C to compile the extensions, so you have to tell {{{setup.py}}} to use the Ming``W32 compiler instead. You can do this by running

{{{
python setup.py build --force -c mingw32
python setup.py install --force --skip-build
}}}
or more briefly:
{{{
python setup.py build -f -c mingw32 install -f
}}}

If you are not familiar with mingw32, you will first need to download and install the following packages, in the order given:

{{{
msys.exe
msysDTK.exe
}}}
Afterwards, download and install the following package, installing it in the directory where you installed the msys package (i.e. {{{c:\msys\1.0\}}})

{{{
MinGW.exe
}}}
You can find them at http://www.mingw.org

Then add the Python and mingw directories to your PATH, and run your build from the command prompt:

{{{
set PATH=%PATH%;c:\python24;c:\msys\1.0\mingw\bin
}}}


If you encounter compiler error in Mercurial versions 0.9.2 and up, you may need libpython24.a in PYTHONPATH\libs. If that's the case, you need to:

{{{
pexports C:\WINDOWS\system32\python24.dll > python24.def
dlltool --dllname C:\WINDOWS\system32\python24.dll --def python24.def --output-lib C:\Python24\libs\libpython24.a
}}}

Then the above setup.py script should run properly.


=== Easier MingW32 based build via Cygwin ===

It is easier to install MinGW32 via Cygwin as it has a single graphical installer. After installing, mingw32 via Cygwin installer ({{{setup.exe}}}), add cygwin bin directory to the path and follow the mingw32 build instructions. e.g.

{{{
set PATH=%PATH%;c:\python24;c:\cygwin\bin
python setup.py build --force -c mingw32
python setup.py install --force --skip-build
}}}

=== ActivePython and MS Visual C ===

If you are going to use MS Visual C, you may need to install an appropriate version of Active``Python:
 * Active``Python 2.4.1 requires VC7.1
 * Active``Python 2.3.5 requires VC6

A less than ideal work-around for the version check is to change your
distutils notion of what version of MSVC Python was built with.
Do this by editing your msvccompiler.py file in your python/Lib/distutils directory to match the version of MSVC you actually have, for example:

{{{
   def __init__ (self, verbose=0, dry_run=0, force=0):
       CCompiler.__init__ (self, verbose, dry_run, force)
       self.__version = get_build_version()
 + self.__version = 6 # override build version to match compiler
}}}


=== Python 2.5 for Windows/x64 ===

Note that pywin32 has not yet been ported to the Windows/x64 platform.

==== The python.org distribution and the MS platform SDK compiler ====

If you happen to use the stock [http://www.python.org/ftp/python/2.5/python-2.5.amd64.msi python-2.5.amd64.msi] from python.org, you can build Mercurial using the Platform SDK compiler
(I used the Microsoft Platform SDK for Windows Server 2003 R2).

There's one catch though: if you simply run `python setup.py build`, you'll likely get the following error:
{{{
...
AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'
}}}
To prevent this error, the trick is to set the DISTUTILS_USE_SDK environment variable.

Note: using the Visual Studio 8 compiler ''won't'' work. By using the above trick, you'll manage to build the extensions, but they won't load:
{{{
...
ImportError: DLL load failed with error code 193
}}}

==== ActiveState Python 2.5 ====

If you use the recently released Python 2.5.0.0 from ActiveState,
building Mercurial is a bit easier, as there's no specific requirement on the runtime library.
This means you can use either the MS platform SDK compiler as described above,
or the Visual Studio 8 compiler. Both need the `DISTUTILS_USE_SDK=1` trick.


=== Other miscellaneous issues ===

Win``Zip7 does not seem to create empty files when extracting from .tar files. But Win``Zip9 is fine.

==== Using the SSH protocol ====
Three solutions:
 * Install cygwin and OpenSSH and use the cygwin shell where ssh will be automatically in the PATH
 * Install [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] and follow the instructions in [http://www.selenic.com/mercurial/wiki/index.cgi/TipsAndTricks#head-728e29f739157fd04e05843a07c87b3a2027f973 TipsAndTricks].
 * Install cygwin and OpenSSH and modify Mercurial.ini to call the cygwin installed ssh executable.

Edit the Mercurial.ini to have the following entry:
{{{
[ui]
ssh = C:\cygwin\bin\ssh.exe
}}}

=== Fix the path problem on Windows ===

If you try to use hg inside a directory that has a 'mercurial' subdirectory,
for example when working on the mercurial sources, python may not be able to
load the binary modules needed by Mercurial, and you may get a stack trace like:
{{{
...
  File "C:\projects\hg\mercurial\demandload.py", line 54, in module
    return object.__getattribute__(self, 'importer').module()
  File "C:\projects\hg\mercurial\demandload.py", line 30, in module
    self.fromlist)
  File "C:\projects\hg\mercurial\mdiff.py", line 9, in ?
    import struct, bdiff, util, mpatch
ImportError: No module named bdiff
}}}

See the mail list thread "Fix the path problem on Windows..."
but essentially Python on Windows ends up with the current directory
automatically added to the python search path '''before''' the site libraries.
So if you run hg in its own repository python gets confused, and can't find
the extensions needed. There is a candidate patch that removes the current
directory, but there is an arguably better workaround from K.Thananchayan.
Simply add a registry entry (replacing 2.4 with the version of Python)

{{{
 HKLM/SOFTWARE/Python/PythonCore/2.4/PythonPath/XXX
   (Default) REG_SZ "YYY"
}}}

=== Hardlinks on Windows ===

Mercurial now includes support for cloning with hardlinks on Windows.
However for this to work, your filesystem needs to support them (i.e. NTFS)
and you need the {{{win32}}} API extensions documented above. If you have a filesystem that does not support
hardlinks or don't have the {{{win32file}}} module, mercurial clone will
still work just fine - but you won't get the benefits of hardlinking of course.

For versions of Mercurial prior to 0.7, Mercurial
won't realise that it has to 'break' hardlinks.

The upshot is that if you have repositories cloned with hardlinks
you must not use pre-0.7 versions of mercurial on them (either the
source or the destination clone), or use a version of python without
{{{win32file}}}. If you do you are likely to get corruption.

A simple solution to break the hardlinks is to copy (using xcopy or File Explorer)
one of the repositories, deleting the clone. Copying it back afterwards.

=== Default editor ===

The default editor for commit messages is 'vi'. The Windows installer creates a mercurial.ini that sets it to notepad.
You can set the EDITOR (or HGEDITOR) environment variable to specify your
preference or set it in mercurial.ini:
{{{
[ui]
editor = whatever
}}}

Note: you probably want the prepackaged Windows version from BinaryPackages!

To install Mercurial from sources under Windows, you need

If you are using [http://www.python.org python.org]'s Python, you will find that the [http://sourceforge.net/project/showfiles.php?group_id=78018&package_id=79063 win32 API extensions] make a huge performance difference when you use the clone command (but see the caveats below about hardlinks on Windows). If you are using Python 2.4, you will also need [http://starship.python.net/crew/mhammond/win32/Downloads.html mfc71.dll]. (These extensions are already shipped as part of [http://www.activestate.com/Products/ActivePython/ ActivePython], but ActivePython is not completely open source software.)

There is a file contrib/win32/win32-build.txt that comes with Mercurial that has instructions to build a Mercurial executable.


This pages describes some issues you may meet when trying to install Mercurial, and how to solve them.

Normally, you would only need to run

python setup.py install --force

in the directory where you unpacked the sources, and everything would "just work". The use of -f/--force switch makes sure that any old installation is overwritten.

Other Windows Tips

TableOfContents

Where is my Mercurial?

By default, Mercurial (the executable) gets installed in a Scripts folder under your Python installation folder.

You can create a small batch file in a folder which is present in your path (e.g. your Windows installation folder) to help you launch Mercurial.

If you are running a Windows of the 9x series (Windows 95, 98 or ME), create a file called hg.bat with the following content:

@echo off
shift
python <path-to-Scripts-folder>\hg %0 %1 %2 %3 %4 %5 %6 %7 %8 %9

For example, if you installed Python in c:\python, the content of the file would be

@echo off
shift
python c:\python\hg %0 %1 %2 %3 %4 %5 %6 %7 %8 %9

Under Windows NT, create a file called hg.cmd with the following content:

@python <path-to-Scripts-folder>\hg %*

For example, if you installed Python in c:\python, the content of the file would be

@python c:\python\Scripts\hg %*

An alternative scheme that works better for some is to search for hg on the PATH. If you are using hg.exe it should work fine. For the python version of hg you should be able to simply rename 'hg' to 'hg.py' and assuming you have the .py extension configured it will be invoked. It is invoked, but there is a long standing redirection bug in Windows, and on XP there are sometimes problems with exit statuses being lost with this form of execution. So the following batch file is a solution -- place it in your PATH and it will find 'hg' without a .py extension in you PATH and invoke it properly: (name the file hg.cmd)

@echo off
for /f %%i in ("hg") DO set HGSCRIPT="%%~$PATH:i"
if %HGSCRIPT% == "" (
        echo Cannot find hg on PATH
        exit /b 1
)
python %HGSCRIPT% %*

Python and MingW32

By default, Python and ActivePython will look for Microsoft Visual C to compile the extensions, so you have to tell setup.py to use the MingW32 compiler instead. You can do this by running

python setup.py build --force -c mingw32
python setup.py install --force --skip-build

or more briefly:

python setup.py build -f -c mingw32 install -f

If you are not familiar with mingw32, you will first need to download and install the following packages, in the order given:

msys.exe
msysDTK.exe

Afterwards, download and install the following package, installing it in the directory where you installed the msys package (i.e. c:\msys\1.0\)

MinGW.exe

You can find them at http://www.mingw.org

Then add the Python and mingw directories to your PATH, and run your build from the command prompt:

set PATH=%PATH%;c:\python24;c:\msys\1.0\mingw\bin

If you encounter compiler error in Mercurial versions 0.9.2 and up, you may need libpython24.a in PYTHONPATH\libs. If that's the case, you need to:

pexports C:\WINDOWS\system32\python24.dll > python24.def
dlltool --dllname C:\WINDOWS\system32\python24.dll --def python24.def --output-lib C:\Python24\libs\libpython24.a

Then the above setup.py script should run properly.

Easier MingW32 based build via Cygwin

It is easier to install MinGW32 via Cygwin as it has a single graphical installer. After installing, mingw32 via Cygwin installer (setup.exe), add cygwin bin directory to the path and follow the mingw32 build instructions. e.g.

set PATH=%PATH%;c:\python24;c:\cygwin\bin
python setup.py build --force -c mingw32
python setup.py install --force --skip-build

ActivePython and MS Visual C

If you are going to use MS Visual C, you may need to install an appropriate version of ActivePython:

  • ActivePython 2.4.1 requires VC7.1

  • ActivePython 2.3.5 requires VC6

A less than ideal work-around for the version check is to change your distutils notion of what version of MSVC Python was built with. Do this by editing your msvccompiler.py file in your python/Lib/distutils directory to match the version of MSVC you actually have, for example:

   def __init__ (self, verbose=0, dry_run=0, force=0):
       CCompiler.__init__ (self, verbose, dry_run, force)
       self.__version = get_build_version()
 +     self.__version = 6 # override build version to match compiler

Python 2.5 for Windows/x64

Note that pywin32 has not yet been ported to the Windows/x64 platform.

The python.org distribution and the MS platform SDK compiler

If you happen to use the stock [http://www.python.org/ftp/python/2.5/python-2.5.amd64.msi python-2.5.amd64.msi] from python.org, you can build Mercurial using the Platform SDK compiler (I used the Microsoft Platform SDK for Windows Server 2003 R2).

There's one catch though: if you simply run python setup.py build, you'll likely get the following error:

...
AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root'

To prevent this error, the trick is to set the DISTUTILS_USE_SDK environment variable.

Note: using the Visual Studio 8 compiler won't work. By using the above trick, you'll manage to build the extensions, but they won't load:

...
ImportError: DLL load failed with error code 193

ActiveState Python 2.5

If you use the recently released Python 2.5.0.0 from ActiveState, building Mercurial is a bit easier, as there's no specific requirement on the runtime library. This means you can use either the MS platform SDK compiler as described above, or the Visual Studio 8 compiler. Both need the DISTUTILS_USE_SDK=1 trick.

Other miscellaneous issues

WinZip7 does not seem to create empty files when extracting from .tar files. But WinZip9 is fine.

Using the SSH protocol

Three solutions:

Edit the Mercurial.ini to have the following entry:

[ui]
ssh = C:\cygwin\bin\ssh.exe

Fix the path problem on Windows

If you try to use hg inside a directory that has a 'mercurial' subdirectory, for example when working on the mercurial sources, python may not be able to load the binary modules needed by Mercurial, and you may get a stack trace like:

...
  File "C:\projects\hg\mercurial\demandload.py", line 54, in module
    return object.__getattribute__(self, 'importer').module()
  File "C:\projects\hg\mercurial\demandload.py", line 30, in module
    self.fromlist)
  File "C:\projects\hg\mercurial\mdiff.py", line 9, in ?
    import struct, bdiff, util, mpatch
ImportError: No module named bdiff

See the mail list thread "Fix the path problem on Windows..." but essentially Python on Windows ends up with the current directory automatically added to the python search path before the site libraries. So if you run hg in its own repository python gets confused, and can't find the extensions needed. There is a candidate patch that removes the current directory, but there is an arguably better workaround from K.Thananchayan. Simply add a registry entry (replacing 2.4 with the version of Python)

 HKLM/SOFTWARE/Python/PythonCore/2.4/PythonPath/XXX
   (Default) REG_SZ "YYY"

Mercurial now includes support for cloning with hardlinks on Windows. However for this to work, your filesystem needs to support them (i.e. NTFS) and you need the win32 API extensions documented above. If you have a filesystem that does not support hardlinks or don't have the win32file module, mercurial clone will still work just fine - but you won't get the benefits of hardlinking of course.

For versions of Mercurial prior to 0.7, Mercurial won't realise that it has to 'break' hardlinks.

The upshot is that if you have repositories cloned with hardlinks you must not use pre-0.7 versions of mercurial on them (either the source or the destination clone), or use a version of python without win32file. If you do you are likely to get corruption.

A simple solution to break the hardlinks is to copy (using xcopy or File Explorer) one of the repositories, deleting the clone. Copying it back afterwards.

Default editor

The default editor for commit messages is 'vi'. The Windows installer creates a mercurial.ini that sets it to notepad. You can set the EDITOR (or HGEDITOR) environment variable to specify your preference or set it in mercurial.ini:

[ui]
editor = whatever

WindowsInstall (last edited 2013-07-19 10:57:21 by rcl)