Hg server replication

[Wing Choi]

I am using svk (with Pushmi) and that is sort of what it does now.
There isn't a lock server, it does a reserve ahead with the primary
(obviously, any other simultaneous push attempts that does not get
the reserve ahead will back off and that/those user(s) will have
to pull and merge b4 retrying the push) and then replay the
transaction over to the primary once the push from the local
client is complete.

How can something similar be accomplished in Hg?


thus spake Dustin Sallings on Tue, Nov 06, 2007 at 07:09:38PM -0800:
> 
> On Nov 6, 2007, at 18:13, Wing Choi wrote:
> 
> >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.
> 
> 	Hmm... I don't think you'll ever be able to keep the servers in sync 
> if people are pushing to them.
> 
> 	The closest you'll get is if you have a distributed lock server that 
> can prevent anyone from pushing anywhere while anyone else is pushing  
> anywhere else.  Otherwise, two different developers can create two  
> children of the same parent and your automated system wouldn't be able  
> to automatically merge in all cases.
> 
> >In case of a missing server, the user will then have a choice
> >to manually switch to another replicated server.
> 
> 	This is perfectly fine for pulls, of course.
> 
> >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
> >
> 
> 
> -- 
> 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/aea4f30a/attachment.pgp