live-mirroring of repository

[Lasse Kliemann]

Gregory Szorc <gregory.szorc at gmail.com> writes:

> Second, and more importantly, I wouldn't put too much faith in a simple
> dual-master setup like this. A proper solution requires complicated and
> coordinated locking between masters.
>
> The "changegroup" hook fires *after* the local repository has committed the
> push transaction to storage. Unless there is locking to prevent
> simultaneous pushes, there will always be a race condition between 2 pushes
> to the different masters. If they each manage to locally commit the
> transaction, you now have 2 repos that think they are correct and there is
> no way to reconcile the changes without rewriting repository history
> (assuming pushes to the same head). And one of the pushers will likely get
> angry if you do that.

It appears to me that you are looking at it from the Git/Subversion
angle. With Mercurial, I do not see this kind of problem. Pushing with
Mercurial merely means "announcing a changeset". This does not carry any
race conditions, since the changeset refers to other changesets by a
unique ID. Note that I'm using the "-f" option to push, which means:
grow a new head if necessary. (Caution on terminology: git head != hg
head; I'm always using "head" in the hg sense here, which means: a
changeset without any descendants.) So changes need not to be reconciled
before the push; this can be done later by anyone with access to the
repo, since anyone can see the new head.

In Git, there are also unique IDs, of course, but there we have this
"ref"-thing. A push has to change an existing ref or create a new one,
but the latter cannot happen in such a (nice and) transparent fashion as
with Mercurial, where we just *see* the new head, even if it is not
accessible by a branch name or whatever.

Some more advocacy: With Mercurial, a user can *just* *push* without
running the risk that any data is lost (even though "push -f" is
described as a "forced push" in Mercurial, it has not much in common
with a forced push in Git, which actually can cause havoc). With Git,
changes have to be reconciled before a push (or a new branch name has to
be invented). This makes it similar to Subversion in this respect, where
one has to run an update (with a possible merge or conflict resolution)
before being allowed to commit. To me, this makes Mercurial the only
*truly* distributed VCS.

Those problems that I was actually experiencing -- to the best of my
knowledge -- were deadlocks caused by the way locking of repositories is
done during push in Mercurial. That's on a more technical level than
those other issues discussed above. My workaround is: timeout soon,
retry often, and wait a random number of seconds between attempts. It's
not pretty, but it works astonishingly well and to my full satisfaction.

Thanks anyways for sharing your thoughts. It made me rethink the whole
construction a couple of times more. I believe it is ok now.

Regarding your comment on bookmarks and phases: I'll keep it in
mind. Currently, we're not using those features, so it will not be a
problem.

-- 
Kind Regards / MfG
Dr. Lasse Kliemann
Westring 269, 24116 Kiel, Germany
E-Mail: lasse at lassekliemann.de
OpenPGP Key: 0x4296A3E08903D018
Phone: +49 162 66 88 468
Web: http://lassekliemann.de
 
Work Address:
Department of Computer Science
Kiel University
Christian-Albrechts-Platz 4
24118 Kiel, Germany
E-Mail: lki at informatik.uni-kiel.de
Phone: +49 431 880 7454
Web: https://www.informatik.uni-kiel.de/~lki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150506/4115bb8e/attachment.asc>