svnpubsub notifications ordering

post-commit hooks may run out-of-order, and in rare cases may fail to run.

Should svnpubsubd hide that complication from its clients? That is: if
a running daemon receives the following sequence of PUT events (for
a single repository):

    r1, r4, r3, r6

then it will "fill in the gaps" by itself: upon hearing of r4 it will
notify clients of r2 and r3; the PUT informing of r3 will be discarded;
and the PUT informing of r6 will cause notifications about f5 as well?

That probably means pushing the 'svnlook info' and 'svnlook changed'
calls from the commit hook to the daemon, though --- which depends on
the assumption that svnpubsubd and commit-hook.py run on the same host.
(That very assumption is already used in the code to authenticate PUTs.)

Case in point: if someone makes a 3000-file change to a website, and
someone makes a 1-file change to that very website a second later,
I expect svnpubsub will notify the two changes in reverse order (due to
time needed to update rep-cache.db), which will cause svnwcsub to update
to HEAD and then to *backdate* by one revision.

So, sure, could teach svnwcsub to only walk forward, but...

Daniel
Received on 2013-06-19 01:22:55 CEST