On 5/20/07, Karl Fogel <email@example.com> wrote:
> "Mark Phippard" <firstname.lastname@example.org> 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.
It seems like if the server can seamlessly re-direct a commit to the
master server, it could potentially do the same for an update, when it
detected the need.
That being said, doing so might cover up that there is a problem with
the slave server that no one realizes exists. It seems like if the
client got an error, but was no worse for it once the slave was synced
would be the ideal.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun May 20 22:20:48 2007