RFC: Managing Mercurial Repositories Remotely

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Wed Feb 20 14:04:51 CST 2008

On Wed, Feb 20, 2008 at 12:20 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> Peter Arrenbrecht wrote:
>  > This is a somewhat lengthy proposal for an extension that supports
>  > running a limited set of hg commands server-side. Comments welcome.
>  I'm sorry, but I think it's all a little weird. For one thing, you can
>  already clone to remote over ssh.

Yes, but this is precisely for setups without ssh access. Only https and http.

>  For the other, I think creating new
>  clones through http is just plain weird. I think something like what
>  hgserve is going to be makes more sense for that, because it has more
>  focus. Managing directories on a server through a version control tool
>  feels a little strange to me.

Hmm. Repos, more like. Clones of repos, in fact. That does not sound
so unrelated to me.

Any details on hgserve's future you can point me to?

>  Finally, it seems at least some of your issues could be solved if it was
>  easier to collaborate from named branches to cloned branches and back.
>  I.e. you can clone/pull just-one-branch from a repo containing multiple
>  branches and push a cloned branch into a named one in the remote repo. I
>  think that approach makes more sense.

Wouldn't that basically just address bandwith issues? After all, if
disregarding size, I might as well just clone the whole thing and work
on the named branch I'm interested in. And I suppose the difference
between cloning a few parallel branches vs. just the branch I want is
not often going to be very noticeable compared to overall repo size.

More importantly, though, I have mainly the review scenario in mind. I
think patch review on a devel list has a lot of merits, but also a few
drawbacks. The fundamental one is that, depending on your mail client,
it can be cumbersome to get a patch into a temporary review repo. You
might want to do that to

-  get more context for diffs,
-  open a modified binary file with its native app (yes, we have .xls
files in our repo),
-  run tools or tests on the patched state.

So what I want is a quick way to set up a temporary repo, push my
current work in there, and let people review. Since I usually use mq,
these repos are *not*stable*. You should not clone from them to
anywhere but maybe a local throwaway review repo. This gives

- a quick way to look at my changes without installing anything
(unlike sending bundles),
- a more sophisticated GUI for that quick look at my changes (files
overview, annotate, etc.),
- a quick way to pull my stuff into a local throwaway review repo
(unlike mail patch bombs).

Now if I could not only cheaply push my current state to a temp review
repo, but could cheaply create a review repo with versioned mq, then I
would give reviewers even more info. They would have the snapshot of
the latest state, and by looking at .hg/patches, they could see
history and changes to the patches, likely in reaction to issues the
reviewers brought up.

I guess the easiest approach to this would be to configure hgrc-rqinit
with hooks that automatically qpop -a, qpush -a on incoming
changegroups. Then there is no need for explicit mq commands in rexec,
and no dependency on mq as rqinit can be done as a simple `hg init
.hg/patches`, as Jesse pointed out.


More information about the Mercurial-devel mailing list