...db\revprops\0 file/revison missing
50 views
Skip to first unread message
Stephan Loeffert
Aug 7, 2022, 2:30:54 PM8/7/22
to TortoiseSVN
Hi,
I've doubled saved my data, so I tried to roll back to revison 514, but it doesn't work either, because revison 616 is missing. I tried to create a 616 file with 123456Z, but it doesn't work. Any way I can repair or roll back? Data on my PC is about 484 GB, so I don't want to install all from the beginning ... Any help appriciated - Thanks
Stephan
I'm using TortoiseSVN just as a file backup (on an external hard disk) and for sometimes using another PC. I can not commit because a revison (616) is missing. On my external hard disk the last file is
515 on J:\00_sub\db\revprops\0
616 on J:\00_sub\db\revs\0
I'm using
TortoiseSVN 1.14.3, Build 29387 - 64 Bit , 2022/04/08 19:31:22
ipv6 enabled
Subversion 1.14.2, -release
apr 1.6.5
apr-util 1.6.1
serf 1.3.9
OpenSSL 1.1.1n 15 Mar 2022
zlib 1.2.11
SQLite 3.36.0
TortoiseSVN 1.14.3, Build 29387 - 64 Bit , 2022/04/08 19:31:22
ipv6 enabled
Subversion 1.14.2, -release
apr 1.6.5
apr-util 1.6.1
serf 1.3.9
OpenSSL 1.1.1n 15 Mar 2022
zlib 1.2.11
SQLite 3.36.0
Edition Windows 10
Home
Version 21H2
Installiert am 14.11.2020
Betriebssystembuild 19044.1826
Leistung Windows Feature Experience Pack
120.2212.4180.0
Stephan
Bruce C
Aug 8, 2022, 10:18:33 AM8/8/22
to TortoiseSVN
Hi,
The report is not completely clear to me. Perhaps others might be better able to help if you were to add a description ot the overall system. Ideally, this would include the specific steps that you've been performing, explaining what happened and what you expected to have happened.
In the meantime, the information you included about internal folders of the repository storage (e.g. .\db\revprops\0) suggest that you might be suspecting repository corruption. If so, you could verify the repository. More information about the relevant command can be found at https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svnadmin.c.verify.
If the issue is with the Subversion [server] storage, you might get more help from the Apache Subversion mailing lists (https://subversion.apache.org/mailing-lists.html). This group is for a specific Subversion client application (TortoiseSVN). Although we're all Subversion users here too, the more general Subversion mailing lists might have a wider audience.
Hope this helps.
The report is not completely clear to me. Perhaps others might be better able to help if you were to add a description ot the overall system. Ideally, this would include the specific steps that you've been performing, explaining what happened and what you expected to have happened.
In the meantime, the information you included about internal folders of the repository storage (e.g. .\db\revprops\0) suggest that you might be suspecting repository corruption. If so, you could verify the repository. More information about the relevant command can be found at https://svnbook.red-bean.com/en/1.7/svn-book.html#svn.ref.svnadmin.c.verify.
If the issue is with the Subversion [server] storage, you might get more help from the Apache Subversion mailing lists (https://subversion.apache.org/mailing-lists.html). This group is for a specific Subversion client application (TortoiseSVN). Although we're all Subversion users here too, the more general Subversion mailing lists might have a wider audience.
Hope this helps.
Stephan Loeffert
Aug 8, 2022, 12:06:34 PM8/8/22
to TortoiseSVN
Hi Bruce, thank you,
o.k., next try:
I usually use a PC and back up my private data in various ways. Since I sometimes have to work on my notebook and the data transfer from the backup to the notebook takes hours, I decided to use Tortoise SVN for this.
My data, which is the issue in this case, is located on the PC in the directory "D:\00_sub_AR" = working copy.
The repository is located in the directory "J:\00_sub" on an external hard drive connected to the PC via USB.
I have never used any commands directly, only the TortoiseSVN menu. When I run the command "SVN Übertragen" = "SVN Commit" from the menu, I get the error message "Keine Revision 616" = "No Revision 616".
Then I noticed that the file 616 is missing in J:\00_sub\db\revprops\0 (see at the top).
Where please I have to enter the recommended command: "svnadmin verify REPOS_J:\00_sub" or "svnadmin verify J:\00_sub"(?)? cmd or PowerShell does not work (or I am too stupid to enter the command correctly).
I hope to have described everything better this time ...
.png?part=0.1&view=1)
.png?part=0.6&view=1)
.png?part=0.2&view=1)
.png?part=0.3&view=1)
.png?part=0.7&view=1)
.png?part=0.5&view=1)
.png?part=0.4&view=1)
o.k., next try:
I usually use a PC and back up my private data in various ways. Since I sometimes have to work on my notebook and the data transfer from the backup to the notebook takes hours, I decided to use Tortoise SVN for this.
My data, which is the issue in this case, is located on the PC in the directory "D:\00_sub_AR" = working copy.
The repository is located in the directory "J:\00_sub" on an external hard drive connected to the PC via USB.
I have never used any commands directly, only the TortoiseSVN menu. When I run the command "SVN Übertragen" = "SVN Commit" from the menu, I get the error message "Keine Revision 616" = "No Revision 616".
Then I noticed that the file 616 is missing in J:\00_sub\db\revprops\0 (see at the top).
Where please I have to enter the recommended command: "svnadmin verify REPOS_J:\00_sub" or "svnadmin verify J:\00_sub"(?)? cmd or PowerShell does not work (or I am too stupid to enter the command correctly).
I hope to have described everything better this time ...
Bruce C
Aug 8, 2022, 5:27:10 PM8/8/22
to TortoiseSVN
Hi,
The issue with the svnadmin command may be because the command line tools have not been installed. Installation of the command line tools is an option when installing TortoiseSVN. Did you enable that option? If not, the solution would be to re-run the installer and add that option. There are other ways to install the Subversion command line tools, but this is probably the easiest for a TortoiseSVN user.
The cause of the primary error is not clear to me. It is a very different usage than I normally experience so you may be handling use cases in which I am not experienced, although I see no reason that your approach would fail. I'm also at a disadvantage as the screenshots are in German, making it difficult (for me) to spot something out of the ordinary. Others might have better suggestions as, I believe, some are native German speakers.
In light of the observations above, the following suggestions may a statement of the obvious that you already know and of no help to you. However, perhaps they will be of some use.
If it were me, there are a some things that I would do. First, it's important to ensure that you have a backup of the local working copy checkout, so that it is easy to get back to the same start point if something goes wrong.
[N.B. Many things can be returned to the original state but can be difficult, especially when lots of things are being tried for the first time. Personally, if I'm unsure, I make a simple copy of the working copy folder. If things don't go as expected, I always have that local duplicate of things before I started. Remember that anything committed to the repository creates a record that allows a return to an earlier state or changes replayed. However, sometimes something in the local working copy can be lost (not least by simply deleting it) and if not committed to the repository those local changes can't be recovered.]
Next, I'd review the details of the checkout. In Windows, this information can be found from the Properties dialog of the folder at the root of the checkout (e.g. D:\00_sub_AR), and looking at the Subversion page (of the dialog). An alternative way to gather this information, especially for sharing, is to run the 'svn info' command (another of the command line tools that can be installed, as described above). Doing this step isn't going to change anything, so there's no risk.
I'd then get additional information about the working copy checkout, using the TortoiseSVN Check for Modifications option or the 'svn status' command. This isn't going to change anything either.
Next, I'd update the working copy checkout. For example, if the files were updated and committed on the laptop, the repository changes will be on the external drive but the desktop PC won't know that those changes exist. The TortoiseSVN Update option can be used to bring the working copy up to date. However, if the desktop PC working copy has changes to the same files that have since been updated to the repository (on the external drive) by the laptop, then the files will need to be merged. If the files are text files, that will be automatic, unless the merge process identifies that the changes are to the same areas (i.e. lines) of the file. This is a conflict that needs to be resolved manually. You should be in a position to resolve such conflicts. Once the conflicts are resolved, the changes can then be committed, as normal. If the files are binary, the merge is trickier.
BTW, it's usually desirable to perform an update after each commit - it isn't done automatically by Subversion. So, after committing from the laptop, or the desktop PC, initiate an update. Another update will also be required on the system that wasn't used to commit the changes (i.e. the desktop PC or the laptop - the other one). The more frequently that updates are performed, the less likely it will be that there is a need to merge files or resolve conflicts.
To be honest, this doesn't "feel" like the updating is the cause of the problem you have described, although it is an issue that can have somewhat similar symptoms.
I haven't looked, in detail, at the internal structure of the repository. Rather than do that, I'd use the standard Subversion tools to report on the state of the working copies and/or the repository as a method to investigate the issue.
Hope this helps.
The issue with the svnadmin command may be because the command line tools have not been installed. Installation of the command line tools is an option when installing TortoiseSVN. Did you enable that option? If not, the solution would be to re-run the installer and add that option. There are other ways to install the Subversion command line tools, but this is probably the easiest for a TortoiseSVN user.
The cause of the primary error is not clear to me. It is a very different usage than I normally experience so you may be handling use cases in which I am not experienced, although I see no reason that your approach would fail. I'm also at a disadvantage as the screenshots are in German, making it difficult (for me) to spot something out of the ordinary. Others might have better suggestions as, I believe, some are native German speakers.
In light of the observations above, the following suggestions may a statement of the obvious that you already know and of no help to you. However, perhaps they will be of some use.
If it were me, there are a some things that I would do. First, it's important to ensure that you have a backup of the local working copy checkout, so that it is easy to get back to the same start point if something goes wrong.
[N.B. Many things can be returned to the original state but can be difficult, especially when lots of things are being tried for the first time. Personally, if I'm unsure, I make a simple copy of the working copy folder. If things don't go as expected, I always have that local duplicate of things before I started. Remember that anything committed to the repository creates a record that allows a return to an earlier state or changes replayed. However, sometimes something in the local working copy can be lost (not least by simply deleting it) and if not committed to the repository those local changes can't be recovered.]
Next, I'd review the details of the checkout. In Windows, this information can be found from the Properties dialog of the folder at the root of the checkout (e.g. D:\00_sub_AR), and looking at the Subversion page (of the dialog). An alternative way to gather this information, especially for sharing, is to run the 'svn info' command (another of the command line tools that can be installed, as described above). Doing this step isn't going to change anything, so there's no risk.
I'd then get additional information about the working copy checkout, using the TortoiseSVN Check for Modifications option or the 'svn status' command. This isn't going to change anything either.
Next, I'd update the working copy checkout. For example, if the files were updated and committed on the laptop, the repository changes will be on the external drive but the desktop PC won't know that those changes exist. The TortoiseSVN Update option can be used to bring the working copy up to date. However, if the desktop PC working copy has changes to the same files that have since been updated to the repository (on the external drive) by the laptop, then the files will need to be merged. If the files are text files, that will be automatic, unless the merge process identifies that the changes are to the same areas (i.e. lines) of the file. This is a conflict that needs to be resolved manually. You should be in a position to resolve such conflicts. Once the conflicts are resolved, the changes can then be committed, as normal. If the files are binary, the merge is trickier.
BTW, it's usually desirable to perform an update after each commit - it isn't done automatically by Subversion. So, after committing from the laptop, or the desktop PC, initiate an update. Another update will also be required on the system that wasn't used to commit the changes (i.e. the desktop PC or the laptop - the other one). The more frequently that updates are performed, the less likely it will be that there is a need to merge files or resolve conflicts.
To be honest, this doesn't "feel" like the updating is the cause of the problem you have described, although it is an issue that can have somewhat similar symptoms.
I haven't looked, in detail, at the internal structure of the repository. Rather than do that, I'd use the standard Subversion tools to report on the state of the working copies and/or the repository as a method to investigate the issue.
Hope this helps.
Reply all
Reply to author
Forward
0 new messages