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. On Monday, 8 August 2022 at 17:06:34 UTC+1 Stephan Loeffert wrote: > 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 ... > [image: Screenshot (1163).png][image: Screenshot (1164).png][image: > Screenshot (1165).png][image: Screenshot (1168).png][image: Screenshot > (1169).png][image: Screenshot (1170).png][image: Screenshot (1166).png] > -- You received this message because you are subscribed to the Google Groups "TortoiseSVN" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tortoisesvn/ddffe616-530a-4f4f-8b3b-e55cc681c506n%40googlegroups.com.
