Ping, the bug report below hasn't seen any response yet.
To summarize, 'hotcopy' doesn't lock revprops.db before copying it, and a
thread on the sqlite mailing list warns that doing so may result in
corruption. Note that when revprop packing is enabled, revprops.db is the
only (and authoritative) record of revprops on some revisions.
An issue is already filed...
Daniel
Daniel Shahaf wrote on Sat, 27 Feb 2010 at 18:07 +0200:
> Stefan Sperling wrote on Sat, 27 Feb 2010 at 13:02 +0100:
> > On Fri, Feb 26, 2010 at 02:34:54AM +0200, Daniel Shahaf wrote:
> > > fs_fs.c:svn_fs_fs__hotcopy() uses this code to copy revprops.db:
> > > 1597 /* Copy the packed revprop db. */
> > > 1598 if (format >= SVN_FS_FS__MIN_PACKED_REVPROP_FORMAT)
> > > 1599 {
> > > 1600 SVN_ERR(svn_io_dir_file_copy(src_subdir, dst_subdir, PATH_REVPROPS_DB,
> > > 1601 pool));
> > > 1602 }
> > >
> > > This post <http://thread.gmane.org/gmane.comp.db.sqlite.general/48391/focus=48423>
> > > on the sqlite-users mailing list implies that an exclusive lock must be
> > > used for copying an sqlite db, and that plain copying might result in
> > > a corrupt database.
> > >
> > > As far as I can see, 'hotcopy' doesn't take the steps recommended
> > > in that (sub)thread to avoid corruption.
> > >
> > > Could someone more familiar with sqlite comment on this? Could
> > > 'hotcopy', as now written, potentially corrupt the revprops db
> > > (of the hotcopy target)?
> >
> > Can you file an issue, please?
> >
>
> Filed this as <http://subversion.tigris.org/issues/show_bug.cgi?id=3596>.
Received on 2010-04-04 10:28:34 CEST