Hi Oliver, 2009/9/20 Oliver Tappe <zooey@xxxxxxxxxxxxxxx>: > Hi, > > On 2009-09-20 at 08:42:02 [+0200], Niels Reedijk <niels.reedijk@xxxxxxxxx> > wrote: >> >> 2009/9/20 root on svn <root@xxxxxxxxxxxxxxxx>: >> >> > ######################################################################## >> > # Subversion Repository Mirrors >> > ######################################################################## >> > 2009-09-19.20:00:01 >> > both repositories are already at 33003 >> > 2009-09-19.20:30:01 >> > syncing r33004:33170 to 96.234.66.125 svnadmin: File not found: transaction >> > '33027-phg', path >> > 'haiku/branches/components/gallium3d/headers/private/shared/TrackerAddOnAppL >> > aunch.h' >> > svnadmin: Can't write to stream: Broken pipe >> > failed >> >> I just downloaded the failed file from Berlios, from the current >> dev.haiku-os.org mirror and svn.haiku-os.org, and diff shows no >> changes so I think the synchronization script seemed to be able to >> overcome the problem. >> >> > 2009-09-19.21:00:01 >> > syncing r32932:33170 to 96.234.66.125 completed. >> >> Also, because it continues here with revision 32932 (and not 33027). > > Yes, everything is alright. I switched the subversion repository underneath > the > backup, such that now the real, unchanged sync with berlios is backed up. > To protect from unwanted changes, write access to the haiku subversion repo on > svn.haiku-os.org has been blocked for now. > > I rolled back the backup repo manually (by deleting files and data-rows in the > SQLite-cache), which went just fine - svnmirror.sh simply started from where > it > supposedly had stopped last time around. All in all, I'm pretty confident that > the backup scheme, the subversion mirror and the read-only svnsync to vmdev > are > working properly now. > > Last thing yesterday, I did a trac-admin resync, such that the test > installation of trac should reflect the current state of the corresponding > svnsync repo. Yes, that's what I thought, because the 'strange' changeset (4###) with user svnsync and dated today (instead of 6 years ago) disappeared. This could be a warning of a (potential) issue in the future though. What happens is that svnsync commits a revision (as user svnsync and dated today), then releases the lock and afterwards changes the metadata. Trac checks every page load whether the repository has changed. If a new changeset is added, it will load (and cache) its data. Now if someone requests a page before svnsync has updated the metadata, then that means that the cached data is inconsistent (and that would mean a manual trac-admin resync when that happens). Now this might be such a rare occasion (once a year) that we decide it is not the effort to look into it, so we might just wait until it happens some day and then see what to do, but if there is something that we can do to fix it now I am open for suggestions. (for example, try to see if svnsync can lock the repository until after the metadata write. Another option would be to hack trac to ignore any changesets committed by user svnsync, but that would be ugly). Kind regards, Niels