Stefan Fuhrmann wrote on Wed, Jun 08, 2016 at 07:55:14 +0200:
> On 04.06.2016 18:57, Daniel Shahaf wrote:
> >Stefan Fuhrmann wrote on Sat, Jun 04, 2016 at 08:04:42 -0000:
> >>On 2016-06-03 09:36 (+0200), Radek Krotil <radek.krotil_at_polarion.com> wrote:
> >>>Hello.
> >>>
> >>>Today, I encountered a problem when trying to pack a repository after
> >>>migrating it to the FSFS 7 format by performing full dump / load sequence.
> >>I assume you ran 'svnadmin load' onto a repository
> >>that was not accessible to the server at that time,
> >>so no remote user could accicentally write to it?
> >Why would that matter? What could happen if somebody makes a commit or
> >a propedit in parallel to an 'svnadmin load'? A concurrent commit will
> >cause mergeinfo in later revisions to have to have off-by-one errors,
> ( and copy-from info may break as well )
> >but shouldn't cause FS corruption.
> You are right in that it should not directly cause an issue.
>
> What people tend to do, however, is to put the new repo
> at the same physical location as the old one and then the
> server might re-use outdated information from its cache.
> ATM, there is no known mechanism that will corrupt future
> commits in addition of just delivering bogus results while
> the cached data lasts.
>
Still, the book does not warn about this problem: neither of
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
has a warning about how replacing the repository at a given filesystem
path poisons the cache (by outdating it without invalidating it).
CC'ing svnbook-dev@.
> That said, it is dicey and since what we have here is looks
> like a new type of corruption (l2p translation appears to
> have worked but the result points a few bytes outside the
> valid range), I simply like to make sure ...
Fully agreed.
Thanks for clarifying,
Daniel
Received on 2016-06-09 14:57:18 CEST