-= LiflForge =-

Installation d'un projet sur LiflForge

L'installation d'un projet ne peut se faire actuellement que par demande auprès des administrateurs système du LIFL.

Lors de votre demande, veuillez spécifier (cf. explications ci-dessous) :

  • le nom que vous voulez donner à votre projet
  • le propriétaire du projet
  • la configuration désirée
  • le type et le nom du dépôt de fichiers

Il est possible de modifier après-coup la configuration d'un projet sur le serveur, mais l'impact côté clients n'est pas toujours négligeable.
En cas de doute, renseignez-vous auprès des administrateurs système.

Une fois votre projet installé, vous aurez à modifier le paramétrage initial.

Nom de projet

Le nom du projet est utilisé pour définir l'URL d'accès au projet. Il doit donc être composé d'un seul mot.
Exemple : MonProjet sera accessible depuis l'adresse principale http://forge.lifl.fr/MonProjet

Propriétaire

Le propriétaire d'un projet doit être enregistré comme membre du LIFL et doit donc disposer d'un compte Unix, ainsi que d'une adresse mail.
Il est l'administrateur, par défaut, du projet.

Configuration

La configuration d'un projet est définie par 3 paramètres indépendants (par défaut : privé / HTTP / sans autorisations fines) :

anonyme / privé

  • privé
    Par défaut, un projet est configuré comme étant privé : l'accès au contenu du Trac et des dépôts de fichiers (SVN/Git) nécessite une authentification.
    L'administrateur du projet peut ajouter/supprimer des utilisateurs, et leur affecter des droits d'accès particuliers.
  • anonyme
    En plus de l'accès privé, un projet peut être configuré pour autoriser un accès sans authentification, en lecteur seule, au contenu du Trac et des dépôts de fichiers (SVN/Git).
    L'administrateur du projet peut ensuite restreindre/étendre les droits d'accès anonymes.

http / https

Par défaut, un projet est configuré pour être accessible au travers du protocole HTTP, non sécurisé, sauf lors de l'accès à la page de connexion qui est forcée en HTTPS. Dans ce mode, le contenu du Trac et des fichiers sources est transmis en clair sur le réseau

Il est possible de configurer un projet pour utiliser le protocole HTTPS, assurant un chiffrement de tous les transferts entre le serveur et le logiciel client. L'utilisation d'HTTPS surchargeant le serveur, il n'est à utiliser que lorsqu'une grande confidentialité est nécessaire.

avec ou sans autorisations fines

L'administrateur du projet a la possibilité de gérer les droits d'accès aux différents modules Trac (wiki, tickets, forum, blog…). Les droits sont cependant accordés sur l'ensemble du contenu géré par le module (toutes les pages wiki, par exemple).

En ce qui concerne les droits d'accès aux dépôts de fichiers (SVN/Git), par défaut 2 types de droits sont définis : en lecture seule pour les accès anonymes (si autorisés), en lecture/écriture pour les accès authentifiés, et ce sur l'ensemble des fichiers du dépôt.

Il est possible de configurer un projet pour permettre la gestion fine des droits d'accès aux contenus Trac et aux dépots SVN (autorisations différentes suivant les projets ou les utilisateurs, autorisation en écriture uniquement à certains répertoires ou fichiers…). La gestion fine n'est, pour l'instant, pas possible pour les dépôts Git.

La gestion fine des droits sur les dépôts SVN étant couteuse et ralentissant les accès aux fichiers du dépôt, il est préférable de ne la mettre en oeuvre que si réellement nécessaire.

Nom et type du dépôt de fichiers

Par défaut, un dépôt SVN est associé au Trac. Il est référencé sous le nom main, et est accessible depuis l'URL http://forge.lifl.fr/MonProjet/svn/main.

