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.kro...@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
