How to recover a repo.

[Ralph Gable]

I had a repo I had opened in Dropbox. Everything was just peachy keen until I was offered a new deal - which was that I got 2 TB of space for 120 bucks a year. I went for it. Also as a part of the deal I found out that Dropbox was using local storage on my disk (which I had not known) and now they were going to allow me to have  files that were only in their "cloud". So I tried to make my SVN repo "only in the cloud". During these adventures SOMETHING happened to the repo ( see ragrepo in myrepo.jpg) and now I can no longer access it. If I try to checkout something from this repo I get the screen in chkoutattempt.jpg. Yet all the paths and file names are okay. The repo directory contains 24.6 GBytes of data  and 3,386 files (see dirrepo.jpg). So all my files are there but I do NOT know how to get access to  them. 

I have another file in dropbox that mysteriously appeared while I was experimenting. It LOOKS like a repo but it has a different name "ragrepowc". When I attempt a Tortoise SVN operation on this file - and do a Show Log I get this message from Dropbox (see SVN-Show-Log.jpg). If I choose Offline For Now I get this (see Log-Display.jpg). If I highlight Revision 5 I get a display showing EVERY file I put into this repository ( see Rev5.jpg).

Can anybody give me some ideas about how I can get these files back? It would certainly be appreciated.

[M. Ziggy]

While Dropbox may have an Explorer plugin so it looks and behaves mostly like local files, the underlying transport protocol would still be http or https, or a Dropbox variant of these, not file (as shown in screenshots) or svn, and this may be confusing how TSVN sees it through libsvn.

I suspect you may need to get a fresh checkout from a direct access https URL derived by looking at Dropbox account in web browser, not explorer. Verify this with Repo Browser, and set user and password, etc, do checkout, and set new local directory to sync to wc directory on Dropbox as a backup, not primary. If nothing else, from web browser you can get a zip of the repo data and put it back on your machine.

[Ralph Gable]

This doesn't work for me. I tried but the problem is the repo in DROPBOX thinks it is on my C: drive. So it must be that the original repo WAS on my C drive and it was just copied to the Dropbox account. Now the situation is even more confused. I talked to the DROPBOX guys - they refuse to have anything to do with it. As far as they are concerned it is a 3rd party problem. Now I have not been able to get the repo directory from my DROPBOX account back to my PC. If I can I think I will be able to access it but have not yet succeeded. I rewound the file in DROPBOX back to an earlier date. That didn't seem to help either. Anyway it is still an ongoing saga.

[mrzig...@gmail.com]

Sorry, thought you could get a zip, but it only lets you download files singly, with basic Android client. The drive letters issue counts as a bug in svn, not tsvn. It's valid for wc tracking of revs, but revs in repo shouldn't have them because source persistence is not guaranteed; checkins can come from wc's on removable drives or over the net.

[Ralph Gable]

On Sunday, June 23, 2019 at 3:24:03 AM UTC-5, (unknown) wrote:

Sorry, thought you could get a zip, but it only lets you download files singly, with basic Android client. The drive letters issue counts as a bug in svn, not tsvn. It's valid for wc tracking of revs, but revs in repo shouldn't have them because source persistence is not guaranteed; checkins can come from wc's on removable drives or over the net.

The repo I was trying to deal with was corrupted beyond repair. I found some Slashdot help that suggested copying the .db file into a newly created repo. That didn't work because the .db file was corrupted. Eventually I had to "rewind" the repo back to a much earlier version in DROPBOX itself. Once I did that I then was able to refresh the local version from that and voi-la the data magically reappeared in SVN. I was then able to checkout all of it and just put it back in DROPBOX. In this case that was sufficient since 95% of the data gained nothing from being in a repository anyway - i.e. it wasn't source files for some project. Even the data that WAS source files (python files) was not for an organized project - just ad hoc procedures I use for certain home projects. I am greatly relieved and thanks for your suggestions.

[mrzig...@gmail.com]

yw... Happy for you not everything lost.