>
> 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
Received on 2016-01-30 12:32:24 CET