"Mark Phippard" <markphip@gmail.com> writes:
>> Generally it works well, however when the commit is "large" (I'm not sure,
>> several megabytes or more or at least the commit time of a few minutes
>> (???)) then we usually have problems where the slave has not synced up
>> with
>> the master yet and the client that committed it to the slave gets confused
>> and starts giving errors. It has been possible but problematic to get
>> things straightened out, and sometimes I've had a svnsync not go through
>> and had to manually kick it and/or delete the svn:lock (I think that is
>> the property) to get things going again.
>>
>> Is there a way to do a synchronous sync with the slave or some code magic
>> behind the scenes that could be added in the client or slave server or
>> master server to tell the client to wait a little longer to be synced
>> up with the slave server correctly?
>>
>> I think what is happening is that the slave says "I've committed a certain
>> version" and then at the end of the commit it checks that the slave server
>> has that version which hasn't been synced yet and it gets confused.
>>
>> Thankfully this has not happened a whole lot but it has happened on
>> multiple occasions. I'm telling my users that when they have a "large"
>> commit (size or time is hard to determine) then to switch to the master to
>> commit it and then switch back to the slave again.
>>
>> Any help, ideas, pointers, would be appreciated.
>
> Seems like a problem that should be identified and fixed before we
> release. Now that we have svnsync it would be super-cool if it could
> be formally integrated into this so that you did not need a hook at
> all.
A client-side solution might work. Take a client that's reading from
a slave repository S, but whose commits go to a master M.
1. S is at revision R, M is at revision R
2. Now the client commits. Afterwards, M is at revision R+1, but S
is still at revision R. (Assume the commit is large, so S can't
sync up immediately.)
3. If the client knows that its commit went through to M, it can
obey a rule that says: "Until S is at R+1 or higher, do all
reads from M".
I'm hand-waving on some details, especially since write-throughs are
supposed to be transparent to the client (is that right?), and this
plan would mean they aren't quite transparent. One possibility:
We could have a new server error code, used only by read-only mirrors,
that says: "You tried to update to a revision higher than my youngest
revision; maybe you should try reading from this other repository over
here (the master)." The client would redirect its communications just
for this RA session, and not remember the master permanently, since
presumably the slave will update soon anyway.
That would, in effect, implement the above-proposed rule.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 20 20:52:27 2007