[haiku-sysadmin] Re: Daily Summary for svn.haiku-os.org
- From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
- To: haiku-sysadmin@xxxxxxxxxxxxx
- Date: Sun, 20 Sep 2009 13:18:55 +0200
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
Other related posts:
