Merge branch 'docs/importing-refactor' into 'master'
Move workflow/importing/ to user/project/import/ See merge request !13593
|
@ -13,4 +13,4 @@
|
||||||
%li
|
%li
|
||||||
The import will time out after 15 minutes. For repositories that take longer, use a clone/push combination.
|
The import will time out after 15 minutes. For repositories that take longer, use a clone/push combination.
|
||||||
%li
|
%li
|
||||||
To migrate an SVN repository, check out #{link_to "this document", help_page_path('workflow/importing/migrating_from_svn')}.
|
To migrate an SVN repository, check out #{link_to "this document", help_page_path('user/project/import/svn')}.
|
||||||
|
|
|
@ -102,7 +102,7 @@ Manage your [repositories](user/project/repository/index.md) from the UI (user i
|
||||||
|
|
||||||
### Migrate and import your projects from other platforms
|
### Migrate and import your projects from other platforms
|
||||||
|
|
||||||
- [Importing to GitLab](workflow/importing/README.md): Import your projects from GitHub, Bitbucket, GitLab.com, FogBugz and SVN into GitLab.
|
- [Importing to GitLab](user/project/import/index.md): Import your projects from GitHub, Bitbucket, GitLab.com, FogBugz and SVN into GitLab.
|
||||||
- [Migrating from SVN](workflow/importing/migrating_from_svn.md): Convert a SVN repository to Git and GitLab.
|
- [Migrating from SVN](workflow/importing/migrating_from_svn.md): Convert a SVN repository to Git and GitLab.
|
||||||
|
|
||||||
### Continuous Integration, Delivery, and Deployment
|
### Continuous Integration, Delivery, and Deployment
|
||||||
|
|
62
doc/user/project/import/bitbucket.md
Normal file
|
@ -0,0 +1,62 @@
|
||||||
|
# Import your project from Bitbucket to GitLab
|
||||||
|
|
||||||
|
Import your projects from Bitbucket to GitLab with minimal effort.
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
>**Note:**
|
||||||
|
The [Bitbucket integration][bb-import] must be first enabled in order to be
|
||||||
|
able to import your projects from Bitbucket. Ask your GitLab administrator
|
||||||
|
to enable this if not already.
|
||||||
|
|
||||||
|
- At its current state, the Bitbucket importer can import:
|
||||||
|
- the repository description (GitLab 7.7+)
|
||||||
|
- the Git repository data (GitLab 7.7+)
|
||||||
|
- the issues (GitLab 7.7+)
|
||||||
|
- the issue comments (GitLab 8.15+)
|
||||||
|
- the pull requests (GitLab 8.4+)
|
||||||
|
- the pull request comments (GitLab 8.15+)
|
||||||
|
- the milestones (GitLab 8.15+)
|
||||||
|
- the wiki (GitLab 8.15+)
|
||||||
|
- References to pull requests and issues are preserved (GitLab 8.7+)
|
||||||
|
- Repository public access is retained. If a repository is private in Bitbucket
|
||||||
|
it will be created as private in GitLab as well.
|
||||||
|
|
||||||
|
|
||||||
|
## How it works
|
||||||
|
|
||||||
|
When issues/pull requests are being imported, the Bitbucket importer tries to find
|
||||||
|
the Bitbucket author/assignee in GitLab's database using the Bitbucket ID. For this
|
||||||
|
to work, the Bitbucket author/assignee should have signed in beforehand in GitLab
|
||||||
|
and **associated their Bitbucket account**. If the user is not
|
||||||
|
found in GitLab's database, the project creator (most of the times the current
|
||||||
|
user that started the import process) is set as the author, but a reference on
|
||||||
|
the issue about the original Bitbucket author is kept.
|
||||||
|
|
||||||
|
The importer will create any new namespaces (groups) if they don't exist or in
|
||||||
|
the case the namespace is taken, the repository will be imported under the user's
|
||||||
|
namespace that started the import process.
|
||||||
|
|
||||||
|
## Importing your Bitbucket repositories
|
||||||
|
|
||||||
|
1. Sign in to GitLab and go to your dashboard.
|
||||||
|
1. Click on **New project**.
|
||||||
|
|
||||||
|
![New project in GitLab](img/bitbucket_import_new_project.png)
|
||||||
|
|
||||||
|
1. Click on the "Bitbucket" button
|
||||||
|
|
||||||
|
![Bitbucket](img/import_projects_from_new_project_page.png)
|
||||||
|
|
||||||
|
1. Grant GitLab access to your Bitbucket account
|
||||||
|
|
||||||
|
![Grant access](img/bitbucket_import_grant_access.png)
|
||||||
|
|
||||||
|
1. Click on the projects that you'd like to import or **Import all projects**.
|
||||||
|
You can also select the namespace under which each project will be
|
||||||
|
imported.
|
||||||
|
|
||||||
|
![Import projects](img/bitbucket_import_select_project.png)
|
||||||
|
|
||||||
|
[bb-import]: ../../../integration/bitbucket.md
|
||||||
|
[social sign-in]: ../../profile/account/social_sign_in.md
|
28
doc/user/project/import/fogbugz.md
Normal file
|
@ -0,0 +1,28 @@
|
||||||
|
# Import your project from FogBugz to GitLab
|
||||||
|
|
||||||
|
It only takes a few simple steps to import your project from FogBugz.
|
||||||
|
The importer will import all of your cases and comments with original case
|
||||||
|
numbers and timestamps. You will also have the opportunity to map FogBugz
|
||||||
|
users to GitLab users.
|
||||||
|
|
||||||
|
1. From your GitLab dashboard click 'New project'
|
||||||
|
1. Click on the 'FogBugz' button
|
||||||
|
|
||||||
|
![FogBugz](img/fogbugz_import_select_fogbogz.png)
|
||||||
|
|
||||||
|
1. Enter your FogBugz URL, email address, and password.
|
||||||
|
|
||||||
|
![Login](img/fogbugz_import_login.png)
|
||||||
|
|
||||||
|
1. Create mapping from FogBugz users to GitLab users.
|
||||||
|
|
||||||
|
![User Map](img/fogbugz_import_user_map.png)
|
||||||
|
|
||||||
|
1. Select the projects you wish to import by clicking the Import buttons
|
||||||
|
|
||||||
|
![Import Project](img/fogbugz_import_select_project.png)
|
||||||
|
|
||||||
|
1. Once the import has finished click the link to take you to the project
|
||||||
|
dashboard. Follow the directions to push your existing repository.
|
||||||
|
|
||||||
|
![Finished](img/fogbugz_import_finished.png)
|
77
doc/user/project/import/gitea.md
Normal file
|
@ -0,0 +1,77 @@
|
||||||
|
# Import your project from Gitea to GitLab
|
||||||
|
|
||||||
|
Import your projects from Gitea to GitLab with minimal effort.
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
>**Note:**
|
||||||
|
This requires Gitea `v1.0.0` or newer.
|
||||||
|
|
||||||
|
- At its current state, Gitea importer can import:
|
||||||
|
- the repository description (GitLab 8.15+)
|
||||||
|
- the Git repository data (GitLab 8.15+)
|
||||||
|
- the issues (GitLab 8.15+)
|
||||||
|
- the pull requests (GitLab 8.15+)
|
||||||
|
- the milestones (GitLab 8.15+)
|
||||||
|
- the labels (GitLab 8.15+)
|
||||||
|
- Repository public access is retained. If a repository is private in Gitea
|
||||||
|
it will be created as private in GitLab as well.
|
||||||
|
|
||||||
|
## How it works
|
||||||
|
|
||||||
|
Since Gitea is currently not an OAuth provider, author/assignee cannot be mapped
|
||||||
|
to users in your GitLab's instance. This means that the project creator (most of
|
||||||
|
the times the current user that started the import process) is set as the author,
|
||||||
|
but a reference on the issue about the original Gitea author is kept.
|
||||||
|
|
||||||
|
The importer will create any new namespaces (groups) if they don't exist or in
|
||||||
|
the case the namespace is taken, the repository will be imported under the user's
|
||||||
|
namespace that started the import process.
|
||||||
|
|
||||||
|
## Importing your Gitea repositories
|
||||||
|
|
||||||
|
The importer page is visible when you create a new project.
|
||||||
|
|
||||||
|
![New project page on GitLab](img/import_projects_from_new_project_page.png)
|
||||||
|
|
||||||
|
Click on the **Gitea** link and the import authorization process will start.
|
||||||
|
|
||||||
|
![New Gitea project import](img/import_projects_from_gitea_new_import.png)
|
||||||
|
|
||||||
|
### Authorize access to your repositories using a personal access token
|
||||||
|
|
||||||
|
With this method, you will perform a one-off authorization with Gitea to grant
|
||||||
|
GitLab access your repositories:
|
||||||
|
|
||||||
|
1. Go to <https://you-gitea-instance/user/settings/applications> (replace
|
||||||
|
`you-gitea-instance` with the host of your Gitea instance).
|
||||||
|
1. Click **Generate New Token**.
|
||||||
|
1. Enter a token description.
|
||||||
|
1. Click **Generate Token**.
|
||||||
|
1. Copy the token hash.
|
||||||
|
1. Go back to GitLab and provide the token to the Gitea importer.
|
||||||
|
1. Hit the **List Your Gitea Repositories** button and wait while GitLab reads
|
||||||
|
your repositories' information. Once done, you'll be taken to the importer
|
||||||
|
page to select the repositories to import.
|
||||||
|
|
||||||
|
### Select which repositories to import
|
||||||
|
|
||||||
|
After you've authorized access to your Gitea repositories, you will be
|
||||||
|
redirected to the Gitea importer page.
|
||||||
|
|
||||||
|
From there, you can see the import statuses of your Gitea repositories.
|
||||||
|
|
||||||
|
- Those that are being imported will show a _started_ status,
|
||||||
|
- those already successfully imported will be green with a _done_ status,
|
||||||
|
- whereas those that are not yet imported will have an **Import** button on the
|
||||||
|
right side of the table.
|
||||||
|
|
||||||
|
If you want, you can import all your Gitea projects in one go by hitting
|
||||||
|
**Import all projects** in the upper left corner.
|
||||||
|
|
||||||
|
![Gitea importer page](img/import_projects_from_github_importer.png)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
You can also choose a different name for the project and a different namespace,
|
||||||
|
if you have the privileges to do so.
|
122
doc/user/project/import/github.md
Normal file
|
@ -0,0 +1,122 @@
|
||||||
|
# Import your project from GitHub to GitLab
|
||||||
|
|
||||||
|
Import your projects from GitHub to GitLab with minimal effort.
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
>**Note:**
|
||||||
|
If you are an administrator you can enable the [GitHub integration][gh-import]
|
||||||
|
in your GitLab instance sitewide. This configuration is optional, users will
|
||||||
|
still be able to import their GitHub repositories with a
|
||||||
|
[personal access token][gh-token].
|
||||||
|
|
||||||
|
>**Note:**
|
||||||
|
Administrators of a GitLab instance (Community or Enterprise Edition) can also
|
||||||
|
use the [GitHub rake task][gh-rake] to import projects from GitHub without the
|
||||||
|
constrains of a Sidekiq worker.
|
||||||
|
|
||||||
|
- At its current state, GitHub importer can import:
|
||||||
|
- the repository description (GitLab 7.7+)
|
||||||
|
- the Git repository data (GitLab 7.7+)
|
||||||
|
- the issues (GitLab 7.7+)
|
||||||
|
- the pull requests (GitLab 8.4+)
|
||||||
|
- the wiki pages (GitLab 8.4+)
|
||||||
|
- the milestones (GitLab 8.7+)
|
||||||
|
- the labels (GitLab 8.7+)
|
||||||
|
- the release note descriptions (GitLab 8.12+)
|
||||||
|
- References to pull requests and issues are preserved (GitLab 8.7+)
|
||||||
|
- Repository public access is retained. If a repository is private in GitHub
|
||||||
|
it will be created as private in GitLab as well.
|
||||||
|
|
||||||
|
## How it works
|
||||||
|
|
||||||
|
When issues/pull requests are being imported, the GitHub importer tries to find
|
||||||
|
the GitHub author/assignee in GitLab's database using the GitHub ID. For this
|
||||||
|
to work, the GitHub author/assignee should have signed in beforehand in GitLab
|
||||||
|
and **associated their GitHub account**. If the user is not
|
||||||
|
found in GitLab's database, the project creator (most of the times the current
|
||||||
|
user that started the import process) is set as the author, but a reference on
|
||||||
|
the issue about the original GitHub author is kept.
|
||||||
|
|
||||||
|
The importer will create any new namespaces (groups) if they don't exist or in
|
||||||
|
the case the namespace is taken, the repository will be imported under the user's
|
||||||
|
namespace that started the import process.
|
||||||
|
|
||||||
|
## Importing your GitHub repositories
|
||||||
|
|
||||||
|
The importer page is visible when you create a new project.
|
||||||
|
|
||||||
|
![New project page on GitLab](img/import_projects_from_new_project_page.png)
|
||||||
|
|
||||||
|
Click on the **GitHub** link and the import authorization process will start.
|
||||||
|
There are two ways to authorize access to your GitHub repositories:
|
||||||
|
|
||||||
|
1. [Using the GitHub integration][gh-integration] (if it's enabled by your
|
||||||
|
GitLab administrator). This is the preferred way as it's possible to
|
||||||
|
preserve the GitHub authors/assignees. Read more in the [How it works](#how-it-works)
|
||||||
|
section.
|
||||||
|
1. [Using a personal access token][gh-token] provided by GitHub.
|
||||||
|
|
||||||
|
![Select authentication method](img/import_projects_from_github_select_auth_method.png)
|
||||||
|
|
||||||
|
### Authorize access to your repositories using the GitHub integration
|
||||||
|
|
||||||
|
If the [GitHub integration][gh-import] is enabled by your GitLab administrator,
|
||||||
|
you can use it instead of the personal access token.
|
||||||
|
|
||||||
|
1. First you may want to connect your GitHub account to GitLab in order for
|
||||||
|
the username mapping to be correct.
|
||||||
|
1. Once you connect GitHub, click the **List your GitHub repositories** button
|
||||||
|
and you will be redirected to GitHub for permission to access your projects.
|
||||||
|
1. After accepting, you'll be automatically redirected to the importer.
|
||||||
|
|
||||||
|
You can now go on and [select which repositories to import](#select-which-repositories-to-import).
|
||||||
|
|
||||||
|
### Authorize access to your repositories using a personal access token
|
||||||
|
|
||||||
|
>**Note:**
|
||||||
|
For a proper author/assignee mapping for issues and pull requests, the
|
||||||
|
[GitHub integration][gh-integration] should be used instead of the
|
||||||
|
[personal access token][gh-token]. If the GitHub integration is enabled by your
|
||||||
|
GitLab administrator, it should be the preferred method to import your repositories.
|
||||||
|
Read more in the [How it works](#how-it-works) section.
|
||||||
|
|
||||||
|
If you are not using the GitHub integration, you can still perform a one-off
|
||||||
|
authorization with GitHub to grant GitLab access your repositories:
|
||||||
|
|
||||||
|
1. Go to <https://github.com/settings/tokens/new>.
|
||||||
|
1. Enter a token description.
|
||||||
|
1. Check the `repo` scope.
|
||||||
|
1. Click **Generate token**.
|
||||||
|
1. Copy the token hash.
|
||||||
|
1. Go back to GitLab and provide the token to the GitHub importer.
|
||||||
|
1. Hit the **List Your GitHub Repositories** button and wait while GitLab reads
|
||||||
|
your repositories' information. Once done, you'll be taken to the importer
|
||||||
|
page to select the repositories to import.
|
||||||
|
|
||||||
|
### Select which repositories to import
|
||||||
|
|
||||||
|
After you've authorized access to your GitHub repositories, you will be
|
||||||
|
redirected to the GitHub importer page.
|
||||||
|
|
||||||
|
From there, you can see the import statuses of your GitHub repositories.
|
||||||
|
|
||||||
|
- Those that are being imported will show a _started_ status,
|
||||||
|
- those already successfully imported will be green with a _done_ status,
|
||||||
|
- whereas those that are not yet imported will have an **Import** button on the
|
||||||
|
right side of the table.
|
||||||
|
|
||||||
|
If you want, you can import all your GitHub projects in one go by hitting
|
||||||
|
**Import all projects** in the upper left corner.
|
||||||
|
|
||||||
|
![GitHub importer page](img/import_projects_from_github_importer.png)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
You can also choose a different name for the project and a different namespace,
|
||||||
|
if you have the privileges to do so.
|
||||||
|
|
||||||
|
[gh-import]: ../../../integration/github.md "GitHub integration"
|
||||||
|
[gh-rake]: ../../../administration/raketasks/github_import.md "GitHub rake task"
|
||||||
|
[gh-integration]: #authorize-access-to-your-repositories-using-the-github-integration
|
||||||
|
[gh-token]: #authorize-access-to-your-repositories-using-a-personal-access-token
|
20
doc/user/project/import/gitlab_com.md
Normal file
|
@ -0,0 +1,20 @@
|
||||||
|
# Project importing from GitLab.com to your private GitLab instance
|
||||||
|
|
||||||
|
You can import your existing GitLab.com projects to your GitLab instance. But keep in mind that it is possible only if
|
||||||
|
GitLab support is enabled on your GitLab instance.
|
||||||
|
You can read more about GitLab support [here](http://docs.gitlab.com/ce/integration/gitlab.html)
|
||||||
|
To get to the importer page you need to go to "New project" page.
|
||||||
|
|
||||||
|
>**Note:**
|
||||||
|
If you are interested in importing Wiki and Merge Request data to your new
|
||||||
|
instance, you'll need to follow the instructions for [project export](../settings/import_export.md)
|
||||||
|
|
||||||
|
![New project page](img/gitlab_new_project_page.png)
|
||||||
|
|
||||||
|
Click on the "Import projects from GitLab.com" link and you will be redirected to GitLab.com
|
||||||
|
for permission to access your projects. After accepting, you'll be automatically redirected to the importer.
|
||||||
|
|
||||||
|
![Importer page](img/gitlab_importer.png)
|
||||||
|
|
||||||
|
To import a project, you can simple click "Import". The importer will import your repository and issues.
|
||||||
|
Once the importer is done, a new GitLab project will be created with your imported data.
|
Before Width: | Height: | Size: 7.1 KiB After Width: | Height: | Size: 7.1 KiB |
Before Width: | Height: | Size: 1.3 KiB After Width: | Height: | Size: 1.3 KiB |
Before Width: | Height: | Size: 8.5 KiB After Width: | Height: | Size: 8.5 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 50 KiB After Width: | Height: | Size: 50 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 36 KiB After Width: | Height: | Size: 36 KiB |
20
doc/user/project/import/index.md
Normal file
|
@ -0,0 +1,20 @@
|
||||||
|
# Migrating projects to a GitLab instance
|
||||||
|
|
||||||
|
1. [From Bitbucket.org](bitbucket.md)
|
||||||
|
1. [From GitHub.com of GitHub Enterprise](github.md)
|
||||||
|
1. [From GitLab.com](gitlab_com.md)
|
||||||
|
1. [From FogBugz](fogbugz.md)
|
||||||
|
1. [From Gitea](gitea.md)
|
||||||
|
1. [From SVN](svn.md)
|
||||||
|
|
||||||
|
In addition to the specific migration documentation above, you can import any
|
||||||
|
Git repository via HTTP from the New Project page. Be aware that if the
|
||||||
|
repository is too large the import can timeout.
|
||||||
|
|
||||||
|
## Migrating from self-hosted GitLab to GitLab.com
|
||||||
|
|
||||||
|
You can copy your repos by changing the remote and pushing to the new server,
|
||||||
|
but issues and merge requests can't be imported.
|
||||||
|
|
||||||
|
If you want to retain all metadata like issues and merge requests, you can use
|
||||||
|
the [import/export feature](../settings/import_export.md).
|
183
doc/user/project/import/svn.md
Normal file
|
@ -0,0 +1,183 @@
|
||||||
|
# Migrating from SVN to GitLab
|
||||||
|
|
||||||
|
Subversion (SVN) is a central version control system (VCS) while
|
||||||
|
Git is a distributed version control system. There are some major differences
|
||||||
|
between the two, for more information consult your favorite search engine.
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
There are two approaches to SVN to Git migration:
|
||||||
|
|
||||||
|
1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which:
|
||||||
|
- Makes the GitLab repository to mirror the SVN project.
|
||||||
|
- Git and SVN repositories are kept in sync; you can use either one.
|
||||||
|
- Smoothens the migration process and allows to manage migration risks.
|
||||||
|
|
||||||
|
1. [Cut over migration](#cut-over-migration-with-svn2git) which:
|
||||||
|
- Translates and imports the existing data and history from SVN to Git.
|
||||||
|
- Is a fire and forget approach, good for smaller teams.
|
||||||
|
|
||||||
|
## Smooth migration with a Git/SVN mirror using SubGit
|
||||||
|
|
||||||
|
[SubGit](https://subgit.com) is a tool for a smooth, stress-free SVN to Git
|
||||||
|
migration. It creates a writable Git mirror of a local or remote Subversion
|
||||||
|
repository and that way you can use both Subversion and Git as long as you like.
|
||||||
|
It requires access to your GitLab server as it talks with the Git repositories
|
||||||
|
directly in a filesystem level.
|
||||||
|
|
||||||
|
### SubGit prerequisites
|
||||||
|
|
||||||
|
1. Install Oracle JRE 1.8 or newer. On Debian-based Linux distributions you can
|
||||||
|
follow [this article](http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html).
|
||||||
|
1. Download SubGit from https://subgit.com/download/.
|
||||||
|
1. Unpack the downloaded SubGit zip archive to the `/opt` directory. The `subgit`
|
||||||
|
command will be available at `/opt/subgit-VERSION/bin/subgit`.
|
||||||
|
|
||||||
|
### SubGit configuration
|
||||||
|
|
||||||
|
The first step to mirror you SVN repository in GitLab is to create a new empty
|
||||||
|
project which will be used as a mirror. For Omnibus installations the path to
|
||||||
|
the repository will be located at
|
||||||
|
`/var/opt/gitlab/git-data/repositories/USER/REPO.git` by default. For
|
||||||
|
installations from source, the default repository directory will be
|
||||||
|
`/home/git/repositories/USER/REPO.git`. For convenience, assign this path to a
|
||||||
|
variable:
|
||||||
|
|
||||||
|
```
|
||||||
|
GIT_REPO_PATH=/var/opt/gitlab/git-data/repositories/USER/REPOS.git
|
||||||
|
```
|
||||||
|
|
||||||
|
SubGit will keep this repository in sync with a remote SVN project. For
|
||||||
|
convenience, assign your remote SVN project URL to a variable:
|
||||||
|
|
||||||
|
```
|
||||||
|
SVN_PROJECT_URL=http://svn.company.com/repos/project
|
||||||
|
```
|
||||||
|
|
||||||
|
Next you need to run SubGit to set up a Git/SVN mirror. Make sure the following
|
||||||
|
`subgit` command is ran on behalf of the same user that keeps ownership of
|
||||||
|
GitLab Git repositories (by default `git`):
|
||||||
|
|
||||||
|
```
|
||||||
|
subgit configure --layout auto $SVN_PROJECT_URL $GIT_REPO_PATH
|
||||||
|
```
|
||||||
|
|
||||||
|
Adjust authors and branches mappings, if necessary. Open with your favorite
|
||||||
|
text editor:
|
||||||
|
|
||||||
|
```
|
||||||
|
edit $GIT_REPO_PATH/subgit/authors.txt
|
||||||
|
edit $GIT_REPO_PATH/subgit/config
|
||||||
|
```
|
||||||
|
|
||||||
|
For more information regarding the SubGit configuration options, refer to
|
||||||
|
[SubGit's documentation](https://subgit.com/documentation.html) website.
|
||||||
|
|
||||||
|
### Initial translation
|
||||||
|
|
||||||
|
Now that SubGit has configured the Git/SVN repos, run `subgit` to perform the
|
||||||
|
initial translation of existing SVN revisions into the Git repository:
|
||||||
|
|
||||||
|
```
|
||||||
|
subgit install $GIT_REPO_PATH
|
||||||
|
```
|
||||||
|
|
||||||
|
After the initial translation is completed, the Git repository and the SVN
|
||||||
|
project will be kept in sync by `subgit` - new Git commits will be translated to
|
||||||
|
SVN revisions and new SVN revisions will be translated to Git commits. Mirror
|
||||||
|
works transparently and does not require any special commands.
|
||||||
|
|
||||||
|
If you would prefer to perform one-time cut over migration with `subgit`, use
|
||||||
|
the `import` command instead of `install`:
|
||||||
|
|
||||||
|
```
|
||||||
|
subgit import $GIT_REPO_PATH
|
||||||
|
```
|
||||||
|
|
||||||
|
### SubGit licensing
|
||||||
|
|
||||||
|
Running SubGit in a mirror mode requires a
|
||||||
|
[registration](https://subgit.com/pricing.html). Registration is free for open
|
||||||
|
source, academic and startup projects.
|
||||||
|
|
||||||
|
We're currently working on deeper GitLab/SubGit integration. You may track our
|
||||||
|
progress at [this issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/990).
|
||||||
|
|
||||||
|
### SubGit support
|
||||||
|
|
||||||
|
For any questions related to SVN to GitLab migration with SubGit, you can
|
||||||
|
contact the SubGit team directly at [support@subgit.com](mailto:support@subgit.com).
|
||||||
|
|
||||||
|
## Cut over migration with svn2git
|
||||||
|
|
||||||
|
If you are currently using an SVN repository, you can migrate the repository
|
||||||
|
to Git and GitLab. We recommend a hard cut over - run the migration command once
|
||||||
|
and then have all developers start using the new GitLab repository immediately.
|
||||||
|
Otherwise, it's hard to keep changing in sync in both directions. The conversion
|
||||||
|
process should be run on a local workstation.
|
||||||
|
|
||||||
|
Install `svn2git`. On all systems you can install as a Ruby gem if you already
|
||||||
|
have Ruby and Git installed.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo gem install svn2git
|
||||||
|
```
|
||||||
|
|
||||||
|
On Debian-based Linux distributions you can install the native packages:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
sudo apt-get install git-core git-svn ruby
|
||||||
|
```
|
||||||
|
|
||||||
|
Optionally, prepare an authors file so `svn2git` can map SVN authors to Git authors.
|
||||||
|
If you choose not to create the authors file then commits will not be attributed
|
||||||
|
to the correct GitLab user. Some users may not consider this a big issue while
|
||||||
|
others will want to ensure they complete this step. If you choose to map authors
|
||||||
|
you will be required to map every author that is present on changes in the SVN
|
||||||
|
repository. If you don't, the conversion will fail and you will have to update
|
||||||
|
the author file accordingly. The following command will search through the
|
||||||
|
repository and output a list of authors.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
svn log --quiet | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | sort | uniq
|
||||||
|
```
|
||||||
|
|
||||||
|
Use the output from the last command to construct the authors file.
|
||||||
|
Create a file called `authors.txt` and add one mapping per line.
|
||||||
|
|
||||||
|
```
|
||||||
|
janedoe = Jane Doe <janedoe@example.com>
|
||||||
|
johndoe = John Doe <johndoe@example.com>
|
||||||
|
```
|
||||||
|
|
||||||
|
If your SVN repository is in the standard format (trunk, branches, tags,
|
||||||
|
not nested) the conversion is simple. For a non-standard repository see
|
||||||
|
[svn2git documentation](https://github.com/nirvdrum/svn2git). The following
|
||||||
|
command will checkout the repository and do the conversion in the current
|
||||||
|
working directory. Be sure to create a new directory for each repository before
|
||||||
|
running the `svn2git` command. The conversion process will take some time.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt
|
||||||
|
```
|
||||||
|
|
||||||
|
If your SVN repository requires a username and password add the
|
||||||
|
`--username <username>` and `--password <password` flags to the above command.
|
||||||
|
`svn2git` also supports excluding certain file paths, branches, tags, etc. See
|
||||||
|
[svn2git documentation](https://github.com/nirvdrum/svn2git) or run
|
||||||
|
`svn2git --help` for full documentation on all of the available options.
|
||||||
|
|
||||||
|
Create a new GitLab project, where you will eventually push your converted code.
|
||||||
|
Copy the SSH or HTTP(S) repository URL from the project page. Add the GitLab
|
||||||
|
repository as a Git remote and push all the changes. This will push all commits,
|
||||||
|
branches and tags.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
git remote add origin git@gitlab.com:<group>/<project>.git
|
||||||
|
git push --all origin
|
||||||
|
git push --tags origin
|
||||||
|
```
|
||||||
|
|
||||||
|
## Contribute to this guide
|
||||||
|
We welcome all contributions that would expand this guide with instructions on
|
||||||
|
how to migrate from SVN and other version control systems.
|
|
@ -90,11 +90,11 @@ from your fork to the upstream project
|
||||||
|
|
||||||
## Import or export a project
|
## Import or export a project
|
||||||
|
|
||||||
- Import a project from:
|
- [Import a project](import/index.md) from:
|
||||||
- [GitHub to GitLab](../../workflow/importing/import_projects_from_github.md)
|
- [GitHub to GitLab](import/github.md)
|
||||||
- [BitBucket to GitLab](../../workflow/importing/import_projects_from_bitbucket.md)
|
- [BitBucket to GitLab](import/bitbucket.md)
|
||||||
- [Gitea to GitLab](../../workflow/importing/import_projects_from_gitea.md)
|
- [Gitea to GitLab](import/gitea.md)
|
||||||
- [FogBugz to GitLab](../../workflow/importing/import_projects_from_fogbugz.md)
|
- [FogBugz to GitLab](import/fogbugz.md)
|
||||||
- [Export a project from GitLab](settings/import_export.md#exporting-a-project-and-its-data)
|
- [Export a project from GitLab](settings/import_export.md#exporting-a-project-and-its-data)
|
||||||
- [Importing and exporting projects between GitLab instances](settings/import_export.md)
|
- [Importing and exporting projects between GitLab instances](settings/import_export.md)
|
||||||
|
|
||||||
|
|
|
@ -1,17 +1 @@
|
||||||
# Migrating projects to a GitLab instance
|
This document was moved to a [new location](../../user/project/import/index.md).
|
||||||
|
|
||||||
1. [Bitbucket](import_projects_from_bitbucket.md)
|
|
||||||
1. [GitHub](import_projects_from_github.md)
|
|
||||||
1. [GitLab.com](import_projects_from_gitlab_com.md)
|
|
||||||
1. [FogBugz](import_projects_from_fogbugz.md)
|
|
||||||
1. [Gitea](import_projects_from_gitea.md)
|
|
||||||
1. [SVN](migrating_from_svn.md)
|
|
||||||
|
|
||||||
In addition to the specific migration documentation above, you can import any
|
|
||||||
Git repository via HTTP from the New Project page. Be aware that if the
|
|
||||||
repository is too large the import can timeout.
|
|
||||||
|
|
||||||
### Migrating from self-hosted GitLab to GitLab.com
|
|
||||||
|
|
||||||
You can copy your repos by changing the remote and pushing to the new server;
|
|
||||||
but issues and merge requests can't be imported.
|
|
||||||
|
|
|
@ -1,62 +1 @@
|
||||||
# Import your project from Bitbucket to GitLab
|
This document was moved to a [new location](../../user/project/import/bitbucket.md).
|
||||||
|
|
||||||
Import your projects from Bitbucket to GitLab with minimal effort.
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
>**Note:**
|
|
||||||
The [Bitbucket integration][bb-import] must be first enabled in order to be
|
|
||||||
able to import your projects from Bitbucket. Ask your GitLab administrator
|
|
||||||
to enable this if not already.
|
|
||||||
|
|
||||||
- At its current state, the Bitbucket importer can import:
|
|
||||||
- the repository description (GitLab 7.7+)
|
|
||||||
- the Git repository data (GitLab 7.7+)
|
|
||||||
- the issues (GitLab 7.7+)
|
|
||||||
- the issue comments (GitLab 8.15+)
|
|
||||||
- the pull requests (GitLab 8.4+)
|
|
||||||
- the pull request comments (GitLab 8.15+)
|
|
||||||
- the milestones (GitLab 8.15+)
|
|
||||||
- the wiki (GitLab 8.15+)
|
|
||||||
- References to pull requests and issues are preserved (GitLab 8.7+)
|
|
||||||
- Repository public access is retained. If a repository is private in Bitbucket
|
|
||||||
it will be created as private in GitLab as well.
|
|
||||||
|
|
||||||
|
|
||||||
## How it works
|
|
||||||
|
|
||||||
When issues/pull requests are being imported, the Bitbucket importer tries to find
|
|
||||||
the Bitbucket author/assignee in GitLab's database using the Bitbucket ID. For this
|
|
||||||
to work, the Bitbucket author/assignee should have signed in beforehand in GitLab
|
|
||||||
and **associated their Bitbucket account**. If the user is not
|
|
||||||
found in GitLab's database, the project creator (most of the times the current
|
|
||||||
user that started the import process) is set as the author, but a reference on
|
|
||||||
the issue about the original Bitbucket author is kept.
|
|
||||||
|
|
||||||
The importer will create any new namespaces (groups) if they don't exist or in
|
|
||||||
the case the namespace is taken, the repository will be imported under the user's
|
|
||||||
namespace that started the import process.
|
|
||||||
|
|
||||||
## Importing your Bitbucket repositories
|
|
||||||
|
|
||||||
1. Sign in to GitLab and go to your dashboard.
|
|
||||||
1. Click on **New project**.
|
|
||||||
|
|
||||||
![New project in GitLab](img/bitbucket_import_new_project.png)
|
|
||||||
|
|
||||||
1. Click on the "Bitbucket" button
|
|
||||||
|
|
||||||
![Bitbucket](img/import_projects_from_new_project_page.png)
|
|
||||||
|
|
||||||
1. Grant GitLab access to your Bitbucket account
|
|
||||||
|
|
||||||
![Grant access](img/bitbucket_import_grant_access.png)
|
|
||||||
|
|
||||||
1. Click on the projects that you'd like to import or **Import all projects**.
|
|
||||||
You can also select the namespace under which each project will be
|
|
||||||
imported.
|
|
||||||
|
|
||||||
![Import projects](img/bitbucket_import_select_project.png)
|
|
||||||
|
|
||||||
[bb-import]: ../../integration/bitbucket.md
|
|
||||||
[social sign-in]: ../../user/profile/account/social_sign_in.md
|
|
||||||
|
|
|
@ -1,29 +1 @@
|
||||||
# Import your project from FogBugz to GitLab
|
This document was moved to a [new location](../../user/project/import/fogbugz.md).
|
||||||
|
|
||||||
It only takes a few simple steps to import your project from FogBugz.
|
|
||||||
The importer will import all of your cases and comments with original case
|
|
||||||
numbers and timestamps. You will also have the opportunity to map FogBugz
|
|
||||||
users to GitLab users.
|
|
||||||
|
|
||||||
* From your GitLab dashboard click 'New project'
|
|
||||||
|
|
||||||
* Click on the 'FogBugz' button
|
|
||||||
|
|
||||||
![FogBugz](fogbugz_importer/fogbugz_import_select_fogbogz.png)
|
|
||||||
|
|
||||||
* Enter your FogBugz URL, email address, and password.
|
|
||||||
|
|
||||||
![Login](fogbugz_importer/fogbugz_import_login.png)
|
|
||||||
|
|
||||||
* Create mapping from FogBugz users to GitLab users.
|
|
||||||
|
|
||||||
![User Map](fogbugz_importer/fogbugz_import_user_map.png)
|
|
||||||
|
|
||||||
* Select the projects you wish to import by clicking the Import buttons
|
|
||||||
|
|
||||||
![Import Project](fogbugz_importer/fogbugz_import_select_project.png)
|
|
||||||
|
|
||||||
* Once the import has finished click the link to take you to the project
|
|
||||||
dashboard. Follow the directions to push your existing repository.
|
|
||||||
|
|
||||||
![Finished](fogbugz_importer/fogbugz_import_finished.png)
|
|
||||||
|
|
|
@ -1,77 +1 @@
|
||||||
# Import your project from Gitea to GitLab
|
This document was moved to a [new location](../../user/project/import/gitea.md).
|
||||||
|
|
||||||
Import your projects from Gitea to GitLab with minimal effort.
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
>**Note:**
|
|
||||||
This requires Gitea `v1.0.0` or newer.
|
|
||||||
|
|
||||||
- At its current state, Gitea importer can import:
|
|
||||||
- the repository description (GitLab 8.15+)
|
|
||||||
- the Git repository data (GitLab 8.15+)
|
|
||||||
- the issues (GitLab 8.15+)
|
|
||||||
- the pull requests (GitLab 8.15+)
|
|
||||||
- the milestones (GitLab 8.15+)
|
|
||||||
- the labels (GitLab 8.15+)
|
|
||||||
- Repository public access is retained. If a repository is private in Gitea
|
|
||||||
it will be created as private in GitLab as well.
|
|
||||||
|
|
||||||
## How it works
|
|
||||||
|
|
||||||
Since Gitea is currently not an OAuth provider, author/assignee cannot be mapped
|
|
||||||
to users in your GitLab's instance. This means that the project creator (most of
|
|
||||||
the times the current user that started the import process) is set as the author,
|
|
||||||
but a reference on the issue about the original Gitea author is kept.
|
|
||||||
|
|
||||||
The importer will create any new namespaces (groups) if they don't exist or in
|
|
||||||
the case the namespace is taken, the repository will be imported under the user's
|
|
||||||
namespace that started the import process.
|
|
||||||
|
|
||||||
## Importing your Gitea repositories
|
|
||||||
|
|
||||||
The importer page is visible when you create a new project.
|
|
||||||
|
|
||||||
![New project page on GitLab](img/import_projects_from_new_project_page.png)
|
|
||||||
|
|
||||||
Click on the **Gitea** link and the import authorization process will start.
|
|
||||||
|
|
||||||
![New Gitea project import](img/import_projects_from_gitea_new_import.png)
|
|
||||||
|
|
||||||
### Authorize access to your repositories using a personal access token
|
|
||||||
|
|
||||||
With this method, you will perform a one-off authorization with Gitea to grant
|
|
||||||
GitLab access your repositories:
|
|
||||||
|
|
||||||
1. Go to <https://you-gitea-instance/user/settings/applications> (replace
|
|
||||||
`you-gitea-instance` with the host of your Gitea instance).
|
|
||||||
1. Click **Generate New Token**.
|
|
||||||
1. Enter a token description.
|
|
||||||
1. Click **Generate Token**.
|
|
||||||
1. Copy the token hash.
|
|
||||||
1. Go back to GitLab and provide the token to the Gitea importer.
|
|
||||||
1. Hit the **List Your Gitea Repositories** button and wait while GitLab reads
|
|
||||||
your repositories' information. Once done, you'll be taken to the importer
|
|
||||||
page to select the repositories to import.
|
|
||||||
|
|
||||||
### Select which repositories to import
|
|
||||||
|
|
||||||
After you've authorized access to your Gitea repositories, you will be
|
|
||||||
redirected to the Gitea importer page.
|
|
||||||
|
|
||||||
From there, you can see the import statuses of your Gitea repositories.
|
|
||||||
|
|
||||||
- Those that are being imported will show a _started_ status,
|
|
||||||
- those already successfully imported will be green with a _done_ status,
|
|
||||||
- whereas those that are not yet imported will have an **Import** button on the
|
|
||||||
right side of the table.
|
|
||||||
|
|
||||||
If you want, you can import all your Gitea projects in one go by hitting
|
|
||||||
**Import all projects** in the upper left corner.
|
|
||||||
|
|
||||||
![Gitea importer page](img/import_projects_from_github_importer.png)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
You can also choose a different name for the project and a different namespace,
|
|
||||||
if you have the privileges to do so.
|
|
||||||
|
|
|
@ -1,122 +1 @@
|
||||||
# Import your project from GitHub to GitLab
|
This document was moved to a [new location](../../user/project/import/github.md).
|
||||||
|
|
||||||
Import your projects from GitHub to GitLab with minimal effort.
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
>**Note:**
|
|
||||||
If you are an administrator you can enable the [GitHub integration][gh-import]
|
|
||||||
in your GitLab instance sitewide. This configuration is optional, users will
|
|
||||||
still be able to import their GitHub repositories with a
|
|
||||||
[personal access token][gh-token].
|
|
||||||
|
|
||||||
>**Note:**
|
|
||||||
Administrators of a GitLab instance (Community or Enterprise Edition) can also
|
|
||||||
use the [GitHub rake task][gh-rake] to import projects from GitHub without the
|
|
||||||
constrains of a Sidekiq worker.
|
|
||||||
|
|
||||||
- At its current state, GitHub importer can import:
|
|
||||||
- the repository description (GitLab 7.7+)
|
|
||||||
- the Git repository data (GitLab 7.7+)
|
|
||||||
- the issues (GitLab 7.7+)
|
|
||||||
- the pull requests (GitLab 8.4+)
|
|
||||||
- the wiki pages (GitLab 8.4+)
|
|
||||||
- the milestones (GitLab 8.7+)
|
|
||||||
- the labels (GitLab 8.7+)
|
|
||||||
- the release note descriptions (GitLab 8.12+)
|
|
||||||
- References to pull requests and issues are preserved (GitLab 8.7+)
|
|
||||||
- Repository public access is retained. If a repository is private in GitHub
|
|
||||||
it will be created as private in GitLab as well.
|
|
||||||
|
|
||||||
## How it works
|
|
||||||
|
|
||||||
When issues/pull requests are being imported, the GitHub importer tries to find
|
|
||||||
the GitHub author/assignee in GitLab's database using the GitHub ID. For this
|
|
||||||
to work, the GitHub author/assignee should have signed in beforehand in GitLab
|
|
||||||
and **associated their GitHub account**. If the user is not
|
|
||||||
found in GitLab's database, the project creator (most of the times the current
|
|
||||||
user that started the import process) is set as the author, but a reference on
|
|
||||||
the issue about the original GitHub author is kept.
|
|
||||||
|
|
||||||
The importer will create any new namespaces (groups) if they don't exist or in
|
|
||||||
the case the namespace is taken, the repository will be imported under the user's
|
|
||||||
namespace that started the import process.
|
|
||||||
|
|
||||||
## Importing your GitHub repositories
|
|
||||||
|
|
||||||
The importer page is visible when you create a new project.
|
|
||||||
|
|
||||||
![New project page on GitLab](img/import_projects_from_new_project_page.png)
|
|
||||||
|
|
||||||
Click on the **GitHub** link and the import authorization process will start.
|
|
||||||
There are two ways to authorize access to your GitHub repositories:
|
|
||||||
|
|
||||||
1. [Using the GitHub integration][gh-integration] (if it's enabled by your
|
|
||||||
GitLab administrator). This is the preferred way as it's possible to
|
|
||||||
preserve the GitHub authors/assignees. Read more in the [How it works](#how-it-works)
|
|
||||||
section.
|
|
||||||
1. [Using a personal access token][gh-token] provided by GitHub.
|
|
||||||
|
|
||||||
![Select authentication method](img/import_projects_from_github_select_auth_method.png)
|
|
||||||
|
|
||||||
### Authorize access to your repositories using the GitHub integration
|
|
||||||
|
|
||||||
If the [GitHub integration][gh-import] is enabled by your GitLab administrator,
|
|
||||||
you can use it instead of the personal access token.
|
|
||||||
|
|
||||||
1. First you may want to connect your GitHub account to GitLab in order for
|
|
||||||
the username mapping to be correct.
|
|
||||||
1. Once you connect GitHub, click the **List your GitHub repositories** button
|
|
||||||
and you will be redirected to GitHub for permission to access your projects.
|
|
||||||
1. After accepting, you'll be automatically redirected to the importer.
|
|
||||||
|
|
||||||
You can now go on and [select which repositories to import](#select-which-repositories-to-import).
|
|
||||||
|
|
||||||
### Authorize access to your repositories using a personal access token
|
|
||||||
|
|
||||||
>**Note:**
|
|
||||||
For a proper author/assignee mapping for issues and pull requests, the
|
|
||||||
[GitHub integration][gh-integration] should be used instead of the
|
|
||||||
[personal access token][gh-token]. If the GitHub integration is enabled by your
|
|
||||||
GitLab administrator, it should be the preferred method to import your repositories.
|
|
||||||
Read more in the [How it works](#how-it-works) section.
|
|
||||||
|
|
||||||
If you are not using the GitHub integration, you can still perform a one-off
|
|
||||||
authorization with GitHub to grant GitLab access your repositories:
|
|
||||||
|
|
||||||
1. Go to <https://github.com/settings/tokens/new>.
|
|
||||||
1. Enter a token description.
|
|
||||||
1. Check the `repo` scope.
|
|
||||||
1. Click **Generate token**.
|
|
||||||
1. Copy the token hash.
|
|
||||||
1. Go back to GitLab and provide the token to the GitHub importer.
|
|
||||||
1. Hit the **List Your GitHub Repositories** button and wait while GitLab reads
|
|
||||||
your repositories' information. Once done, you'll be taken to the importer
|
|
||||||
page to select the repositories to import.
|
|
||||||
|
|
||||||
### Select which repositories to import
|
|
||||||
|
|
||||||
After you've authorized access to your GitHub repositories, you will be
|
|
||||||
redirected to the GitHub importer page.
|
|
||||||
|
|
||||||
From there, you can see the import statuses of your GitHub repositories.
|
|
||||||
|
|
||||||
- Those that are being imported will show a _started_ status,
|
|
||||||
- those already successfully imported will be green with a _done_ status,
|
|
||||||
- whereas those that are not yet imported will have an **Import** button on the
|
|
||||||
right side of the table.
|
|
||||||
|
|
||||||
If you want, you can import all your GitHub projects in one go by hitting
|
|
||||||
**Import all projects** in the upper left corner.
|
|
||||||
|
|
||||||
![GitHub importer page](img/import_projects_from_github_importer.png)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
You can also choose a different name for the project and a different namespace,
|
|
||||||
if you have the privileges to do so.
|
|
||||||
|
|
||||||
[gh-import]: ../../integration/github.md "GitHub integration"
|
|
||||||
[gh-rake]: ../../administration/raketasks/github_import.md "GitHub rake task"
|
|
||||||
[gh-integration]: #authorize-access-to-your-repositories-using-the-github-integration
|
|
||||||
[gh-token]: #authorize-access-to-your-repositories-using-a-personal-access-token
|
|
||||||
|
|
|
@ -1,21 +1 @@
|
||||||
# Project importing from GitLab.com to your private GitLab instance
|
This document was moved to a [new location](../../user/project/import/gitlab_com.md).
|
||||||
|
|
||||||
You can import your existing GitLab.com projects to your GitLab instance. But keep in mind that it is possible only if
|
|
||||||
GitLab support is enabled on your GitLab instance.
|
|
||||||
You can read more about GitLab support [here](http://docs.gitlab.com/ce/integration/gitlab.html)
|
|
||||||
To get to the importer page you need to go to "New project" page.
|
|
||||||
|
|
||||||
>**Note:**
|
|
||||||
If you are interested in importing Wiki and Merge Request data to your new instance, you'll need to follow the instructions for [project export](../../user/project/settings/import_export.md)
|
|
||||||
|
|
||||||
![New project page](gitlab_importer/new_project_page.png)
|
|
||||||
|
|
||||||
Click on the "Import projects from GitLab.com" link and you will be redirected to GitLab.com
|
|
||||||
for permission to access your projects. After accepting, you'll be automatically redirected to the importer.
|
|
||||||
|
|
||||||
|
|
||||||
![Importer page](gitlab_importer/importer.png)
|
|
||||||
|
|
||||||
|
|
||||||
To import a project, you can simple click "Import". The importer will import your repository and issues.
|
|
||||||
Once the importer is done, a new GitLab project will be created with your imported data.
|
|
||||||
|
|
|
@ -1,183 +1 @@
|
||||||
# Migrating from SVN to GitLab
|
This document was moved to a [new location](../../user/project/import/svn.md).
|
||||||
|
|
||||||
Subversion (SVN) is a central version control system (VCS) while
|
|
||||||
Git is a distributed version control system. There are some major differences
|
|
||||||
between the two, for more information consult your favorite search engine.
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
There are two approaches to SVN to Git migration:
|
|
||||||
|
|
||||||
1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which:
|
|
||||||
- Makes the GitLab repository to mirror the SVN project.
|
|
||||||
- Git and SVN repositories are kept in sync; you can use either one.
|
|
||||||
- Smoothens the migration process and allows to manage migration risks.
|
|
||||||
|
|
||||||
1. [Cut over migration](#cut-over-migration-with-svn2git) which:
|
|
||||||
- Translates and imports the existing data and history from SVN to Git.
|
|
||||||
- Is a fire and forget approach, good for smaller teams.
|
|
||||||
|
|
||||||
## Smooth migration with a Git/SVN mirror using SubGit
|
|
||||||
|
|
||||||
[SubGit](https://subgit.com) is a tool for a smooth, stress-free SVN to Git
|
|
||||||
migration. It creates a writable Git mirror of a local or remote Subversion
|
|
||||||
repository and that way you can use both Subversion and Git as long as you like.
|
|
||||||
It requires access to your GitLab server as it talks with the Git repositories
|
|
||||||
directly in a filesystem level.
|
|
||||||
|
|
||||||
### SubGit prerequisites
|
|
||||||
|
|
||||||
1. Install Oracle JRE 1.8 or newer. On Debian-based Linux distributions you can
|
|
||||||
follow [this article](http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html).
|
|
||||||
1. Download SubGit from https://subgit.com/download/.
|
|
||||||
1. Unpack the downloaded SubGit zip archive to the `/opt` directory. The `subgit`
|
|
||||||
command will be available at `/opt/subgit-VERSION/bin/subgit`.
|
|
||||||
|
|
||||||
### SubGit configuration
|
|
||||||
|
|
||||||
The first step to mirror you SVN repository in GitLab is to create a new empty
|
|
||||||
project which will be used as a mirror. For Omnibus installations the path to
|
|
||||||
the repository will be located at
|
|
||||||
`/var/opt/gitlab/git-data/repositories/USER/REPO.git` by default. For
|
|
||||||
installations from source, the default repository directory will be
|
|
||||||
`/home/git/repositories/USER/REPO.git`. For convenience, assign this path to a
|
|
||||||
variable:
|
|
||||||
|
|
||||||
```
|
|
||||||
GIT_REPO_PATH=/var/opt/gitlab/git-data/repositories/USER/REPOS.git
|
|
||||||
```
|
|
||||||
|
|
||||||
SubGit will keep this repository in sync with a remote SVN project. For
|
|
||||||
convenience, assign your remote SVN project URL to a variable:
|
|
||||||
|
|
||||||
```
|
|
||||||
SVN_PROJECT_URL=http://svn.company.com/repos/project
|
|
||||||
```
|
|
||||||
|
|
||||||
Next you need to run SubGit to set up a Git/SVN mirror. Make sure the following
|
|
||||||
`subgit` command is ran on behalf of the same user that keeps ownership of
|
|
||||||
GitLab Git repositories (by default `git`):
|
|
||||||
|
|
||||||
```
|
|
||||||
subgit configure --layout auto $SVN_PROJECT_URL $GIT_REPO_PATH
|
|
||||||
```
|
|
||||||
|
|
||||||
Adjust authors and branches mappings, if necessary. Open with your favorite
|
|
||||||
text editor:
|
|
||||||
|
|
||||||
```
|
|
||||||
edit $GIT_REPO_PATH/subgit/authors.txt
|
|
||||||
edit $GIT_REPO_PATH/subgit/config
|
|
||||||
```
|
|
||||||
|
|
||||||
For more information regarding the SubGit configuration options, refer to
|
|
||||||
[SubGit's documentation](https://subgit.com/documentation.html) website.
|
|
||||||
|
|
||||||
### Initial translation
|
|
||||||
|
|
||||||
Now that SubGit has configured the Git/SVN repos, run `subgit` to perform the
|
|
||||||
initial translation of existing SVN revisions into the Git repository:
|
|
||||||
|
|
||||||
```
|
|
||||||
subgit install $GIT_REPO_PATH
|
|
||||||
```
|
|
||||||
|
|
||||||
After the initial translation is completed, the Git repository and the SVN
|
|
||||||
project will be kept in sync by `subgit` - new Git commits will be translated to
|
|
||||||
SVN revisions and new SVN revisions will be translated to Git commits. Mirror
|
|
||||||
works transparently and does not require any special commands.
|
|
||||||
|
|
||||||
If you would prefer to perform one-time cut over migration with `subgit`, use
|
|
||||||
the `import` command instead of `install`:
|
|
||||||
|
|
||||||
```
|
|
||||||
subgit import $GIT_REPO_PATH
|
|
||||||
```
|
|
||||||
|
|
||||||
### SubGit licensing
|
|
||||||
|
|
||||||
Running SubGit in a mirror mode requires a
|
|
||||||
[registration](https://subgit.com/pricing.html). Registration is free for open
|
|
||||||
source, academic and startup projects.
|
|
||||||
|
|
||||||
We're currently working on deeper GitLab/SubGit integration. You may track our
|
|
||||||
progress at [this issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/990).
|
|
||||||
|
|
||||||
### SubGit support
|
|
||||||
|
|
||||||
For any questions related to SVN to GitLab migration with SubGit, you can
|
|
||||||
contact the SubGit team directly at [support@subgit.com](mailto:support@subgit.com).
|
|
||||||
|
|
||||||
## Cut over migration with svn2git
|
|
||||||
|
|
||||||
If you are currently using an SVN repository, you can migrate the repository
|
|
||||||
to Git and GitLab. We recommend a hard cut over - run the migration command once
|
|
||||||
and then have all developers start using the new GitLab repository immediately.
|
|
||||||
Otherwise, it's hard to keep changing in sync in both directions. The conversion
|
|
||||||
process should be run on a local workstation.
|
|
||||||
|
|
||||||
Install `svn2git`. On all systems you can install as a Ruby gem if you already
|
|
||||||
have Ruby and Git installed.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo gem install svn2git
|
|
||||||
```
|
|
||||||
|
|
||||||
On Debian-based Linux distributions you can install the native packages:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
sudo apt-get install git-core git-svn ruby
|
|
||||||
```
|
|
||||||
|
|
||||||
Optionally, prepare an authors file so `svn2git` can map SVN authors to Git authors.
|
|
||||||
If you choose not to create the authors file then commits will not be attributed
|
|
||||||
to the correct GitLab user. Some users may not consider this a big issue while
|
|
||||||
others will want to ensure they complete this step. If you choose to map authors
|
|
||||||
you will be required to map every author that is present on changes in the SVN
|
|
||||||
repository. If you don't, the conversion will fail and you will have to update
|
|
||||||
the author file accordingly. The following command will search through the
|
|
||||||
repository and output a list of authors.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
svn log --quiet | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | sort | uniq
|
|
||||||
```
|
|
||||||
|
|
||||||
Use the output from the last command to construct the authors file.
|
|
||||||
Create a file called `authors.txt` and add one mapping per line.
|
|
||||||
|
|
||||||
```
|
|
||||||
janedoe = Jane Doe <janedoe@example.com>
|
|
||||||
johndoe = John Doe <johndoe@example.com>
|
|
||||||
```
|
|
||||||
|
|
||||||
If your SVN repository is in the standard format (trunk, branches, tags,
|
|
||||||
not nested) the conversion is simple. For a non-standard repository see
|
|
||||||
[svn2git documentation](https://github.com/nirvdrum/svn2git). The following
|
|
||||||
command will checkout the repository and do the conversion in the current
|
|
||||||
working directory. Be sure to create a new directory for each repository before
|
|
||||||
running the `svn2git` command. The conversion process will take some time.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt
|
|
||||||
```
|
|
||||||
|
|
||||||
If your SVN repository requires a username and password add the
|
|
||||||
`--username <username>` and `--password <password` flags to the above command.
|
|
||||||
`svn2git` also supports excluding certain file paths, branches, tags, etc. See
|
|
||||||
[svn2git documentation](https://github.com/nirvdrum/svn2git) or run
|
|
||||||
`svn2git --help` for full documentation on all of the available options.
|
|
||||||
|
|
||||||
Create a new GitLab project, where you will eventually push your converted code.
|
|
||||||
Copy the SSH or HTTP(S) repository URL from the project page. Add the GitLab
|
|
||||||
repository as a Git remote and push all the changes. This will push all commits,
|
|
||||||
branches and tags.
|
|
||||||
|
|
||||||
```bash
|
|
||||||
git remote add origin git@gitlab.com:<group>/<project>.git
|
|
||||||
git push --all origin
|
|
||||||
git push --tags origin
|
|
||||||
```
|
|
||||||
|
|
||||||
## Contribute to this guide
|
|
||||||
We welcome all contributions that would expand this guide with instructions on
|
|
||||||
how to migrate from SVN and other version control systems.
|
|
||||||
|
|