On Tue, Aug 16, 2011 at 09:31:21AM +1000, Simon Takita wrote:
>
> On 16/08/2011, at 02:34 , Stefan Sperling stsp-at-elego.de |subversion users list| wrote:
>
> > On Mon, Aug 15, 2011 at 11:06:29AM -0500, Les Mikesell wrote:
> >> I suppose the direct access could help in the case where the
> >> revision taking too long to sync is not the same data the client
> >> needs for its update, but otherwise it could make things worse.
> >
> > Good point.
> >
> > I was thinking of operations like 'svn log', 'svn diff' etc.
> > An update will need to pull the same data the sync is getting, of course.
>
>
> Direct access would certainly help in the case where the revision in transit was unrelated to a clients working copy. In fact I would probably expect this to be the usual case.
>
> Even though deferring to the master in this case (where the transaction is related to the working copy), could make things worse in terms of absolute sync time, the current situation is that the slave can't be used for some operations during this period. In our situation fully coherent access to what the master server sees is a higher priority than update time, but I understand that others may have a different priority here.
>
Right. I think the slave should be selective about what it forwards to
the master. E.g. requests for log messages can certainly be sent to the
master without causing much harm. The only real problem would be an update
to a revision that is currently syncing or about to be synced.
A diff/blame operation that involves this revision might also cause
undesired traffic.
We should try to improve the error message users get to see. If mod_dav_svn
were to peek at the svn:sync-* properties to determine whether a sync is
happening, it could annotate error messages for failed read requests with
a "please try again later" message. (Yes, this assumes svnsync is being
used -- dump/load isn't really the standard way of doing this, sorry).
Received on 2011-08-16 15:58:51 CEST