Hg server replication
Wing Choi
Wing.Choi at Sun.COM
Tue Nov 6 20:13:08 CST 2007
Ah, some further details to clarify.
Actually, I am interested in having 2+ servers that contain
exactly the same transactions ( no two heads obviously ) that
are distributed geographically both for redundancy and faster
turn around time (due to network latency and remoteness of
each of the distributed network segment). So users from each
location would use their own closest server(s) to clone from
and also push back into. However, each server must be in sync
with each other and so the txns from one will likely somehow
be pre-reserved and replayed on either a master server or
all of the other servers.
In case of a missing server, the user will then have a choice
to manually switch to another replicated server.
thus spake Dustin Sallings on Tue, Nov 06, 2007 at 06:03:27PM -0800:
>
> On Nov 6, 2007, at 16:10 , Wing Choi wrote:
>
> >I am looking at some kind of way to let me replicate an
> >Hg server so that pushes from a downstream client get
> >replicated automagically for 2+ upstream servers.
> >Ideally, this must be able to take on possible collisions from
> >2+ downstream clients pushing conflicting changesets.
> >
> >are there some sort of precommit hooks that can achieve this?
>
>
> It can be done, but you're probably asking for more than you think
> you are.
>
> Do you want to allow multiple heads to be created? I'd assume not,
> so you'd need to force a merge after a commit (you really want to
> allow people to commit before breaking their trees).
>
> By having more than one upstream, you'd really need to get a merge
> that would make all of these servers happy, but there's no two phase
> commit. Each user ends being responsible for making sure that each
> upstream contains a singly-headed view of everything each user has seen.
>
> You also have to consider what happens if one of these upstreams is
> unavailable (which is really a desirable state since decentralization
> means we can work under suboptimal conditions).
>
> --
> Dustin Sallings
>
>
--
Nothing is really work unless...
you'd rather be doing something else
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 477 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial/attachments/20071106/b37474fe/attachment.pgp
More information about the Mercurial
mailing list