RFC: Managing Mercurial Repositories Remotely
Peter Arrenbrecht
peter.arrenbrecht at gmail.com
Thu Feb 21 01:03:48 CST 2008
On Wed, Feb 20, 2008 at 10:57 PM, Jesse Glick <jesse.glick at sun.com> wrote:
> Peter Arrenbrecht wrote:
> >>> The reason I wanted to support MQ on the server was for allowing
>
> >>> easy web review of patches maintained in a queue.
> >>
>
> >> Why can't you just link to the actual patch (in the queue
> >> repository as browsable by hgwebdir)?
> >
> > That does not give me annotate or, if hgweb ever supports it, diffs
> > with more context on the patched files [...for use in] reviewboard.
>
> I still don't get it. Running MQ commands on a remote repository seems
> like a terrible idea to me. If you just have your "real" remote
> repository which people develop as usual, and a remote patch queue
> repository which people can also push into, then all your information is
> available.
Available: yes, easily reviewable online: I think not fully. But let's
drop this for the moment. I'll experiment and gain experience with
this a bit more and report back if after that I still think it is a
good idea.
> If you want Reviewboard or any other web-based tool to be able to
> display a patch in the context of unmodified lines or files, it can
> simply maintain a private local clone of both repositories and use
> regular local MQ commands to calculate the appearance of patches in
> context. Such a server could decide either to have one MQ-managed local
> repo and serve only one web request at a time (running e.g. 'hg qgo &&
> hg qdi'), or maintain a pool of such repos to permit concurrent display
> of different patches, or run a background process to push patches and
> cache displayable information resulting from them, ad nauseam - none of
> which would be safe or efficient if it had to make remote calls.
Agreed.
-peo
More information about the Mercurial-devel
mailing list