I have created a repository using tortoise SVN. The repository seems to work fine but I am struggling to make a sub folder in accessible. Even setting the sub folder to have no access, when a user tries to fetch the repository, whole directory is fetched including the sub folder which has been set to be in accessible.
Related
I spent all day installing the svn server on my virtual debian 7. So now I have working svn server on svn:// and http:// protocols. With the http:// I haven't got any problems, but with the svn:// first I couldn't create a project folder in my repo through Tortoise browser, there was some error: "User cancelled", after this I did it in the console with some command like this one
svn mkdir -m "project folder" svn://svn.host/repo/project
then a message for root password appeared, next svn user name and pass, and the project folder showed up to the Tortoise browser. I did 3 folders trough Tortoise browser: trunk, branches and tags, and I added my local project to the trunk directory. So now everything seems to work fine just when access my repo through console, ftp or http I can see the trunk branches and tags directories. I tried to find them in the linux tree with no success, it is very strange because the project is there in the Tortoise Browser, but not in the repo. Thanks of any good people which can help me to understand whats going on, and sorry for the level of my English still learning.
The subversion repository is basically a database; you won't see the literal names of files and directories if you inspect it directly. This follows from the purpose of subversion: to store the history of every file and folder, including its state at every past revision, and metadata such as log messages, and actions which change the directory structure, such as renames and deletes.
Laying out the repository the same way as the code being stored would be a very inefficient solution for this aim.
I have created a Tortoise SVN repo in my C:\Users\***\svn_repo dir and would like to delete it. Is it safe to just delete the directory itself because the TortoiseSVN Explorer utilities don't show me how and neither does the documentation
Just delete the repo. And go to Settings -> Saved Data -> URL history -> Clear.
You'll be fine. I promise
Yes, it's safe. A Subversion repository is nothing else than a directory with a bunch of files.
I windows.
Go to project in explorer.
Options
See hidden files.
Delete SVN folder
Have you tried using the repository browser to delete? Right click the any folder and choose TortoiseSVN -> Repo Browser. Then point to your local repository in the URL field. Once open you could be able to browse the repo, and with a right click, delete the folder.
As described in the header, I lost a hard drive that had a tortoise repository on it, but I managed to recover the files folder from that drive, unfortunately without the repository.
In the meantime the recovered folder now has a "!" icon on it, and I can't do anything with it (clean up, relocate, check in) since it says that it can't find its old repository.
Is there any way to move it to an existing repository on the new drive, or even just create a new one?
Thanks!
Cleanup doesn't require access to the repository. If even cleanup fails, then your backup wasn't complete or completely successful because the working copy is broken.
If you lost the repository, then you have to start from scratch (now you know why backups are important). Since you still have the files from your working copy, copy them to the new drive, then remove all hidden .svn folders. After that, you can import those files in a fresh repository.
I messed up with some commits in my project and I'd like to totally remove the commits I made, and not having any trace anymore (no revert).
Because I deleted some folders in my arborescence then restored them, but I lost all the logs that were on these subfolders and I totally need to know the modifications that have been made on these subfolders.
From the main folder, all the logs are visible, but not anymore in the subfolders
Does someone has an idea how to do it ???
You cannot remove revisions, but I think what you could to in your case is the following: Use the repository browser and go to the revision where you still had your folders, copy the required folders to some "temp" folder in the root of your repository. Switch back to the "HEAD" of the repository and move the copied folders back into your project folder.
This way you will be able to see the entire history, just make sure that you uncheck the "Stop on copy/rename" checkbox in the log window.
This has been plaguing me for a week.
SVN keeps telling me that a certain file "does not exist in repository".
Fine. Let's just delete it. Forget about it. Ignore it. Whatever. I don't really care about this file (especially if it continues to fail the nightly check-in).
The most bizarre part? A "restore" will actually RESTORE the file from the repository, so its there (corrupted, maybe?).
...and this has to be the icing on the cake. If I delete the file through Windows Explorer, SVN will RESTORE the file from the repository, and right after that state that it doesn't exist in the repository. WTF?
Does anyone have a clue how to get rid of this?
I've already tried clean-ups, reversions, deletions and anything else imaginable, but this one has me stumped.
Thanks for any tips you might have...
It seems most likely that you have corrupted your local working copy, e.g. by moving folders or some other manipulation that you did with windows explorer but should have done through the TortoiseSVN context menu. The information inside the .svn folders now no longer matches the state of the working copy, which is confusing Subversion.
To fix this, delete the parent folder ("Originals") in your working copy with windows explorer (NOT with TortoiseSVN). Then do a TortoiseSVN "update" at the root of your working copy. This should restore the folder in working order.
Another option is to discard your working copy entirely and do a fresh checkout.
Note that the next release of Subversion (1.7) will reduce the opportunities for corrupting your working copy by centralizing all metadata in a single .svn folder at the root.
I've had similar problems with corrupted working copies. Sometimes the working copies have a lot of pending changes but unable to checkin. To resolve this, I use the following approach (svn 1.7+):
Checkout a fresh working copy into a new directory (path2)
In the fresh working copy, if the offending file is there, delete it if needed.
Commit the fresh working copy
In the fresh working copy, delete everything except the .svn directory
Copy everything from the old working copy except the .svn directory into the fresh working copy.
Commit the fresh working copy again
Delete (or backup) the old working copy
Rename the fresh working to the old working copy (path2 to path)
I had faced a similar problem wherein i had a folder, for example "FolderA" which consistently shows in svn update even though I had deleted it.
It would not even show in the folder list but svn would still recognise it as if it exists.
I followed below steps:
1.Create same folder name for which svn was giving error in the same file location
2.Added it to svn checkout. Since it gave conflict errors, i resolved it using the svn option to resolve.
3.Deleted the folder and committed my svn.
Error was resolved