Stefan Sperling wrote on Tue, Aug 16, 2011 at 15:58:13 +0200:
> 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.
>
For that matter you could try and cache those revprops somewhere, even
though the FS' youngest revision is older than them.
I'd probably prefer to see them separated from the FS revprops proper
--- ie, from the revprops that correspond to existing revisions --- in
order to maintain sanity of the FS code maintainers.
> 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).
Agreed; the proxy could could check for svn:sync-lock, svn:rdump-lock,
and maybe svn:I-am-syncing-the-proxy-via-some-other-means, revprops on
r0.
And it could include the URL of the master in the error message...
though, strictly speaking, I'm not sure that we expose that URL to
clients today? (so we may want to make this disclosure of information
optional)
Received on 2011-08-16 16:32:55 CEST