RFC: Managing Mercurial Repositories Remotely

Chuck.Kirschman at bentley.com Chuck.Kirschman at bentley.com
Tue Feb 19 17:45:23 CST 2008

I agree with Peter that we'd prefer the remote .hg to copy.  We use
hooks for permission information, bug tracking, etc., and they will just
work based on the name and location of the repository if we copy the
.hgrc.  Just putting a clean repo up with hg init will not use our
server mechanisms correctly.  We could probably make it work if there is
a server-side hook called that knows the location of the new repository
so we can dig up the information, but it would be more convenient if it
just pulled it over.  Also, we host collections of repositories in
different subdirectories under the server.  So we either need to be able
to specify the subdirectory, or specify another repository in the
collection in order to put it in the right place.

-----Original Message-----
From: mercurial-devel-bounces at selenic.com
[mailto:mercurial-devel-bounces at selenic.com] On Behalf Of Jesse Glick
Sent: Tuesday, February 19, 2008 6:03 PM
To: mercurial-devel at selenic.com
Subject: Re: RFC: Managing Mercurial Repositories Remotely

Peter Arrenbrecht wrote:
> I think rinit should still reference an existing repo, if only to
> know which hgrc to link to

I must be missing something. Why do you need anything in the remote 
.hg/hgrc at all?

Copying hooks from an existing repo could be useful, though in a lot of 
such cases I would think you would need to edit the configuration 
anyway. For example, even if I wanted the notify extension to be used in

a new clone, I would likely not want the same email mapping as the

> The reason I wanted to support mq on the server was for allowing easy
> web review of patches maintained in a queue.

Again I must be missing something. Why can't you just link to the actual

patch (in the queue repository as browsable by hgwebdir)?

Regarding rinit, you could express this alternately as

$ hg rclone -r null $any-repo-at-all $new-repo

Mercurial-devel mailing list
Mercurial-devel at selenic.com

More information about the Mercurial-devel mailing list