According to the "Creating repositories" at http://dev.lshift.net/paul/mercurial-server/docbook.html all we need to do to create new repository - is to clone not existent one.
But in 1.1 I doesn't work. And if we look at code:
if cmd is None:
fail("direct logins on the hg account prohibited")
elif cmd.startswith('hg -R ') and cmd.endswith(' serve --stdio'):
repo = getrepo("read", cmd[6:-14])
if not os.path.isdir(repo + "/.hg"):
fail("no such repository %s" % repo)
dispatch.dispatch(['-R', repo, 'serve', '--stdio'])
elif cmd.startswith('hg init '):
repo = getrepo("init", cmd[8:])
if os.path.exists(repo):
fail("%s exists" % repo)
d = os.path.dirname(repo)
if d != "" and not os.path.isdir(d):
os.makedirs(d)
dispatch.dispatch(['init', repo])
else:
fail("illegal command %r" % cmd)
we can see, that to create we need to pass specifically init command.
This command works as expected:
"TortoisePlink.exe" -ssh -2 hg#mercurial "hg init tst"
but I hope it is some more elegant command to do so.
Well, is it a "bug" in documentation or am I doing something wrong?
UPDATE:
My question is only about creating repositories remotely using mercurial-server.
UPDATE 2:
It was my misunderstanding, since it was not clear for me that there should be already created local repository, that will be cloned remotely.
I find it very straightforward to create a new repo using Mercurial-server. Assuming that you have the rights and that the path "/dir1/dir2/" already exist on the server, simply (using command line):
mkdir new
cd new
hg init
hg clone . ssh://hg#server/dir1/dir2/new
Cheers,
Christophe.
The page you reference is for sharing existing repositories, not specifically for creating new, empty ones. The command you give hg init tst is correct for initializing a new, empty repository. I think the only 'inelegant' thing about it is that you are doing it remotely and thus need to give the additional ssh commands. The repository creation command itself hg init is quite simple.
Related
I need a mercurail template/keyword "hostname" to get the name (or IP) of the computer where the repo is located. as far as i read the wiki, namely "Chapter 11. Customizing the output of Mercurial", hg help templates, and the web, I think it should be similar to the date keyword, dynamicly expanded. How can i define my own template/keyword?
Thank you verry much
The following extension should do the trick:
from mercurial import templatekw
testedwith = "3.5"
_ipname = None
def showipname(repo, ctx, templ, **args):
""":ipname: String. The hostname of the machine that the repository
resides on."""
import socket
global _ipname
if not _ipname:
_ipname = socket.gethostname()
return _ipname
def uisetup(ui):
templatekw.keywords["ipname"] = showipname
Then use (say):
hg log -r . -T '{node|short} at {ipname}\n'
Note that the value of socket.gethostname() may depend on your internet connectivity. If you need the value in /etc/hostname or something else that identifies your machine, use that method instead.
To use an extension, put it in a file, say ipnametempl.py somewhere, then add the following lines to your .hgrc:
[extensions]
ipnametempl=/path/to/ipnametempl.py
This can be either your user/global hgrc or the .hg/hgrc in your repository (the latter if you only want to enable it for a specific repository). See hg help hgrc to find out where the user/global hgrc files are on your system.
Either the repository is local to your machine (then you can get the absolute path via hg root) and query the name via the normal system tools. You can embed those also in your templates:
$ hg log -r. --template="{branch}-{rev} from $(hostname) running debian $(cat /etc/debian_version)"
trunk-22248 from MYHOSTNAME running debian 8.2
Or you know already the URL (remote path) in order to operate with it as you need to specify it as argument to hg pull/clone/outgoing/incoming
If the remote URL is not explicitly specified on the command line it is specified in your .hgrc in the [path] section. When there is a remote repository at all, then usually a default = URL is defined there.
If you need the URL printed, then install hooks for clone, pull and push (and maybe outgoing and incoming) which prints the $URL as available in those hooks - or maybe just the changegroup hook. Check http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html#sec:hook:changegroup and hg help config.
We have 500 plus Hg repositories and am looking for a quick and efficient want of backup. Is there a script or Tool that we can use to backup these repositories. We tried Hg bundle, hg clone and regular file system backup but they are not helping.
Is there a standard practice, or some documentation for Hg repositories backup policy?
A follow-up question, what will happen when a user is in a middle of pushing the changeset and we start the backup ?
We do use RhodeCode to publish the Hg repositories.
Thanks
There's no standard. A true FS-level snapshot taken during a push will be fine, but a non-instantaneous mirroring operation (recursive copy) could end up with a corrupt repo, though it would be repairable to the pre-push state.
In the past I've done something as simple as:
for repo in $(find /srv/repos -type d -name .hg | sed 's/\.hg$//') ; do
hg --cwd $repo --repository $repo push ssh://backupserver/$(basename $repo)
done
That pushes all repos to a remote ssh server, incrementally, with full updating-while-pushing integrity, creating them if necessary.
I have a somewhat similar solution of cloning/pulling from a backup server but I trigger the backup on an hg hook.
In the main server global hgrc, I have:
changegroup.backup = .../backup.sh
and in backup.sh something like:
REPO=`hg root`
ts sshpass -p '...' ssh hg#backupserver "~/bin/pull.exp $REPO" 2>> $LOG
Ts (task spooler) allows the operation to happen asynchronously. The expect script is handling the fact that the repository might be new (thus performing an hg clone --noupdate) or already existing (thus performing an hg pull) and also can give the ssh key a passphrase when requested.
Pushing on the second server is only allowed for the backup hook, so no issue of multiple heads or needed force can happen.
What I find interesting in this type of real time backup is that in case of crash of the main server, it should be much faster to switch to the backup one.
Hosting Mercurial on a windows box thru IIS.
I have a root directory where I put all of my repos
d:\repos
- ProjectA
- .hg
- hgrc
- ProjectB
- .hg
- hgrc
- ProjectC
- .hg
- hgrc
All of the repos' hgrc files setup the notify extension with:
config =d:\hg\Repositories\NotificationList.txt
That way I have a single file to manage all of the notification recipients, like the wiki describes:
https://www.mercurial-scm.org/wiki/NotifyExtension
But the wiki makes mention of controlling that NotificationList.txt file thru it's own repository? How can I do that? If I create a separate repo at d:\repos\HgNotify and have the NotificationList.txt file in there, users can change, commit and push back, but when the push occurs, NotificationList.txt does not get updated on the hg server.
Is there a way to update that file somehow? Am I missing a key setup on my Hg server? Or do I need to use a post-push hook to deploy that file?
Update 1
I added the details from Tim's answer and I kept getting HTTP 500: Server Error on the push. I finally figure out how to trace the python calls (python -m win32traceutil), and here is what seems to be the problem:
File "C:\Python27\lib\site-packages\mercurial\util.py", line 402, in hgexecutable
exe = findexe('hg') or os.path.basename(sys.argv[0]) AttributeError: 'module' object has no attribute 'argv'
It doesn't seem to be able to find hg.exe.
Update 2
I installed TortoiseHg and rebooted the system. Now I get:
emote: added 1 changesets with 1 changes to 1 files
remote: notify: sending 1 subscribers 1 changes
remote: warning: changegroup.update hook exited with status 1
So that makes be think that it has found the hg.exe, but it is not doing its job, because the file does not get updated
Update 3
Found my solution here: https://stackoverflow.com/a/8023594/698
The command line I ended up using was:
changegroup = cmd /c hg update
I also added:
[ui]
debug=true
To my hgrc. Those two combined gave me a lot more meaningful messages. In the end I saw "Access denied". I gave Users full permission, but I am not sure why giving IUSR full permission didn't work. Something I'll have to dig into at a later time.
On the server repo containing your notification list you need to add a changegroup hook:
[hooks]
changegroup.update = hg update -C
or if you want to ensure the repository is always clean:
[extensions]
purge =
[hooks]
changegroup.update = hg update -C && hg purge --all
We are starting to use Mercurial for source control. We have configured the HGRC configuration file to do an auto update after we push to the "central" repository.
With some PCs we get this error msg:
warning: changegroup hook exited with status -1
HGRC looks like this:
[ui]
username=ADMIN
verbose=true
[hooks]
changegroup = hg update >&2
Later we perform the update manually and everything works right.
I had a very simmilar issue. This finally works now:
changegroup = cmd /c hg update
The bold cmd /c causes cmd.exe to spawn which will execute hg update as we want it to, but now the exit value from cmd.exe will be 0.
Longer Story:
setup: win 2008 server.
mercurial 1.9.3
hgwebdir via plain http, its an internal network
error:
my error was funnily not the -1 as in your case but
"warning: changegroup hook exited with status 1"
Anyway, the update was not performed.
I found out that I can put the hooks into either .hgrc or into hgweb.config the problem was the same here or there. I finally put it into hgweb.config as below, so all repositories are auto commiting, which is way better than having this loose branch all the time. The main reason I wanted auto commit is that the respositories on the vcs & build server hold now the latest version which makes admin tasks often simpler.
[web] push_ssl = False allow_push = *
[collections] c:\Dev\Reps = c:\Dev\Reps
[ui] debug=true
[hooks] changegroup = cmd /c hg update
It might be related with the user actually executing the hook, which might not be the one with the correct privileges.
Do you have a IIS webserver managing your Mercurial repos?
(from the thread:)
From experience with Mercurial/IIS, things I'd recommend trying:
(a) Does running a simple non-HG command work? Permissions on cmd.exe will
affect out-of-process python hooks.
(b) Does a simple hook like 'python -c "import sys; sys.exit(0)"' work?
(c) If you make it this far, can you confirm that the process is running as the
user you think it's running as, with a hook that does something like:
import win32api
username = win32api.GetUserName()
(write username to a file so you can read it)
I've seen a number of blog posts, and have experienced for myself, that Mercurial does not preserve the permissions on files pushed from one repo to another. Does anyone know of a Mercurial extension that would preserve the permissions? I'm assuming it can't be done with a hook, because what does a hook know about permissions at the originating repo?
Requested elaboration:
If the only change to a file is a change in permissions (e.g., chmod o+r filename), attempts to commit the file fail with a message saying that the file has not changed.
If I commit a file with permissions 600 (rw-------), then clone the repo, the same file in the clone has permissions 664 (rw-rw-r--):
: nr#yorkie 6522 ; hg clone one two
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
: nr#yorkie 6523 ; ls -l one two
one:
total 4
-rw------- 1 nr nr 8 Aug 18 21:50 foo
two:
total 4
-rw-rw-r-- 1 nr nr 8 Aug 18 21:51 foo
This examples shows that hg clone does not preserve permissions, but hg push does not preserve them either.
In my application, one repo is on a publically accessible path, and it's of major importance that
Multiple users have the right to change the repo
Files in the public repo become readable only when explicitly made readable.
It looks like it can be done using hooks and an auxiliary tool (and a little chewing gum and baling wire):
Get David Hardeman's Metastore, which saves and restores file metadata.
Alter the sources so it will ignore directory .hg as well as .git.
Use the following Mercurial hooks:
precommit.meta = metastore -s
changegroup.update = hg update
update.meta = /usr/unsup/nr/bin/metastore -a
You have to add the .metadata file to the repo.
This lashup will work most of the time, but if you change only permissions and want to propagate it, you'll have to run metastore -s in order to push those changes into the .metadata file where hg will see the change; otherwise the commit thinks nothing is new.
What about using this solution from the Mercurial FAQ:
If you're using Mercurial for config
file management, you might want to
track file properties (ownership and
permissions) too. Mercurial only
tracks the executable bit of each
file.
Here is an example of how to save the
properties along with the files (works
on Linux if you've the acl package
installed):
# cd /etc && getfacl -R . >/tmp/acl.$$ && mv /tmp/acl.$$ .acl
# hg commit
This is far from perfect, but you get the idea. For a more sophisticated solution, check out etckeeper.
For the specific case of the /etc directory, etckeeper looks interesting.
I assumed that metastore was abandonware due to the dead git link on author's site so I whipped the below which is placed directly in repo's .hc/hgrc configuration file:
[paths]
default = ...
[hooks]
# NOTE: precommit is different than pre-commit, see https://www.mercurial-scm.org/repo/hg/help/hgrc for list of hooks
pre-commit =
# export permissions
hg st -camn0 | sort -z | xargs -0 getfacl > .hg.hook.pre-commit.acl.export
hg add .hg.hook.pre-commit.acl.export
# export timestamps
hg st -camn0 | sort -z | xargs -0 stat > .hg.hook.pre-commit.stat.export
hg add .hg.hook.pre-commit.stat.export
update =
# import permissions
setfacl --restore=.hg.hook.pre-commit.acl.export
# import timestamps
# TODO: use touch to restore timestamps
It is not good idea to store permissions in VCS. However, Mercurial supports "executable" flag (that is not the same as permissions, although in Unix executable flag is part of permissions).