After my OS crashed, I've installed a fresh version (Windows 7 Pro x64).
I want to commit my project changes, so I need to restore my local repository to do this. Of course I have the all files located in my folder where was the repository before the OS crash, but of course TortoiseSVN doesn't know that there was a repository. How can I do it (I believe it is possible to restore that repository)?
If you still have your repository folder, intact with all the .svn subfolders, all you should need is installing TortoiseSVN itself after the OS reinstall. TortoiseSVN does not rely on anything outside the file system to identify working folders, so you should be able to just check in.
I think you're mixing up "repository" and "working-copy" here.
Assuming you have a local repository created on your harddrive:
To find your repository you could do a fresh checkout of your local repository and specify the location starting with "file://". If you have an old working-copy, but the repository is not at its old location, you can relocate it with the TortoiseSVN command "relocate".
An old working-copy should just show up. Chances are that it doesn't show up, because you installed a new version of TortoiseSVN (1.7.x) which uses a newer working-copy-format that is different from the older format. You need to select your working-copy directory and select "upgrade working-copy" so you can work with it.
Simply checkout a new project and copy the .svn folder into existing project.
Related
I have a repository in a folder /var/www/. Through the git client, I select this folder as "open an existing repository", but the repository opens as if it is located in the /run/ directory.
This did not happen on the old computer. And now I have a number of problems. For example, auto-updating of the state of files after their modification does not work. It also fails to use Stash. There are also other problems.
UPDATE and a solution: I found out that this problem appeared due to the fact that I installed the flatpack version of Sublime Merge on
a new computer. When I reinstalled it as a regular package, everything
works as it should.
I'm not sure if the problem is exactly in the changed repository path, but this is my main suspicion.
I'm using Linux Mint 21.1. Test this with git-clients Sublime Merge and Gittyup. Sublime Merge shows the path to repositories as /run/user/1000/doc/c9e48011/<repo_name>.
Gittyup as /run/flatpak/doc/c9e48011/<repo_name>.
On the path from Sublime Merge, there really is a folder with all the files from my repository. And the path that Gittyup shows is inaccessible because the /run/flatpak/ folder doesn't actually exist.
Why is this happening and how to fix it?
I had a gitlab server of 7.6.2 version with some repositories. Now this server was upgraded by newest Ubuntu and it has an empty gitlab server of version 12.0.1. I also have a HDD backup from old gitlab server.
I need to move all repositories from old gitlab server to the new one. I tried to copy .git repositories from /var/opt/gitlab/repositories/user/ to the similar location of the new server with disabled hashed repositories storage, but it has no effect.
I also tried to create an empty repository with e.g. name test and replace test.git directory on new server from directory from old one, but there is no effect neither.
I tried to find file from created test repository named test.txt by find command in whole server file system, but there is no such file was found (but this file exists in the gitlab repository).
My question is: where repositories of gitlab server are stored and how can I copy it from backup of old server HDD to the new server file system (I can not run both instances of gitlab because I have only one machine. Running backup of old server as virtual machine's rootfs is also impossible by some reasons).
Upd.
It is not duplicate of this question because I have no backups of old gitlab server made by gitlab, I have only backup of filesystem of machine it was installed on. I also can not run old server to pull repositories because its machine was upgraded. Only thing I have from old server: its filesystem.
If you just need to migrate repositories (ie: no issues, pipelines, etc), it's better to clone each repository and upload it again (one by one, or using a batch command):
cd /var/opt/gitlab/repositories/...
git remote add newserver url
git push --all newserver url
Instead, if you need to migrate all features, it's better to restore the server backup and upgrade OS and Gitlab in place... even if it's a long road between 7 and 12, and you probably neeed to make multiple steps.
Careful, this might cause massive breakage, experiment on a scratch system.
The git repositories should be the same, so I'd try just copying the contents over. The user information and ancillary stuff is probably different.
Another path would be to set up the old system, and upgrade that one. Version by version, if need be.
Last resort is to clone the old repositories and upload them into the new system.
I have a Windows PC and on the same PC I have a Lubuntu VM inside the VMWare player.
I share my Windows folders so I can see them from the Lubunutu VM.
My problem is when I clone a Git repo on Windows (using Tortoise Git) and then try to access it from Lubuntu (using Git from command line) all files appear modified although I have not changed them.
I know that reason for this is that Windows and Linux handle the new lines differently.
My question is how can I configure my Git installations on Windows and on Lubuntu so I do not have this problem?
Update:
As suggested (by Craig Estey) this does not seem to be CRLF problem. I tried cloning a repo in my Linux VM on the shared directory and got following error:
fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.`
I have no problem cloning the same repo on the VM's local drive.
Any idea what could be the reason?
Note: The main reason I want to do this is to keep my VM's drive size small and use shared drive as much as possible. My VM's local drive is on SSD drive and shared drive is on much larger HDD.
Suppose you put a repository into a Windows Shared folder.
And mount(Mount shared folder on Ubuntu) that shared folder on Ubuntu, so you can clone that repository. (Talking about you can not clone, it must be another problem. I tested it, good for me.)
When you cd to that repository in that mount, you see all files are modified on Ubuntu, then it should be the EOL problem.
On Windows the autocrlf is true by default(assume you are using Git for Windows).
When you clone a repository on Windows, the files will be checkout with CRLF EOL.
But, On Ubuntu the autocrlf is false by default. Using git in that repository which is mount on Ubuntu, git expects the EOL is LF. But, the EOL is still CRLF. That's why git treats all file as modified on Ubuntu.
To fix this problem, make sure both OS to use the same autocrlf value, or using .gitattributes to control the EOL.
For example, using false value:
On windows,
Delete all files in working tree of that repository.
(Note: if you have local changes, commit them first.)
Run git config core.autocrlf false for that repository only. Or
Right click in that repository, click TortoiseGit -> Setting
In Settings dialog, go Git node, select local and un-check the AutoCrlf
Apply the change
Perform git reset hard to get all files back with correct EOLs.
Open TortoiseGit Log Message dialog
Right click on current branch and perform Reset "<current branch name>" to this
Choose "Hard" option
On Ubuntu, you should not see all files modified.
For using .gitattributes:
* -crlf
There was a problem with my computer and I had to reinstall Windows (7). I installed TortoiseSVN (1.8.11 64 bit) and I see the context menus, but I don't have a commit option in my SVN directory (where the files are), only a few other options. I don't want to update the files from the server but just commit (because only I can commit to this repository). How do I enter my username & password and commit my changes to SVN?
The reason could be:
The file hasn't been changed, so there is no commit option available -> or the file is not versioned
your directory hasn't been added to the SVN
you haven't made a working copy and you are using some "backup" folders wher you lost the hidden .svn folder -> if so then make a working copy
I am working on a file system repository with Tortoise.
I deleted the initial folder where I created the repository.
The folder which I added to the old repository, when I try to add to a new repository, the error message appears:
Repository UUID '6df16c57-c740-ea49-ab7f-fcd22d7f7cb9' doesn't match expected
Is there a way to simply clear out the settings for the old repository? So that I could perform the importing of the folder to add into the new repository in a clean slate.
BTW this is my tortoise version (if it is of any help):
TortoiseSVN 1.5.8, Build 15348 - 32 Bit , 2009/02/13 18:06:18
Subversion 1.5.5,
apr 1.2.12
apr-utils 1.2.12
berkeley db 4.4.20
neon 0.28.3
OpenSSL 0.9.8i 15 Sep 2008
zlib 1.2.3
Basically, all I want to do is to clear up the repository which I earlier created so that it is like starting from scratch over again.
Thanks.
There's an easy way to do this with TortoioseSVN:
unversion a working copy
Yes. If you have Cygwin installed, you can use the unsvn utility to remove all the ".svn" folders.