Hi Nathan,
Thank you for the help
* Please see my answers below with leading [YE].
* I rewritten my posts in SVN
Forum<https://www.svnforum.org/forum/topic/please-help-to-repair-svn-repository>
and in
stackoverflow<https://stackoverflow.com/questions/68985395/please-help-to-repair-svn-repository>
(it has also pictures). The old post and this mail (On Mon, Aug 30, 2021 at
11:15 AM Yakov Erlich <[email protected]<mailto:[email protected]>>)
have the same text. In the updated post I described the problem more logicall
(my opinion) and added more detailed loggers (logger of dump with errors) and
pictures also. Do I need to copy updated post here or enough in these sites?
So, Nathan, how I continue to repair my repository?
Best Regards,
Yakov Erlich
From: Nathan Hartman <[email protected]>
Sent: Tuesday, August 31, 2021 5:24 PM
To: Yakov Erlich <[email protected]>
Cc: [email protected]
Subject: Re: Please help to repair SVN repository.
On Mon, Aug 30, 2021 at 11:15 AM Yakov Erlich
<[email protected]<mailto:[email protected]>> wrote:
Hi,
Please help to repair SVN repository.
I use TortoiseSVN (1.14.1) and VisualSVN Server 4.3.4.
Were you upgrading a repository from an older SVN version? If so, which version?
If not for an upgrade, what prompted to fix the repository?
More below...
[YE] We started work with SVN since 10/2016, using Subversion 1.9.4 under
VisualSVN 3.5.4.
Then we periodically did upgrades, according to mails that I get from
'VisualSVN Team' via VisualSVN Announce
[email protected]<mailto:[email protected]>
Du to we are very small startup, we migrated smooth to Subversion 1.10, and
then to together with VisualSVN 4.3.1 to Subversion 1.4
in several VisualSVN upgrades
I try to repair "Altera" repository.
Its size is 106 GB with 1844 revisions.
Attached files
- log-verifivation.txt keeps list of all bad revisions (17)
- repo_dump_script.sh dumps Altera repository to several dump files,
except the bad ones (found in log-verifivation.txt).
Note that later revisions may be based on data in earlier revisions; e.g., r752
may contain a diff against data in r730. Therefore it could be that, say, a
single bit error in the storage of r730 leads to all the other bad revisions.
Is it possible there was a disk corruption? If so, do you have an older backed
up dump that includes r730 that could be used to load up to (and including)
that portion of the repository? (Alternately do you have an older copy of the
repository in backups, e.g., made with 'svnadmin hotcopy' or similar?)
[YE] Regarding disc corruption. We have a separate Server (computer) for SVN.
I have no direct access to the Server, only using TortoiseSVN.
I do not nothing regarding to disk corruption.
Regarding SVN backup. We did not do any backup.
(I' am a SW designer and had no experience with repository administration.
In fact, only I worked with SVN, saving my and may team's projects in SVN.)
- repo_load_script.sh loads the dump files into new "AlteraFix"
repository (see its log in).
- log-repo_load.zip of log-repo_load.txt (44 MB) keeps output of load process
(repo_load_script.sh)
Note:
All 'svnadmin' commands and scripts I ran in "Bash"
command-line window,
under Windows 10. The Bash window executes Linux commands.
The Bash window I can open after installing GIT on my PC.
Problem:
All the dump and load finished without errors (IMHO), but there are following
problems:
- Resulting repository AlteraFix has 45 GB size in opposite to Altera (106 GB)
If upgrading from a much older SVN (older than SVN 1.6), SVN 1.6 and newer has
a (optional) feature called representation sharing (rep sharing) which could
account for a big reduction in size: when adding duplicate files to the
repository, Subversion only stores one instance. However, I can't say whether
that's the case here, since I don't know whether you are upgrading an older
repository, nor the size of the revisions that are excluded from the dump, nor
the amount of duplicated data. It could be that ~61 GB of data are accounted
for by the revisions that were excluded from the dump, and therefore are not in
the "AlteraFix" repository.
[YE] real reason of smaller is the following: svnadmin load stopped to work
after encountering with first error.
Nathan