Si cette configuration par défaut ne convient pas, il est possible :

  • de ne pas associer de dépôt de fichiers au projet Trac (dans le cas où Trac est utilisé comme espace de partage de documents - ce qui n'est a priori pas sa vocation…),
  • de nommer différemment le dépôt SVN,
  • de remplacer le dépôt SVN par un dépôt Git. Le nom du dépôt Git aura l'extension .git classique des dépôts centraux.

D'autres dépôts de fichiers pourront être ajoutés ultérieurement au projet Trac. Il faut, pour l'instant, en faire la demande auprès des administrateurs système.

Git ou SVN ?

Disons le tout de suite, c'est avant tout une histoire de goût (ou presque…). Si l'investissement nécessaire avant de commencer à saisir les subtilités de Git est plutôt important, une fois que l'on a gouté aux fonctionnalités d'un logiciel de gestion décentralisée de versions (DVCS) tel que Git (dépôt local permettant de travail en mode déconnecté, branches locales, fusion aisée entre branches, ré-écriture de l'historique des modifications, picorage de modifications, etc), il est difficile de s'en passer.

Il faut cependant distinguer les fonctionnalités locales et la nature du dépôt central (dans le cas de Git, on ne peut pas réellement parler de dépôt central, mais plutôt de dépôt distant officiel. On se permettra cependant, ici, ce raccourci pour simplifier le discours…). En effet, il est tout à fait possible d'utiliser Git localement en liaison avec un dépôt distant SVN, à l'aide de git-svn.

La question porte donc sur le choix du dépôt central/distant.

  • Dans son principe, Git met à disposition en local, sur votre machine, des copies synchronisées (à la demande) de branches distantes.
    Chaque branche distante peut être située physiquement sur n'importe quelle machine accessible par le réseau (éventuellement celle d'un des collaborateurs au projet). Le dépôt central n'est qu'une machine hébergeant une (ou des) branche(s) distante(s) officielles(s).
    Git permet donc, de par sa nature, de travailler à plusieurs sur une branche de développement non disponible sur le dépôt central, charge au chef de projet de fusionner cette branche sur le dépôt central au moment opportun.
    C'est dans ce mode de fonctionnement très distribué que Git (ou tout autre DVCS) présente tout son intérêt, comparé à SVN. Rien n'empêche cependant de n'utiliser Git que dans un mode centralisé (i.e. toutes les branches sont stockées sur le dépôt central, il n'y a pas de dépôts intermédiaires).
  • SVN ne fonctionne qu'en mode centralisé, il n'y a pas de copie locale des branches hébergées sur le dépôt central (SVN nécessite d'être connecté au dépôt central pour pouvoir commiter des changements).
    SVN est basé sur WebDAV, il permet d'accéder par URL à un répertoire de fichiers hébergés sur un serveur WebDAV.
    De par cette utilisation de références sous forme d'URLs, SVN intègre très naturellement la capacité à héberger plusieurs sous-projets, chaque sous-projet étant un sous-répertoire du dépôt (cf. plus bas).
    Il n'y a pas à proprement parler de notions de branches : une branche SVN peut être considérée comme l'équivalent d'une copie de répertoire (avec conservation de l'historique des modifications).
    La fusion de branches est de ce fait plus hasardeuse qu'avec Git qui fonctionne à un niveau plus atomique, et les conflits causés par la divergence de contenus des branches sont très fréquents.

En résumé :

  • on privilégiera un dépôt SVN lorsque l'on désire gérer plusieurs sous-projets dans la même hiérarchie, que le mode de fonctionnement centralisé est suffisant et que l'utilisation de branches est occasionnel.
  • on privilégiera un dépôt Git lorsque l'on désire un mode de fonctionnement décentralisé, que l'utilisation de branches de développement est régulière (voire est le mode de collaboration par défaut - branches WorkInProgress) et qu'il n'y a pas nécessité de gérer des sous-projets indépendants au sein du même dépôt.

Notes concernant git-svn

  • Pour des raisons de différence de gestion de l'historique, si votre branche locale master est liée à un dépôt distant SVN, il faudra éviter d'effectuer des fusions directes vers cette branche. On utilisera la commande git merge --squash ... suivie d'un classique git add ....
  • git-svn ne permet pas de gérer les propriétés SVN. Cela implique qu'il n'est pas possible avec git-svn de spécifier le type MIME d'un fichier ou de modifier l'auteur ou le message de log d'une ancienne révision, par exemple.
Last modified 5 years ago Last modified on 01/29/13 12:18:59