Karl Fogel wrote:
> "Mark Phippard" <email@example.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
>>> 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
> 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".
So long as R+1 is guaranteed to be the result of this clients commit and
not from another clients simultaneous action.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon May 21 00:47:21 2007