On Sun, Apr 24, 2011 at 7:20 AM, Michael Diers <mdi...@elego.de> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2011-04-21 13:58, Nico Kadel-Garcia wrote: >> On Thu, Apr 21, 2011 at 5:15 AM, Ian Wild <ian.w...@wandisco.com> wrote: >> >>> That sounds like a good translation to me. The maths gets complicated to put >>> it mildly, but I know Dr Yeturu's work is in some part at least based on >>> Paxos ( http://en.wikipedia.org/wiki/Paxos_algorithm ). AIUI we've got the >>> only implementation of this model that can guarantee the consistency and >>> ordering of transactions; important when you need your repositories to >>> remain identical on every site! >>> Ian >> >> *NOTHING* can guarantee this.. This is key to the difficulty of the >> "merge" process for multiple branches against a common trunk. > > Nico, > > I believe you misunderstand how the repositories are kept in sync.
There's a fundamental problem that is not mathematical, it is procedural. When the link between active-active servers for any database is broken, *or phase delayed for any reason*, and each database accepts alterations from clients without propagating the change to a fundamentally shared repository, mathematics cannot decide which changes must be merged, in which order. Now, it's certainly possible to bring *down* one of the servers when the connection is broken, and leaver the other active as the primary database server to allow synchronization with the other database later. This is how numerous active-active database systems work, including Oracle and MySQL's systems. But "commits" on Subversion are an atomic operation: you can't go back later and say "no, wait, that one conflicted with a commit on another server, we can't take it". That's what the merge step is for. >> Maintaining two sets of changes on distinct repositories that wind up >> altering the same set of text, or code, in divergent ways cannot be >> guaranteed to be resolved "correctly" by a mechanical process, because >> the process would have to "understand" the discrepancies and resolve >> them. It can be as simple as a copyright notice, whose changes >> represent social information outside the scope of the source control >> system, or code changes in a subroutine in one branch and the handling >> of the error codes generated by that subroutine in a distinct branch. >> >> It may do a much better *job* of this than other tools. That would be >> cool, tricky merges have always been an issue. But mere ordering and >> consistency is not sufficient, overlapping merges require attention. > > While your observation regarding merging is correct, it does not apply > to the replication technique that WANdisco use in their product. > > The network nodes handling the repositories are distributed, but not > isolated. The nodes actively agree on how to apply a proposed change to > their repository replicas, effectively avoiding the merge problem. Single mirrored backend database, synchronizatoin protected some sort of locking mechanism to prevent simultaneous commits from the multiple "active" front ends. This works well if the backend is a single shared storage system, such as fiber channel, or a an online database which handles turning commit requests into single threaded, atomic operations. But that's not a mathematical data synchronization issue, that's a single threaded locking problem to prevent out of order transactions. > WANdisco provide a well-written White Paper explaining this. > > http://www.wandisco.com/get/?f=documentation/whitepapers/WANdisco_DConE_White_Paper.pdf Just read it. It confirms my description, implemented as a clever set of tools to handle master/slave relationships at high speed on the back end. The "propersers" operate under locking mechanisms handled by the "acceptors", Sadly, it suffers from the same issue as ill considered NTP configuratons. It takes a poll among the nodes to decide whether a transaction number is high enough. I leave it to the rest of the community to decide what happens when you set up a world distributed network with 3 nodes each in 3 different locations, and one of those locations gets its VPN connetions to the other locations blocked. The 3 nodes can go off on their merry way, and the absolutely necessary for Subversion central transaction numbering is *broken* between the two sets of nodes. When, and how, to turn the relevant repos into read-only nodes is left as an exercise in resource management and paranoia. But the potential for fractures and divergence among them is inherent in any network of more than a few nodes, and switching from "active-active" to "active-slave" when the link is broken is begging to set up "slave-slave" for all sorts of confusing scenaries, and breaking the ability to submit code. And cleaning *UP* the mess is horrible if they're not set to "slave" behavior. This sort of thing has been proving problematic for decades, if not centuries. It certainly dates back to religious schisms in Europe, where communications lags lead to the promulgation of prayer books and excitement about being able to cheaply print Bibles to provide unified scripture for priests who'd tend to stray from the teachings of Rome without reliable, written guidelines. In this case, though, instead of a cental "Pope" as a backend Subversion central repository must be, you've allowed any set of bishops who are disconnected by a bad winter or war to set up their own Pope. Using a "Paxos" algorithm does not solve the problem of disconnected nodes, unless you're reliant on hardcoded lists of active servers and are absolutely reliant on a majority of a generous number of pre-defined nodes to be available to provide that "vote". But if you're detached from more than half the nodes, you can only be read-only: nothing else is safe. Wrapping it in a set of equations doesn't fix that. And unless you're very careful, som idiot *will* rewrite local configuraitons to reduce that "half" requirement, and synchronization of the central list of nodes becomes absolutely critical. It's workable, but potentially fragile, and it is an *old* distributed computing problem.
