> > The dump/load cycle into 1.9 is finished as well, now it is 36.2 GB (less > compared to 1.8 which was 37.5 GB). Both 1.9->1.9 and 1.8->1.9 resulted > almost identical repos when comparing files byte by byte (the exception is > UUID file)... Which makes me wonder if I dumped the same rep twice. Too bad > the windows cmd doesn't retain command history. > > > It is very unlikely that you actually (successfully) dumped and > loaded data twice because the number of nodes and revisions > would then be different. >
I didn't want to say I executed two dump & load into same repo. I executed the load into two different new repos, both in 1.9 format. (one from1.8 format repo, another from original 1.9 format repo, so I had 4 repos in total). As those new repos are byte-by-byte identical, I wonder if I managed to dump one repo twice. Well, good news is that when de-duplication works correctly the 1.9 repo is smaller than 1.8 And this is totally separated from the first sync and failing de-duplication. > However, you might have tried to do > "something" to the repo while to got written by the sync process. > That might have blocked access to the rep-cache.db, ending > all deduplication. But that is pure speculation. > > As I said elsewhere, there was indication of some process crash at the time when rep-cache.db updates stopped. I did not find the crash report, so I have no idea what could have caused it, or if the process that crashed was related to svn. Gert
