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.
Related
After migrating svn repos from a server to another server, even I used "--force-uuid" in svnadmin load command, the passwd files of the repositories are empty.
All conf folder contents are empty.
Is there a way to migrate conf file properly?
Thanks for your help.
edit: from server's svn version is 1.6, to server's svn version is 1.7. is version difference causes a problem like this?
edit: from server's svn version is 1.6, to server's svn version is
1.7. is version difference causes a problem like this?
You must not use Subversion 1.7 or older versions. Upgrade to the latest 1.9.x.
I would recommend that you read the documentation before you perform any repository maintenance or administration tasks. SVNBook is a great resource of information about Subversion and version control in general. It will help you familiarize yourself with common terminology and concepts of SVN and version control.
After migrating svn repos from a server to another server, even I used
"--force-uuid" in svnadmin load command, the passwd files of the
repositories are empty. All conf folder contents are empty.
Read SVNBook | Repository data migration using svnadmin:
The Subversion repository dump format describes versioned repository
changes only. It will not carry any information about uncommitted
transactions, user locks on filesystem paths, repository or server
configuration customizations (including hook scripts), and so on.
And note that UUID has nothing to do with your htpasswd file.
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
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.
i have a CVS Repository in Solaris machine, now i want to move this repository to anathor CVS server in anathor machine, can anyone please tell me the steps to migrate the CVS repository to the new CVS server. existing server is running in extssh protocol and i want to move it to Pserver protocol.
CVS is a very simple environment. To move the repository over, just copy the files that are in the repository. If you like, tar it up, copy the tar to the new machine, and untar it. Most of the per-directory configuration will be stored along with the rest of the files in the tarball.
The parts of the configuration that are not included within the repository will need to be set up according to the instructions for setting up CVS on your target platform, whatever that is.
I wanna copy files and folders from my svn repository on server, but I dont want to install svn client, can I do it without svn client?
PS server - linux (CentOS 5.5), svnadmin version 1.4.2 (r22196)compiled Aug 10 2009, 17:54:46.
UPD: files are already exported to server: I want to import files from svn repository to directory, where web-server runs. For example: svn repository located at /var/svn/repos, I wanna dump repository to /var/www, but in /var/svn/repos no files I needed.
PSS sorry for my bad english =\
The Subversion repository isn't in a readable format that you can peruse like you could with CVS. To read the files in the repository you need someone with a client somewhere.
If your Subversion repository uses Apache httpd for its server, you can use wget or curl to pull off the last revision on a specific directory since as an added bonus, the Subversion Apache httpd modules allow you to see the latest version.
$ wget http://svn/repos/foo/trunk/myfile.java
The other option is to use a Subversion repository browser like (ViewVC)[http://www.viewvc.org/] or Sventon. These will allow you to browse the entire repository (including older revisions) without having to install the Subversion client on the local machine. I like Sventon because it doesn't have to run from the Subversion repository server.
If you're on Centos 5.5, you should already have the Subversion command line client installed on your system. In that case, if you don't want the .svn directories, use the svn export command instead of svn checkout.
Or, setup your web server to ignore the .svn directories. That way, you can do an svn update and update the files on your web server without having to redownload everything.
Well, if you have physical access to the server you could use the Subversion client on that box to export files/folders and then copy them from the server to the client machine. If you're trying to do this purely from the client, the only way I can think of would be to manually download the file(s) from the web client but this will only work if you're using Apache as your Subversion server.
Unless the server has an HTTP interface (is the repository URL prefixed with http://? Just open it up in a web browser), no.
It might be simplest to export the files you want on the server (svn export file://repo/path/to/directory), then copy them to the client using http or scp or something.