Talk:Mercurial

This is a talk page.
Please be polite and assume good faith. Personal attacks will not be tolerated.
Please DO NOT use this page to ask support questions. This page is for discussing the article only.
Please sign and date your comments by typing four tildes (~~~~) at the end.

Completing Step 1 - easy_install docutils

I found that this command does not work as-is due to restricted permissions on the /usr directory. Instead, I would change the order of the steps a bit:

• Update the .bash_profile and .bashrc files with the PYTHONPATH and other variables first.
• If ~/lib/python does not exist, create it

   mkdir -p ~/lib/python

• Install docutils

   easy_install --install-dir=~/lib/python docutils

Reorganize the article

I feel the organization is a little confusing because it mixes the restrict access and the html authentication. I feel it's confusing because you can also work with SSH and restrict the access (or letting read-only access). Those two parts has nothing to do with the html part of the Securing your Repositories.

I propose something like:

• Securing your repositories
• Publishing repositories
  • Through HTML authentication
  • Shared SSH access

--Pablo Olmos de Aguilera Corradini 00:56, 2 February 2010 (UTC)

Python 2.3 issue

For some reason, Python 2.3 is the default version of Python on my server. 2.4 is installed (the highest version actually) and it results in me having to edit all shebang files (and a line in the makefile) or make a symlink in a local bin directory to python2.4, which still needs the hgweb.cgi file to be edited to point to the correct python. --Miquelfire 14:18, 1 October 2010 (UTC)

Isn't it much easier just to use easy_install?

I think the article makes it much more complicated than needed.

Is there any good reason why a user shouldn't simply do something like:

mkdir -p ~/local/site-packages
easy_install --install-dir ~/local/site-packages/ mercurial

NB. I got the idea from: http://mitchfournier.com/2010/06/25/getting-started-with-virtualenv-isolated-python-environments

Spk 03:02, 8 November 2010 (UTC)

It's not possible AFAIK because you don't have a real PYTHONPATH. In fact, after executing those steps you get an error:

TEST FAILED: /home/asd_user/local/site-packages/ does NOT support .pth files
error: bad install directory or PYTHONPATH

There are some workarounds here, but they say it isn't stable. The virtual python solution works, but it's harder and longer. I'll post it on the wiki when I upgrade the article to 1.7.--Pablo Olmos de Aguilera Corradini 17:13, 8 November 2010 (UTC)

Ah, I took care of that error message by adding the following line to my ~/.bash_profile :

export PYTHONPATH=$PYTHONPATH:$HOME/local/site-packages

I also created ~/.hgrc and added the following two lines to it (replacing "John Doe" with my desired username and "john@example.com" with my email address):

[ui]
username = John Doe <john@example.com>

With that done, do you see any reason not to use easy_install? Spk 18:48, 9 November 2010 (UTC)

OK, it seems that some or all of my suggestions above may not work for everyone. Indeed, they may not even have been working for me. Part of the reason I thought they were working is that my Dreamhost PS already had Mercurial 1.0.1 installed, which I only discovered when troubleshooting my suggestions at the very reasonable request of Pablo Olmos de Aguilera Corradini. The rest, I'm still figuring out... Spk 22:32, 12 November 2010 (UTC)

Something very weird is happening on my Dreamhost PS. I stripped out all local Python related config from my user account, including removing any lines pertaining to Python (e.g. re: the $PATH or $PYTHONPATH variables) from my ~/.bash_rc and ~/.bash_profile, and then logged out and in again so that as far as its Python setup goes, my account was essentially virginal.

Running

which hg

produced:

/usr/bin/hg

and running

hg --version

produced:

Mercurial Distributed SCM (version 1.0.1)

Copyright (C) 2005-2008 Matt Mackall <mpm@selenic.com> and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Then I added

export PYTHONPATH=$PYTHONPATH:$HOME/local/site-packages

to my ~/.bashrc (which is now sourced from my ~/.bash_profile), and ran:

source ~/.bash_profile
mkdir -p ~/local/site-packages
easy_install --install-dir ~/local/site-packages/ mercurial

After doing this, running

which hg

still produced:

/usr/bin/hg

but running

hg --version

instead produced:

*** failed to import extension hgext.imerge: No module named imerge
*** failed to import extension hgext.inotify: No module named inotify
Mercurial Distributed SCM (version 1.7)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2010 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm at a loss to explain this inconsistency, and would be grateful for advice. Spk 22:54, 12 November 2010 (UTC)

OK, so with the help of some of the folks on the Mercurial IRC channel, I now understand the apparent inconsistency mentioned above.

