Hg server replication

[David Frascone]

I've been considering a similar situation.  We have a repo on a nfs drive.
And, nfs is not as high-performance as I'd like.

So, I'd like to move the repo to a hard disk, but, whenever anyone pushes to
it, I'd like it to push a copy to the repo on NFS.  (Or, trigger the NFS
server itself to pull a copy over http -- which would be much faster)

Is there any easy way to do this?  The HD repo would be the only one pushing
to the NFS one, so there aren't any merge issues to deal with.

-Dave

On 11/6/07, Wing Choi <Wing.Choi at sun.com> wrote:
>
>
> 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
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
>


-- 
David Frascone

Oxymoron: Safe Sex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20071106/55dae8de/attachment.htm