Accessing configuration of remote repositories

Jonathan S. Shapiro shap at eros-os.com
Wed Nov 28 16:41:02 CST 2007


On Wed, 2007-11-28 at 00:48 -0500, Glenn Ammons wrote:
> I am writing an extension in which each Mercurial repository refers to
> another data store.  When changes are pushed from Mercurial repository
> A to Mercurial repository B, I first want to push any additions to the
> store referred to by A to the store referred to by B.  To do that, I
> need to know where A's store is and where B's store is.

Glenn:

I think that conceptually this is not what you want. First, you probably
want your transfer to obey the same transaction boundaries as the rest
of the operation. Second, you are basically doing an out of band
transfer here, and that seems like a really good way to increase the
likelihood and complicate the diagnosis of connection failures.

Conceptually, it seems like the right model here would be to extend the
wire protocol such that additional information can be sent from the
local extension to the remote extension during the transaction, and then
extend the transaction commit/abort protocol so that all of the
participating "parties" to the transaction get told to commit or abort.

To (possibly) make this clear, the current protocol is doing something
like the following (note: I haven't looked, this is from first
principals).

  1. Establish a transport over ssh or whatever.
  2. Begin a transaction.
  3. Establish a channel between the repo engine on one side
     and the repo engine on the other side.

     At the moment, it would not surprise me if this step is
     implicit.

  4. Let the engines talk. If anybody declares abort, report
     that to both sides and abort.
  5. Commit the transaction.
  6. Tear down the transport.

What I am sketching is that parts [2,3] be generalized to allow multiple
applet pairs to talk within the transaction, and to allow any of the
communicating pairs to abort the transaction for all of them.

I have heard it said that there is desire to generalize the wire
protocol, but I don't know if this would fall within the types of
generalization that folks have in mind.

As to mechanics, I wouldn't be the right person to ask. I'm merely
thinking out loud here. I can, however, think of a bunch of uses for
this particular generalization if it is actually feasible.


shap



More information about the Mercurial-devel mailing list