Un entrepôt CVS est ouvert chez
Gna :
cvs.gna.org:/cvs/wikini
Nous avons également fait un alias
cvs.wikini.net qui pointe sur
cvs.gna.org.
- (PiiF) apparemment, l'alias ne marche plus, j'ai un Host cvs.wikini.net not found
Vous pouvez donc en principe utiliser cet alias en lieu et place de
cvs.gna.org.
- Accès en consultation par interface Web : GnaCVS
- Accès en écriture : créez un compte sur Gna, ajoutez votre clef publique dans les préférences de votre compte Gna et contactez DavidDelon ou CharlesNepote pour être ajouté au projet.
L'entrepôt est divisé en deux branches :
- La branche courante HEAD (ou MAIN) : branche par défaut dans laquelle se font les développements de la future version de Wikini.
- La branche 0.4 (identifiant REL_0_4_1) : branche de la dernière version stable de Wikini. De cette branche sont issues la version 0.4 de Wikini et ses versions mineures (0.4.1, 0.4.2 ...) qui ne font que corriger des bogues ou améliorer les performances, sans aucun changements fonctionnels. L'identifiant BRANCH_0_4 pour cette branche eût été préférable, mais afin de préserver la cohérence de l'historique des modifications des sources de l'entrepôt, l'identifiant REL_0_4_1 a été conservé.
A la sortie de la version 0.5, une nouvelle branche sera créée pour accueillir les corrections de bogues de la 0.5 et donc les versions mineures 0.5.1, 0.5.2, etc. (A ce titre, le mode de développement de
WikiNi rapelle
celui de Mozilla).
Accès au CVS en anonyme via Linux
Branche courante
Créez tout d'abord le répertoire de destination sur votre machine :
- Ouvrez un terminal (sous la console ou Xwindow, au choix)
- Créez un dossier : par exemple : mkdir Wikini
- Positionnez-vous dans ce dossier : cd Wikini
- Récupérez les sources : cvs -d:pserver:anonymous@cvs.gna.org:/cvs/wikini co wikini
Le tour est joué. Vous devez trouver un dossier wikini sous votre dossier Wikini.
Pour récupérer la dernière version des sources, il vous suffira de retourner dans ce dossier, puis de tapper la commande
cvs update -PdC. Attention cependant, cela récupèrera les mises à jour officielles de
WikiNi et effacera vos modifications à vous ! Vous pouvez également mettre ces options
-PdC dans votre
~/.cvsrc. Voir la page de manuel
man cvs pour plus d'information.
Branche 0.4
La démarche est la même que ci-dessus, il faut juste préciser que l'on veut récupérer la branche 0.4 lors de la récupération des sources par la commande :
cvs -d:pserver:anonymous@cvs.gna.org:/cvs/wikini co -r REL_0_4_1 wikini
--
EuLer,
CharlesNepote &
ProgFou DavidDelon
Récupérer les sources sans les métadonnées CVS
Vous pouvez souhaiter récupérer les sources mais sans toutes les métadonnées créées par CVS.
Pour récupérer la dernière version du CVS :
- cvs -d:pserver:anonymous@cvs.gna.org:/var/cvs/wikini export -r HEAD wikini
Pour récupérer la version 0.4.1 de
WikiNi :
- cvs -d:pserver:anonymous@cvs.gna.org:/var/cvs/wikini export -r V041 wikini
Pour récupérer la branche 0.4 de
WikiNi :
- cvs -d:pserver:anonymous@cvs.gna.org:/var/cvs/wikini export -r REL_0_4_1 wikini
Note : récupérer sur le tag V041 donnera la version 0.4.1 à sa date de sortie et non pas la dernière 0.4.x avec toutes les mises à jour faites, pour récupérer la branche 0.4 il faut utiliser le tag REL_0_4_1
Accès au CVS en tant qu'utilisateur via Linux
(en mode texte)
Récupération de WikiNi (checkout)
- Générer les clés SSH nécessaires à la connexion sur gna.org : ~/ssh-keygen -t rsa (cf. FAQ Gna)
- Publier la clé publique générée sur gna.org (/home/user/.ssh/id_rsa.pub si vous avez choisi les options par défaut de ssh-keygen) : https://gna.org/account/editsshkeys.php
- Créez un dossier : par exemple : mkdir Wikini
- Positionnez-vous dans ce dossier : cd Wikini
- export CVS_RSH=ssh
- export CVSROOT=nepote@cvs.gna.org:/cvs/wikini
- Le CVSROOT=nepote@cvs.gna.org n'est pas à remplacer par le nom d'utilisateur du compte ouvert sur Gna! ? Si oui, peut-être est-ce bon de le préciser. -- MickaelMenu
Branche courante
Branche 0.4
- cvs co -r REL_0_4_1 wikini
Si vous désirez travailler sur les deux branches de wikini en même temps, la démarche est la même, mais il vaut mieux séparer les dossiers de travail :
- Créez un dossier : par exemple : mkdir Wikini
- Positionnez-vous dans ce dossier : cd Wikini
- export CVS_RSH=ssh
- export CVSROOT=nepote@cvs.gna.org:/cvs/wikini
Branche courante
- cvs co -d "wikini" "wikini"
Branche 0.4
- cvs co -d "wikini.0.4" "wikini"
Publication d'un fichier modifié localement sur le référentiel (commit)
L'exemple reprend les noms de dossiers attribués ci-dessus.
Branche courante
- cd Wikini/wikini
- cvs update -P
- cvs commit -m 'Correction cosmetique' wakka.basic.css
Branche 0.4
- cd Wikini/wikini.0.4
- cvs update -P
- cvs commit -m 'Backport bug cookie' wakka.php
Les mises à jours se font automatiquement sur la branche 0.4, grace aux parametres enregistré dans le répertoire CVS du dossier.
Accès au CVS avec WinCVS sur Windows 2000
Attention, il ne semble pas possible de générer des clés RSA avec SSH1 sous Windows (en particulier avec ssh-1.2.14). Il faut utiliser un client compatible SSH2 :
[en cours de rédaction]
- Generation clef publique (To generate a public key, run the program 'ssh-keygen'. The public key will be placed at '~/.ssh/id_rsa.pub'. Read the ssh documentation for further information on sharing keys.)
- ssh-agent (existe sous windows ? reponse : voir PuTTy )
- Télécharger et installer WinCVS
- Configurer WinCVS
- Menu Admin / Preference /
- Authentication : SSH
- Authentication / Settings : [à compléter]
- Path : /cvsroot/wikini
- Host Adress : cvs.gna.org
- User name : monlogin
- CVSROOT : monlogin@cvs.gna.org:/cvs/wikini
- X : show CVS Console
- Faire ensuite menu Create / Checkout Module / Module name and path on the server : wikini : l'arborescence de wikini doit alors se recopier en local.
Références
Accès au CVS avec TortoiseCVS?
TortoiseCVS? fonctionne sur le même principe que
WinCVS, mais il est complètement intégré à l'explorateur de fichier de windows. La plupart des commandes se trouvent donc dans le "click-droit" sur les fichiers/répertoires. Un des avantages est la possibilité de faire un import depuis le serveur dans la boîte de dialogue "Ouvrir" commune à la plupart des éditeurs de texte. Pour trouver
TortoiseCVS? :
http://www.tortoisecvs.org/
- Télécharger et installer TortoiseCVS 1.6.7 ou plus
- Lancer le programme puttygen.exe (répertoire TortoiseCVS) et générer une paire de clé privée/publique SSH2 RSA(option en bas de la fenêtre de puttygen). Enregistrer les 2 clés dans des fichiers, sélectionner le code de la clé publique (champ "Public key for pasting....") affiché dans puttygen et copier le dans le presse papier windows. La clé plublique affichée par puttygen est de la forme : ssh-rsa AAAAB3NzaC1yc...plein de caractères...73rKY/U1otcKvgWZdU= rsa-key-20040928 et c'est l'ensemble qu'il faut mettre dans le champ des clés sur gna.org.
- Aller sur le site http://gna.org et coller la clé publique contenue dans le presse papier dans un des champs de clé.
- Télécharger le programme pageant.exe sur le site de PuttY
- Lancer pageant.exe, l'icône pageant apparait à coté de l'heure dans la barre des taches Windows, et charger la clé privée via le menu ou le bouton Add Key. Il est possible de charger automatiquement une clé dans pageant en lui indiquant le fichier de clé privée en paramètre. Par exemple : "C:\Program Files\TortoiseCVS\pageant.exe" "C:\Documents and Settings\GarfieldFr\Mes documents\ssh\garfieldfr@gna_ssh2rsa.priv" ou garfieldfr@gna_ssh2rsa.priv est le fichier contenant la clé privée générée avec puttygen.exe.
- Configurer TortoiseCVS? :
- click-droit puis CVS/Préférences. Onglet Outils :
- indiquer dans "Application SSH" le fichier "C:\Program Files\TortoiseCVS\TortoisePlink.exe" (sans guillemets)
- indiquer dans "Paramètres SSH" : "-A" (en option "-v" pour avoir un mode bavard de PLink) (paramètres toujours sans guillemets)
- click-droit dans le répertoire qui contiendra l'import des fichiers puis "CVS emprunter" (version en français)
- dans CVSROOT : :ext:username@cvs.gna.org :/cvs/wikini avec username votre nom d'utilisateur sur gna
- dans module : wikini
- cliquez sur OK
Discussions
Ok. Ça c'est la recette qui va bien (fonctionne correctement chez moi). Mais je voudrais comprendre la recette. Comment "pageant" entre-t'il en action ? Y a-t'il un moyen de lancer "pageant" automatiquement avec la bonne clé chargée ?
--
CharlesNepote
Le programme
pageant garde une ou plusieurs clés en mémoire pour éviter d'avoir à ressaisir sans cesse son mot de passe de clé privée. Chaque programme voulait faire une connexion sécurisée via le protocole SSH va demander à l'agent d'authentifier cette connexion pour lui. L'agent n'envoie jamais les clés privés, il fait les authentifications lui-même et renvoie uniquement le résultat.
Il ne faudrait surtout pas que l'agent puisse charger automatiquement les clés, sinon cela voudrait dire que n'importe qui ayant un accès physique à la machine pourrait utiliser les clés sans en connaître les mots de passe ! C'est déjà bien qu'on ait à les saisir qu'une seule fois...
--
ProgFou
Pour répondre à
CharlesNepote, il est possible de charger automatiquement les clés privées au lancement de
pageant comme ceci :
- La clé privée est dans le fichier C:\ssh\gna_ssh2rsa.priv (par exemple)
- Lancer pageant comme ceci : pageant.exe "C:\ssh\gna_ssh2rsa.priv". Les " sont présents pour le cas ou le chemin d'accès au répertoire de la clé privée comporterait des espaces. Il est possible de charger plusieurs clés : pageant.exe "C:\path\gna_ssh2rsa.priv" "C:\path\bidule_ssh1.priv".
Comme l'indique
ProgFou, cela n'est pas très conseillé si la machine est accessible physiquement et si les clés privées ne sont pas protégées par un mot de passe.
--
GarfieldFr
J'ai beau essayer tout ce que je peux, ça ne marche absolument pas pour moi :-S (je pense que ça ne peut pas être parce que je n'ai pas redémarré mon pc, si ? tortoise demande le redémarrage juste pour s'intégrer dans explorer non ? donc j'ai juste relancé ce dernier...)
Bon alors j'ai suivi les instructions à la lettre, j'ai donné ma clef publique à gna hier soir (il ne faut rien changer tout de même, on peut la donner telle quelle non ? "
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIB0GCmvbj1gRWg59FMG//AdcvaiLMs8/Z9GYwdpfjkriGPsWzS0E7tACfeiFD6/8XsYiYgXojDy2STUDhymxvac9tIy0gPh0PlejHoUuucew2XJLhoisyu8IuYsEfvHk99/0dcn/BlIErs6LpeDVIkXrInzyAZml9F8zvyltVqo7Q== rsa-key-20041208")
... et rien à faire, Tortoise ne comprend rien (plein de warnings...), et en fait je n'arrive même pas à me connecter directement avec plink
- consultez l'historique de la page pour logs... en gros c'est "key refused"
Si je comprends bien le serveur refuse ma clef... pourquoi ? J'ai eu beau faire des recherches sur le net, je ne trouve rien... par exemple sur gna.org il y a deux articles qui semblent concerner exactement le même porblème que moi: le premier semble décrire exactement la démarche qui est donnée ici, le deuxième reste sans solution (mais supposée trouvée...)... sinon j'ai trouvé un super jeu de mot d'un gars qui avait apparemment le même genre de problème: "tortoise is tortoising !"... et puis d'autres trucs plus vagues qui concernent les problèmes de connexion à ssh en général... --
LordFarquaad
Re-essayer aujourd'hui ? La prise en compte de la clef publique par gna n'est pas immédiate. --
DavidDelon
- Ben non, ça fait plus de 48h que j'ai donné ma clef et ça ne marche toujours pas... j'ai essayé sous linux mais je suis pas trop doué, enfin j'ai su récupérer les fichiers en anonyme, c'est déjà ça... J'ai suivi la procédure décrite plus haut pour se connecter en tant qu'utilisateur, donc j'ai mis une deuxième clef sur gna, je réessaierai peut-être tantôt, quand le serveur aura (normalement) pris en compte ma clef... Ca ne peut pas être un problème de majuscules dans le pseudo au fait ? -- LordFarquaad (2004-12-11 04:00)
- Je viens de retester sous linux et ma clef n'est toujours pas acceptée... pourtant c'est une heure normalement na ? Enfin ça fait plus de 10h là. Par contre la version que j'ai téléchargée en anonyme depuis linux est reconnue par Tortoise qui arrive à l'actualiser ! J'en reviens pas là :-P Enfin ce serait bien tout de même que j'arrive à y accéder en tant qu'utilisateur, surtout pour pouvoir m'impliquer "officiellement" dans le projet ;-) (j'ai pas encore demandé l'accès en écriture là, tant que je n'arrive pas à me connecter en tant qu'utilisateur ça ne sert à rien de toute façon...) -- LordFarquaad (2004-12-11 14:30)
- Ben j'ai beau essayer sous linux je n'y arrive pas non plus :-S Il y a un truc que je fais mal ou quoi ? Pour commencer j'ai généré mes clefs comme expliqué plus haut, puis j'ai ajouté le contenu de ~/.ssh/id_rsa.pub comme deuxième clef ssh sur gna, c'est un truc du genre "ssh-rsa [[:alnum:]/+]+= lordfarquaad@localhost" (c'est normal qu'il n'y ait qu'un seul "=" ? il faut bien recopier tout au fait ?)[Faudrait que tu rendes public ton profil sous gna, pour qu'on puisse jeter un coup d'oeil sut cette clef publique -- DavidDelon] Ensuite j'ai tenté de me connecter (cvs d'abord, puis comme ça ne marchait pas, ssh directement):
- logs effacez, voyez l'historique si vous voulez...
- Apparemment ma clef est toujours rejettée, pourtant celle-là je l'ai donnée hier tôt le matin... (peu avant l'avant dernier message que j'avais laissé ici) -- LordFarquaad (2004-12-12 15:58)
- En fait maintenant ça marche (avec Tortoise) :-P J'ai enlevé mes logs d'ici pour faire plus propre. Pour moi on peut virer même tout ce que j'ai dit en fait même, pour garder cette page dans un état correct... Et merci pour l'intégration au projet ;-) -- LordFarquaad
Impossible de me connecter. Je pense avoir suivi les instructions à la lettre. Résultat : "Unabale to open connection: Host does not exist" ! J'ai essayé divers paramètres, avec anomymous... Peut-être un problème de firewall, y-a-t'il des ports particulier à ouvrir ? --
JeanMorlet
La branche TEST
Cette branche TEST n'existe plus, une page de log des changements intervenus sur cette branche est disponible ici :
WikiNiCVSBrancheTest (--
GarfieldFr)
Les branches
Voici une explication sur les branches dans CVS provenant de
http://faq.tuxfamily.org (faq inactive au 27/04/2005, le site est lui disponible):
Une branche est en fait une version dérivée, une version parallèle. La bonne méthode de travail étant de travailler sur une version TEST et de la rendre publique par la suite. Vous pouvez créer des branches de branche, etc... et autant de branches que vous voudrez. Ces branches, dans ma méthode de travail, auront un "sticky tag". Ce "tag" permet de faire porter un nom à votre branche en plus du nouveau numero de version. C'est bien plus pratique pour la récupération d'une branche.
Etant donné que l'étiquette est collante, elle restera collée tout le temps; chaque commit , update etc... se fera sur cette version. La version principale du CVS étant chez Tuxfamily le tag HEAD, cette version n'en sera pas touchée.
Comment créer une branche de la version HEAD en version TEST ?
Ici "module" est le nom du module (dans la section 1 on l'avait appelé TRUC). Si vous n'avez pas encore récupéré le module faite un
$ cvs co module
sinon :
$ cvs update module
ensuite création de la branche:
$ cvs rtag -b -r HEAD TEST module
Cela crée la branche TEST à partir de la version HEAD.
"rtag" crée un tag collant, -b une brache, -r pour nommer le tag ...
Ensuite il faut récupérer la bonne version:
$ cvs co -r TEST module
ou simplement un fichier:
$ cvs co -r TEST module/foo.c
Là nous avons la version TEST, vérifions:
$ cvs status module
qui fait apparaître le sticky tag (tag collant) TEST dans le rapport qui s'affiche à l'ecran. Maintenant toute les modifications n'auront un impact QUE sur la version test.
Nous voulons, maintenant que notre version TEST a reçu des modifications, mettre à jour notre version principale (nommée par défaut HEAD) à partir de notre version TEST. Il nous faut d'abord revenir à la version HEAD avec un checkout (co) avec l'option -A pour supprimer les tags :
$ cvs co -A module (prend la version sans sticky tag)
$ cvs update module (pour remettre a jour les fichier locaux (facultatif))
ensuite on fait un merge de la version TEST vers la version HEAD (celle que nous avons en local) :
$ cvs update -j TEST module
puis confirmons tout ça :
$ cvs ci module
faites tout de même un update au cas où puis faites un status. Notre version locale HEAD a donc reçu les modifications de la version TEST.
Imageons ce qu'il vient de se passer dans cette section :
Vous avez un paquet de documents, un gros dossier. C'est le dossier de travail. Vous voulez faire en sorte que ce dossier puisse evoluer en test et le rendre publique seulement si il est bon. Vous prenez donc un gros sac dans lequel vous mettez vos documents et vous collez sur ce qac une etiquette autocollante avec ecrit dessus "TEST". Ce sac est alors distribué à qui le veut. Vous modifiez des choses, vous y inserez des feuilles. Cette version vous plait, vous copier alors tout ce dossier et le mettez dans le sac principal (publique) qui n'a pas l'etiquette "TEST". Mais vous avez encore une version de l'ancien sac principal ainsi que le sac TEST au cas où.
(c'est Ok pour moi, je mets mes "truc" dans la branche TEST, à savoir l'action include avec support des pages distantes --
GarfieldFr )
Utilisation des branches et des tags
La structure d'un CVS est constituée en forme d'arbre: une branche principale ou tronc qui représente le développement principal de l'application et des branches qui partent de la branche principale ou d'une autre branche qui représentent des versions différentes de l'application (par exemple, une version spéciale "société truc" de l'application qui a été réalisée à la demande de la société truc).
Un fichier a un numéro de
révision par exemple 1.1, 1.2, 1.3 ...etc pour les fichiers du tronc ou dans une branche 1.2.1, 1.2.2....etc ce qui indique que la branche est partie de la révision 1.2 du fichier dans la branche principale.
Un tag permet de nommer une révision, en effet, les révisions de tous les fichiers ne vont pas bouger avec la même fréquence, ce qui implique qu'à une date D les fichiers n'auront pas les mêmes numéros de révision. Si on décide de dire que les fichiers de la date D représente une version stable ou utilisable (par exemple la version 1.0), il suffit de créer un tag ( par ex : VERSION_1.0) et de l'appliquer aux fichiers faisant partie de la version. Certains fichiers présents dans le CVS ne feront pas partie de la version car c'est une nouveauté en cours de développement ou une fonction obsolète. Chaque fichier peut avoir plusieurs tags différents (par exemple le fichier de licence est présent dans toutes les versions). L'interêt de poser un tag, c'est de pouvoir récupérer tous les fichiers d'une version donnée uniquement en indiquant le nom du tag alors que sans le tag, il faudrait récupérer tous les fichiers à une date donnée identifiée comme étant celle d'une version et ensuite faire le tri entre les fichiers utiles et inutiles.
Il existe un tag particulier, le tag HEAD qui permet de recupérer la dernière révision de tous les fichiers, c'est cette version qui est récupérée lorsque on fait un checkout sans indiquer de version. Ce tag bouge donc en même temp que le numéro de révision des fichiers. Je ne sais pas s'il est possible de poser d'autres tag mobile avec CVS (c'est possible avec d'autre outils comme PVCS par exemple).
En résumé, la branche est une évolution différente du projet, le tag est une étiquette posée sur une certaine révision de certains fichiers. Il y a beaucoup d'analogie avec l'évolution des espèces, par exemple, "homo-sapiens", "homo-erectus" et "neandertale" sont des "tags" de la branche de l'évolution des hommes alors que "homme", "chimpanzé" et "gorille" sont des branches qui sont parties d'un même tronc à des époques différentes (je ne garantis pas l'exactitude des termes, mais c'est juste pour fixer les idées). --
GarfieldFr