RFC: Managing Mercurial Repositories Remotely

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Tue Feb 19 16:42:06 CST 2008

On Feb 19, 2008 8:16 PM, Jesse Glick <jesse.glick at sun.com> wrote:
> Peter Arrenbrecht wrote:
> > This is a somewhat lengthy proposal for an extension that supports
> > running a limited set of hg commands server-side.
> This would be very welcome. Having to rely on a human admin, or custom
> admin scripts, just to create new clones on the server is a pain.
> > == hg rclone et al. ==
> However I am confused at the plethora of commands. To my mind, there are
> only two primitive commands which must be supported:
> * hg rinit $name (~ ssh server hg init $name)
> * hg rdrop $name (~ ssh server rm -rf $name)
> (An admin might want to disable the rdrop command or change it to move
> the repo to a "junk" directory.)

Good point about rinit. Shall add it. But I think rinit should still
reference an existing repo, if only to know which hgrc to link to, and
for establishing rights etc. So it would be

  hg rinit https://host.org/hg/main new

Same as rclone really, only does hg init instead of hg clone.

> If you can create a new repository on the server, you can prepare
> whatever content for it you wish on your own local disk using regular Hg
> commands, and then push in the desired changesets. As a concession to
> performance, especially for people with limited upload bandwidth trying
> to clone very large repositories, it would be good to add
> * hg rclone -r $rev $old $new (~ ssh server hg clone -r $rev $old $new)
> since otherwise you would have to upload megabytes of history which the
> server already has in an existing repo.

Precisely. This is already done. As is rdrop.

> Everything else you can do locally given the existing network operations
> of clone, pull, and push. This does not apply to MQ operations, which
> involve nonmonotonic changes to history, but I don't really see what you
> need to do with MQ on a server other than create a versioned patch
> queue, which is possibly simply with
> $ hg rinit existing-repo/.hg/patches
> $ hg -R .hg/patches push http://server/existing-repo/.hg/patches

I know. But rqinit can use more cleverness as to which hgrc to set up,
and for security reasons I think it wise to forbid rinit or rclone to
general paths. I only allow them to a sibling in the same parent dir
as the cloned repo. And I specifically deny requests where there is a
.hg in the path. This to ensure no one can mess with any hg internal
data. See my proposed implementation. And I'd be happy if any security
holes were spotted early. :)

The reason I wanted to support mq on the server was for allowing easy
web review of patches maintained in a queue. Such a repo should, of
course, not be cloned from, only the queue repo. But the submitter
could easily push new queue states and then remotely update the
underlying repo to submit fixes and have them reviewed again. If we
take this one further, it could form the basis for integration into
something like reviewboard.

But I'll definitely go for keeping the mq part separate from the rest
as it does add a whole lot of clutter, and a dependency on mq to boot.

Any comments on the hgrc symlinking scheme? Could be I'm touching a
sore spot again there. ;)


More information about the Mercurial-devel mailing list