INRIA Forge project administrators and/or users need to coordinate to decide when and how to perform these migrations. It's also important to decide what exactly needs to be migrated, since you may not need to keep everything.
Coordination is paramount because if, as a project admin, you migrate for example the source control repository without telling the users, some of them might still use the old repository on the forge for checkouts or commits.
Communication with forge project members
As there is no simple way for a forge project administrator to get the list of emails of project members (to communicate with everyone and be sure to forget nobody), we can provide these lists on demand to forge project administrators. Open a ticket for this.
Preventing project members from commiting / pushing
Add a pre-commit hook which always returns false. For example:
For specific technical details on gitlab, git, git svn... there are numerous resources easily available on the web. In many situations, moving from subversion to git is pretty easy as long as you stick with basic operations:
svn checkout -> git clone
svn update -> git pull
svn commit -> git add + git commit + git push
There are cheat sheets with basic equivalence, such as this one.
Projects members need to have an account on the gitlab. If they don't have an account, they need to create one. It will then be possible for them to request access to the project (but only for public projects) or the opposite, an administrator can manually add them.
Project name and user names do need necessarily need to be the same between gforge and gitlab (though it may be simpler, if they are the same).
Also don't forget that to be able to actually do something (like cloning, pushing...) users need to setup their account correctly. If they want to use ssh to avoid entering their username/password on each action, they should have a working ssh setup and upload their ssh public key to the gitlab (the same as with the gforge)
Migration of source control repositories
INRIA gitlab is restricted to git (no subversion anymore), so for subversion users unfamiliar with git, you should take the time to read and understand the basic differences between subversion and git. If you want to stay with subversion, there is no alternative at INRIA, but you can go to SourceSup https://sourcesup.renater.fr/, which is actively maintained by Renater.
You need to decide if you want to migrate just the tip of your development history (last version on the repository) or if you want to migrate the whole commits / branching / tags history. Note that in several situations, there is no real need to migrate the whole history. For example if you keep a project only for historical reference, you may not need all the commit history.
In the following examples, we assume that the gitlab project is already created, correctly setup, and empty. The user performing the migration has a gforge account <forge_user>, a gforge project with unixname <forge_project>, a gitlab account <gitlab_user> and a gitlab project in the <gitlab_user> namespace, with name <gitlab_project>.
Migrating only the last version of the repository
Get the last version of the development tree (git or subversion), and import this in a new gitlab repository. All history is lost.
Migrating the whole (or part of the) history
Command-line git-svn method
Checkout the subversion repository with git-svn (https://git-scm.com/docs/git-svn). It creates a git repository from the subversion repository (with all the history). You can then add your gitlab project as a git remote and push to that project:
This directory can then be used to work from now on, or if you want to be sure that everything is correct, you can try a new checkout from scratch from the gitlab in another directory:
cd ..mv <forge_project> <forge_project>.migration# (may be removed later when you're sure the migration was correctgit clone email@example.com:<gitlab_user>/<gitlab_project>.gitcd <gitlab_project># check that all is correct
This directory cannot be used as a local working copy since the --mirror option implies --bare. You need to checkout a new working copy:
cd ..mv <forge_project>.git <forge_project>.git.migration# (may be removed later when you're sure the migration was correctgit clone firstname.lastname@example.org:<gitlab_user>/<gitlab_project>.gitcd <gitlab_project># check that all is correct
Gitlab import method
An alternative method is to directly choose the "Import project" tab when creating the project in gitlab, and then choose "Git repo by URL". Enter the URL of the project's git repository on the forge, such as: https://scm.gforge.inria.fr/anonscm/git/<forge_project>/<forge_project>.git (anonymous access) or https://<forge_user>@scm.gforge.inria.fr/authscm/<forge_user>/git/<forge_project>/<forge_project>.git (https developer access). Anonymous access is only available for public repositories. For https developer access you'll need to provide forge username and passsword for gitlab to be able to retrieve and import the project from the forge. It is not possible to use a git+ssh URL scheme for this method.
Mapping subversion / git committers to gitlab users
Git itself has no knowledge of forge / gitlab users. From git point of view, the author of a commit is a string
Gitlab maps commit authors to gitlab users accounts with the git .mailmap file. It allows solving situations where a forge svn or git repository is migrated to gitlab and some users don't have the same username between the forge and the gitlab. It also allows solving situations where some users have committed with varying names/addresses during the life of the project.
Subversion / Git Hooks
Classic subversion or git hooks, implemented as executable in the hooks directories of the subversion or git server repositories, are not possible on the gitlab. So the usual email on subversion commit / git push has no direct equivalent. Gitlab has the concept of notifications, where this is the user who decides what he/she wants to be notified for. But git push are not part of the notified events. So the best equivalent of the email on commit/push is to activate "Emails on push" in the gitlab project integrations.
The activity page of gitlab projects lists events such as pushes, merge request comments, issues.
No direct equivalent in gitlab, but one should be able to compute many kind of custom statistics by using git itself (for the git repositories) or the gitlab API (for gitlab specific stuff).
A wiki may be associated with each project in gitlab. The markup language is slightly different from mediawiki, though. When planning the migration of a wiki, you also need to handle attached files (images, etc.).
Forge Project Hierarchy
Gitlab groups are the alternative to Forge projects hierarchy, and they are actually more powerful and easy to use.
Forge Web Hosting
Web hosting in gitlab is done with gitlab pages. Gitlab pages can only serve static content, so this means no PHP (unlike the forge) or database. For example it is not possible to host a dokuwiki (which is php based). The generation of the pages is done with the same mechanisms as gitlab continuous integration. Any static site generator can be used (and there are templates for many). Gitlab pages are served over HTTPS but it has been decided that custom domains / certificates won't be activated.
A gitlab runner is needed to build gitlab pages. A gitlab runner is a server/VM/docker container running an agent and which can act as an executor for gitlab continuous integration jobs (and gitlab pages are a special case of gitlab continuous integration). As it is annoying for every project to setup a runner just for being able to publish a website, there is a work in progress to add shared runners to the inria gitlab. In the meantime, all projects requiring a runner for quick tasks like gitlab pages generation can ask to join the qlf-ci-gitlab-runner which provides such pseudo-shared docker runners.
We are currently evaluating the possibility to offer the possibility to redirect the web hosting of forge projects to new URLs.
Forge Shell Access
Not available in gitlab
Alternatives to INRIA gitlab
If you absolutely need a close equivalent to INRIA forge, RENATER SourceSup might be an alternative. It is based on FusionForge (like INRIA forge), offers git and subversion hosting, and is currently actively maintained. https://sourcesup.renater.fr/