The file at /usr/bin/hg turns out not to be a binary file at all (despite being in /usr/bin/), but rather a very short Python script with an "import hg" line. Before installing the latest version of Mercurial using easy_install and adding that to my $PYTHONPATH, the script at /usr/bin/hg imported the system-wide hg package, which happened to be version 1.0.1. After I'd installed Mercurial using easy_install and added its directory to my $PYTHONPATH, it instead imported the new version, which happened to be 1.7. In order to prevent "which hg" from returning "/usr/bin/hg" and thereby giving me the false impression that I was using a system-wide Mercurial package, all I needed to do was add "export PATH=$HOME/local/site-packages:$PATH" to my ~/.bash_rc and then run "source ~/.bash_profile"

So far, this is all satisfactory, but running "hg" produced "failed to import extension" errors. Apparently this is because when Mercurial is installed system-wide on Debian systems like Dreamhost's, a system-wide hgrc file is present that ends up being called whenever a user invokes the "hg" command. It gets called even if a user has a local copy of Mercurial that is much more up-to-date than the system-wide version. Version 1.0.1, the system-wide version on my server, was packaged for Debian with an hgrc file that called some Mercurial extensions that are now obsolete. Because they're obsolete, Mercurial 1.7 (for instance) can't find them, hence the errors. The only workaround seems to be to override the system-wide hgrc file with a local ~/.hgrc file containing lines like "hgext.imerge = !" in the "[extensions]" section.

Additionally, a helpful person on IRC suggested (yet) another way to install Mercurial locally, as long as there's a system-wide install available that's not totally ancient, so here it is, as an alternative to the easy_install method I've given above:

hg clone http://selenic.com/repo/hg#stable ~/local/hg-stable
cd ~/local/hg-stable
make local

Then add ~/lib/hg-stable to your $PATH. (You don't need to add it to your $PYTHONPATH; running "make local" already automagically took care of that.) Handle any "failed to import extensions" error messages as described above.

To upgrade to the latest stable version of Mercurial, simply:

cd ~/local/hg-stable
hg pull -u
make local

I rather like this. It's simple and elegant. Spk 04:46, 13 November 2010 (UTC)

building mercurial

I found that you don't need to comment out the doc parts in the makefile if you have docutils installed. To install I did the following:

1. downloaded docutils and untar docutils
2. setup.py build
3. setup.py install --prefix $HOME
4. edited my $PYTHONPATH in my bashprofile to point to where the docutils module is.

no errors occurred building mercurial happened after that. These site were sites I used as reference points:

• http://wiki.dreamhost.com/Trac_Installation
• http://groups.google.com/group/django-users/browse_thread/thread/e35f1fcacc07b051/f2fa1ed34d3ec514?lnk=gst&q=dreamhost

Another method using Virtualenv

Another method of install Mercurial locally. This may not be perfect, but all the basics work (for me). I am a total beginner with hg (just started today) so these instructions may bite you down the road. I putting here on the talk page until someone else verifies it works for them.

1. install Virtualenv using the dh wiki instructions on Python#Virtualenv. This symlinks python stuff to your ~/local folder so module installation is by defaul local. It's nice. You'll have to find the latest version and change the version numbers in the install instructions yourself.

(see instructions there, not repeated here) (see note about hg's make install-home below)

2. edit your .bash_profile (or .bashrc which I source in my .bash_profile) to add

export PATH=$HOME/local/bin:$PATH
export PYTHON_PATH="$PYTHON_PATH:/home/billspat/local/lib/python2.5/site-packages"

( I don't know if PYTHON_PATH is necessary with Virtualenv)

2.5 re-source this to get new path

$source .bash_profile

3. use easy_install. yup it works, thanks to Virtualenv

easy_install docutils
easy_install Mercurial

4. Config with .hgrc At this poing 'hg' will spout warnings for missing extensions. I couldn't get them installed, so I turned them off. Do we need them? I don't know. To do so, edit .hgrc. Also add your user name while you are at it

.hgrc

[extensions]
hgext.imerge=!
hgext.inotify=!

[ui]
username = First Last <email@host.com>

5. test

hg init hg-test
cd hg-test
touch hg-test.py
hg add hg-test.py
hg commit -m "initial commit of hg-test"
hg history

Notes: If you follow the instructions for downloading Mercurial and as part of that do

   make install-home

will install mecurial to $HOME/bin and $HOME/lib but I wanted to use $HOME/local/bin and $HOME/local/lib as that's what Virtualenv uses (and all my ruby stuff uses that too). Using easy_install put it in this ~/local/lib folder (thanks to Virtualenv I guess).

billspat Oct 3 2011