RE: Checksum mismatch still with 1.8.19
Thanks all for the responses. Daniel wrote: > Does it load successfully if you disable rep-sharing in fsfs.conf on the > 1.8.19 repository? > I do not have rep-sharing enabled (on either repository). > > The two -1's imply that both sides of the collision are part of the same > revision --- the revision that 'load' fails to commit. Inspect that revision > on > the 1.8.5 server. Does it, by any chance, really add two different files with > the same sha1? > I inspected the revision. It does indeed have a number of files with the same MD-5 / SHA1 hash. The contents seem to be identical for them (they are NuGet packages.config files for different projects in the solution, all with the same package references, so their xml files are identical). But this is surely not an unusual situation? Stefan wrote: > Just quickly skimming through this mail, this sounds like the problem > described and investigated in late July: > http://mail-archives.apache.org/mod_mbox/subversion-users/201707.mbox/%3C5aae07a9-bb6d-6340-206a-dafcf91e35e6%40apache.org%3E > Note that the issue reported in that mail was not fixed in 1.8.19 (it's > currently expected to get into 1.8.20). > If you are in fact running into that described problem, try svnadmin > load -M 0 as a workaround. If that won't work, you are likely running > into a different issue here. As danielsh already suggested, try to > verify that indeed you don't have two different files with the same > sha-1 hash (I doubt that atm, though). I I had indeed read that thread before I posted here, however the last message on that thread said the fix would be in 1.8.19. Which is why I posted - that the fix is still pending is news to me :-) I have tried the svnadmin load -M 0 trick, and that does seem to work to allow the dump to be loaded. Exactly why I have no clue though of course, but thanks! Is there any downside to this? This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.
Re: Checksum mismatch still with 1.8.19
Grant Drake wrote on Wed, 30 Aug 2017 09:04 +: > Daniel wrote: > > The two -1's imply that both sides of the collision are part of the same > > revision --- the revision that 'load' fails to commit. Inspect that > > revision on > > the 1.8.5 server. Does it, by any chance, really add two different files > > with > > the same sha1? > > > I inspected the revision. It does indeed have a number of files with > the same MD-5 / SHA1 hash. The contents seem to be identical for them > (they are NuGet packages.config files for different projects in the > solution, all with the same package references, so their xml files are > identical). But this is surely not an unusual situation? I meant, files that have the same sha1 and different contents, as in http://shattered.io/. Multiple identical files are of course supported.
Re: Checksum mismatch still with 1.8.19
On 8/30/2017 11:04 AM, Grant Drake wrote: [...] Stefan wrote: Just quickly skimming through this mail, this sounds like the problem described and investigated in late July: http://mail-archives.apache.org/mod_mbox/subversion-users/201707.mbox/%3C5aae07a9-bb6d-6340-206a-dafcf91e35e6%40apache.org%3E Note that the issue reported in that mail was not fixed in 1.8.19 (it's currently expected to get into 1.8.20). If you are in fact running into that described problem, try svnadmin load -M 0 as a workaround. If that won't work, you are likely running into a different issue here. As danielsh already suggested, try to verify that indeed you don't have two different files with the same sha-1 hash (I doubt that atm, though). I I had indeed read that thread before I posted here, however the last message on that thread said the fix would be in 1.8.19. Which is why I posted - that the fix is still pending is news to me :-) I have tried the svnadmin load -M 0 trick, and that does seem to work to allow the dump to be loaded. Exactly why I have no clue though of course, but thanks! Is there any downside to this? [...] The only downside I'm aware of is that svnadmin load performs a bit less performant (most notably with large repositories on slower storage systems (i.e. HDD or NAS)). This however only applies to the performance of running the load command. The repository's performance is not impacted to my knowledge. P.S. your mail signature is not quite suitable for posting on mailing lists. ;-) -- Regards, Stefan Hett
Re: building subversion --with-zlib=.... seems to have no effect
Hiran CHAUDHURI wrote on Mon, 14 Aug 2017 14:25 +: > I am building subversion from source but always see the output files depend > on the system-supplied zlib which is way older than the one I want to use. I gather you build 1.9.5. > What I did was this: > > ./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX /apr-util > --with-sqlite=$PREFIX /sqlite > > which gives me the error message that subversion requires zlib. So far so > good. This implies that configure doesn't find zlib in the default paths. That's odd, given that later you indicate that libz was found in /lib64, which probably _is_ one of the default paths. Are there any clues in configure's output from this run? > Then I do > > ./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX/apr-util > --with-sqlite=$PREFIX/sqlite --with-zlib=$PREFIX/zlib > > which terminates with exit code 0. The messages on stdout look ok, but when I > do make and make install, the created libraries will depend on the > system-supplied zlib instead of the one I specified to use. Further, in > config.log I can see these lines: > > ... $ ./configure --with-apr=$PREFIX/apr --with-apr-util=$PREFIX/apr-util > --with-sqlite=$PREFIX/sqlite --with-zlib=$PREFIX/zlib ... So this is > confusing for me. While the parameter I passed was recognized and the > different checks on zlib were successful, the overall result is > --with-system-zlib? > > After make and make install, when I check the compiled libraries I get this > output: > > ldd libsvn_client-1.so ... libz.so.1 => /lib64/libz.so.1 > (0x7fc978e9f000) ... > > This shows me that the system zlib library is indeed referenced. How would I > compile subversion with zlib in a nonstandard location? Possibly apr or serf bring in another copy of zlib than the one you intended. What's the output of «grep "^SVN_.*LIBS =" Makefile»? Can you show the linker invocation of libsvn_client?
