On Wed, Aug 10, 2011 at 8:04 AM, Ulrich Eckhardt
<ulrich.eckhardt_at_dominolaser.com> wrote:
> On Wednesday 10 August 2011, Nico Kadel-Garcia wrote:
>> On Wed, Aug 10, 2011 at 3:40 AM, Ulrich Eckhardt
>> <ulrich.eckhardt_at_dominolaser.com> wrote:
> [..]
>> > 3. connect the repositories
>> > This involves creating a post-commit hook that svnsyncs the changes to
>> > the secondary repository and one for the rev-prop changes, but you seem
>> > to have these set up already.
>> > 4. create a transparent write-proxy
>> > This requires Apache (the rest could be dove with svnserve, too) and
>> > should also be documented. I never made this step though but only the
>> > former three, since the write-proxy wasn't my requirement.
>>
>> Step 3 and 4 *are not enough*. The synchronization would have to occur
>> at the "commit" stage, not the "post-commit", because "commit" has to
>> be atomic with Subversion. Post-commit is nominally allowed to fail
>> without stopping the commit operation. And the only support I've seen
>> for that sort of thing is in Wandisco's "Multi-Site" tool.
>
> I don't think I understand you. Or maybe you don't understand me....
>
> Step three above means that new revisions in the primary repository are synced
> to the secondary repository. I didn't explicitly say that this is a one-way
> operation, but that's what I meant. In no case can you directly commit to the
> secondary repository.
The implication, from the original poster's question and, I thought,
from your response, was that you could do this on the *slave* server,
accept commits there, and push the changes to the master. This is what
I'm raising red flags: resolving potential "split-bran" operations due
to a master server being offline has to be done at the commit stage,
not the post-commit stage.
Since this is not what you meant, I am re-assured.
> Step four is a setup of Apache that simply redirects any write request to the
> primary repository while satisfying read requests from the secondary
> repository mirror.
That's not so dangerous, but potentially quite confusing if the slave
server is out of sync. Picture, if you will:
* Master server has a 4 Gig binary file, a DVD iso image, in
repo/branches/test-repo-1/dist.iso
* Developer 1 commits modified dist.iso on the master server,
revision 1001..
* A post-commit tries to publish the revision 1001 to the slave
server (svnsync operation)
* This takes time due to slow connection, say 10 minutes.
* During that 10 minutes, the slave server cannot report
knowledge about the changes in dist.iso: it's still at revision 1000.
* Developer 2 tries to commit modified dist.iso in the same branch.
* Commit operation reports missing update with passthrough
operations to master server.
* Developer 2 runs subversion update from "slave" server, which
is permitted, gets revision 1000 until and unless svnsync is complete.
* Developer 2 tries to commit modified dist.iso again,
* Developer 2 remains unable to commit change until svnsync is
complete, due to mismatch between revisions for read operations, and
write operations, because they are *2 distinct and out of sync
Subversion servers*, despite best efforts.
At this point, with luck, someone can explain to developer 2 that
there's a slight delay with bulky files that will be resolved. But
while that bulky revision is being pushed, *ALL* other revisions are
blocked, and *any active files on the master repository* can have
similar commit issus.
> I don't see this happening in any proper setup. The setup is not a net of peer
> repositories but one primary repository and multiple secondaries. Changes will
> only be made to the primary and then synced to the secondary.
That was unclear: thank you for attempting to clarify it. Gaurav
wanted to be able to commit changes from the secondary, to the master.
You've avoided that, in theory, if you can get the pass-through proxy
working, although I think I've described some potential issues for it.
> What can happen (and, at least for a short latency, always does) is that the
> secondary repository falls behind the primary, so someone updating from that
> repository sees an older state than someone using the primary. This doesn't
> cause severe problems though, at least not any more than those you get from a
> broken connection to the primary which causes all commits to fail.
One hopes. The "it worked yesterday, why doesn't it work today!!!???"
cry of upset developers is the sort of thing that can get engineers
who manage source control fired, unless they can get very clear what
they can and cannot reliably support, and get it in writing.
Received on 2011-08-10 21:05:26 CEST