... | ... | @@ -8,11 +8,17 @@ INRIA Forge project administrators and/or users need to coordinate to decide *wh |
|
|
|
|
|
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.
|
|
|
|
|
|
## Available documentation
|
|
|
|
|
|
The gitlab documentation is available here: https://gitlab.inria.fr/help
|
|
|
|
|
|
Beware that gitlab is both a software (gitlab) and a free hosting platform (https://gitlab.com). In many places in the documentation, the links given point to https://gitlab.com, you have to replace these by links to our instance: https://gitlab.inria.fr
|
|
|
|
|
|
## 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.
|
|
|
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.
|
|
|
|
|
|
### Migrating only the last version of the repository
|
|
|
|
... | ... | @@ -76,7 +82,7 @@ Gitlab groups are the alternative to Forge projects hierarchy, and they are actu |
|
|
|
|
|
## 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.
|
|
|
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.
|
|
|
|
|
|
## Forge Shell Access
|
|
|
|
... | ... | |