Bonsoir

Je n'arrive pas à tirer certaines choses au clair.
La sortie de mon framework est pour le 1 février, et il me reste à mettre en place la partie téléchargement. Pour ça, j'ai pensé à un SVN. Mais comment ça s'utilise ? J'ai testé 3 programmes avec un interface graphique, mais autant programmer en BrainFuck, ce serait pareil.
Si j'utilise SVN, je peux gérer plusieurs versions ; certes c'est son but. Mais comment on utilise tout ça ? Je peux tout traiter en local, et balancer seulement les dernières versions en ligne ? Je peux le faire en ligne de commandes, ça ne m'effraye pas, mais comment ? Etc.
Il existe également des trackers (Trac, Bugzilla, ViewVC), kézako, utile ? ViewVC accompagne SVN. Ce que j'ai compris, c'est qu'ils permettent d'explorer les sources du SVN.

Bref, je suis un peu perdu dans tout ça. Livre, framework, et examens ne sont pas un mélange ! Merci pour vos lanternes.

Pour infos, j'ai enfin terminé de bidouiller DocBook (1 mois déjà). Les sources seront en ligne. Le résultat est maintenant sémantiquement plus correct (admissible dirons-nous).

Regardes du cote de USVN (Projet de FE d'Epitech)

Je cherche surtout à savoir comment on doit utiliser tout le bazar et pas un outil pour y arriver. Je peux utiliser SVN en ligne de commande, ce sera parfait. D'ailleurs, des explications sur la ligne de commandes seraient préférables. Je suis plus porté sur le terminal que des interfaces graphiques.

Je cherche surtout à comprendre le fonctionnement d'SVN. Si quelqu'un l'a déjà utilisé, j'aimerais pouvoir parler avec lui (mp ou sur le forum, ce n'est pas un problème) .

tu veux dire comment installer ou comment utiliser?

si c'est l'utilisation c'est ssez simple tu codes en local ensuite tu checkout dans un répertoire pour "lier" ce répertoire au serveur svn, tu copie tes sources dans le répertoire, tu add tous tes fichiers via les commandes svn et tu commit tes sources.

le tout est relativement facile en ligne de commande comme tu le disais,

Alors voici une petite introduction à SVN.

http://dev.nozav.org/intro_svn.html

J'utilise svn avec tortoise (sous win pas besoin de s'en priver, c'est parfait).

A la base, svn est une structure en répertoires (assez libre)

Tu as un repository, ou tout est stocké, que tu peux diviser en dossier (par projets). Par projet, tu peux créer trois dossiers (trunk / branches / tags), ou seront enrégistrés respectivement le tronc du projet (principal), les branches (pour les petites modifications sans toucher le projet principal) et les tags (ou snapshots, ou quelque chôse comme ça), pour des "images" régulieres, si on veut. Mais à la base, c'est très démocratique.

Si tu pars d'un projet existant, il faut d'abord l'importer dans le repository (disons svn//127.0.0.1/calendrier/trunk ). Voilà qui est fait.

Pour avoir un "working copy", il faut faire un checkout, a partir d'un des dossiers du repos vers ton poste.

Pour valider les modifications apporter, c'est par un "commit" que tu enregistreras la nouvelle version dans ton repos (le n° de "version" est global, et vaut pour le repos en entier. Ainsi, deux projets différents dans un même repos ne peuvent avoir la même version).

Si d'autres ont travaillé dessus entretemps, il faut d'abord faire un "update", qui soit se passe sans conflits, soit avec, et il faudra alors les résoudre.

Pour finalement sortir une version de production, il suffit de faire un "export". (version "HEAD" qui est la plus récente, ou tout simplement un numéro particulier)

Tu peux faire des "merge", entre une branche et le trunk par exemple, copier le projet vers un autre serveur, récuperer une version antérieure, pleins de trucs. Mais jamais tu ne travailleras sur ce qui est stocké par svn.

C'est diablement pratique, depuis que je l'ais adopté au taf, j'ai transformé mon nas chez moi en serveur svn, pour a peu près tout. J'utilise un nas en raid1 pour tout ce qui est stockage un tant soit peu important, et avec svn, que du bonheur. Surtout avec tortoise, puisqu'il t'indique sur chaque ficher son état (à jour, nouveau, effacé, modifié, etc..)

[Note: posté avant de lire le message de Berzemus]
[Note2: j'avais commencé à écrire avant le post de h0_noMan, suis son lien, l'article a l'air complet, en tout cas plus complet que nos posts ]

comment ça s'utilise ?

Avant toute chose il faudrait cerner ce que tu veux en faire. Sous Windows, installe TortoiseSVN. C'est une interface graphique qui intègre le multi-versionning à Windows, et comme elle embarque Subversion, tu peux l'utiliser en ligne de commande. Sous Linux, utilise ton package manager préféré.

Subversion, comme tout SCM, c'est un serveur d'un côté et un client de l'autre. Si tu veux héberger ton propre serveur, il faut créer un "repository" (en gros, la DB qui représente toutes les versions des fichiers de ton projet) et configurer un daemon pour y accéder, mais je te recommanderais plutôt d'utiliser un hébergeur externe pour ne pas te prendre la tête avec son administration. Par exemple, te faire héberger chez Google Code.

Reste le client. Si tu le souhaites, il y a un gros manuel TL;DR sur la théorie du Version Control dans Subversion, mais si tu es le seul à travailler sur ce projet et que Google s'est occupé de créer ton dépôt (repository), la version courte est :

• tu crées un répertoire destiné à accueillir tes fichiers sous SVN grâce à la commande "svn checkout". Évidemment, ce répertoire est vide puisque tu n'as encore aucun fichier sous SVN
• tu copies tes fichiers dans ce répertoire
• tu marques les fichiers à stocker dans SVN avec la commande "svn add"
• tu confirmes le tout avec "svn commit", c'est à ce moment là que tes changements sont réellement appliqués dans le dépôt
• plus tard, à chaque fois que tu voudras mettre à jour les fichiers du dépôt tu referas un commit

C'est à peu près tout ce que tu auras à faire. À l'usage, et si tu partages la maintenance du projet avec d'autres personnes, tu utiliseras "svn diff" (voir un diff des fichiers, c'est là que tu remercieras TortoiseSVN d'avoir une interface) et "svn update" (pour fusionner ta copie locale avec celle du serveur). Il y a aussi quelques attributs à activer sur les fichiers, par exemple pour s'assurer que les fichiers utiliseront toujours les EOL Linux (voir le manuel).

Ok merci je teste tout ça ce soir .

Si tu n'es pas trop fâché avec la langue de Shakespeare, voici une très bonne introduction au versionning et à subversion en particulier (c'est avec ça que j'ai débuté).

Ah au fait, Bugzilla c'est un bug tracker (pour gérer les rapports de bug / feature requests, d'ailleurs tu peux l'utiliser toi-même pour noter les bugs que tu veux réparer plus tard), ViewVC c'est une interface pour rendre accessible ton dépôt par le web et Trac c'est les deux plus un wiki. Mais si tu vas chez Google, tu auras tout ça sans avoir à configurer Trac (qui fonctionne sous Python, au passage).

Bonsoir,

maintenant, les choses s'éclaircissent. Je commence à y voir plus clair (merci ).
J'aimerais installer moi-même le repos (repository) en local. Apparemment, c'est lié à Apache.
Avant de foutre mon Apache en l'air, et de passer des jours à le remettre en place, j'aimerais être sûr de ce que je vais faire.

Gros edit. En tentant de trouver des réponses à mes questions, je suis tombé sur : http://svnbook.red-bean.com/en/1.4/svn-book.html. Je lis ça, et je vous fais signe .

Je n'ai pas envie d'utiliser Google Code car :
1. c'est Google, et quand on lit les licences pour Google Vidéo et Mail, c'est suffisamment effrayant pour ne pas avoir confiance dans Google Code ;
2. je préfère me faire mon propre serveur en local, et en faire une copie sur mon serveur distant, ce sera sans doute plus facile à gérer, non ?

L'idée serait d'avoir tout le système en local, et que je place une copie ensuite sur Internet accessible pour les utilisateurs. Bonne ou mauvaise idée ?
Je risque de changer d'hébergeur dans peu de temps, et j'ai pas envie de tout recommencer ; voilà pourquoi je préfère faire en local, et exporter en distant.
Après niveau maintenance, ce n'est sans doute pas l'idéal :s. J'ai besoin de vos avis !

Bonne nuit.

J'aimerais installer moi-même le repos (repository) en local. Apparemment, c'est lié à Apache.

Non, pas vraiment. Apache peut l'afficher via WEBDAV si mes souvenirs sont bons, mais je ne dirais pas que c'est la meilleure méthode. Mieux vaudrait utiliser ViewVC ou Trac.

quand on lit les licences pour Google Vidéo et Mail, c'est suffisamment effrayant pour ne pas avoir confiance dans Google Code

Je ne connais pas les licences de ces logiciels, mais tu peux choisir la license que tu préfères (Apache, GPL, MIT, etc...) et autant que je me souvienne Google Code ne demande d'adhérer à aucune condition particulière pour être utilisé.

L'idée serait d'avoir tout le système en local, et que je place une copie ensuite sur Internet accessible pour les utilisateurs. Bonne ou mauvaise idée ?

Moyenne idée. Ce qui se fait en général, c'est d'avoir un répertoire "trunk" contenant les versions les plus récentes (et donc qui ne fonctionnent pas toujours) et un répertoire "branches" contenant les versions stables distribuées (eg 1.0, 1.1, 1.2). Parfois certains ont une branche "stable" correspondant à la dernière release stable. À toi d'organiser ton développement en conséquence et maintenir les branches en local. Maintenir plusieurs branches est assez ennuyant, en général les gens ont un répertoire dev et un répertoire stable, de temps à autres ils écrasent le répertoire stable avec les fichiers de dev et ils appellent ça une release.

Je risque de changer d'hébergeur dans peu de temps, et j'ai pas envie de tout recommencer

Tu peux faire un backup de ton repository avec un simple tar, tout est contenu dans un même dossier (à part la config du serveur dans /etc/conf bien sûr).

Mon avis : inscris ton projet chez Google, une branche dev que où tu commit tous les jours et une branche stable pour distribuer tes fichiers et zoum! plus de problèmes Non seulement tu n'auras pas à t'embêter à administrer ton repo mais en plus ça te fait un backup de moins à gérer (je doute que Google pertes tes données).

Pas d'accord sur ton concept des branches, hubert (du coup j'ai relu la doc de subversion pour être sur ):

Ce sont les tags qui permettent de faire des "snapshots" de version stables, des "release".
(même si "permettre" est un grand mot. On va dire qu'habituellement, c'est comme ça qu'on fait)

Par exemple:
svn://127.0.0.1/repos/moncalendrier/tags/release-1.0


Les "branches" sont vraiment des branches de dévelopement, quand on veut faire prendre à une partie du code une autre direction, tout en gardant l'historique, et en maintenant une mise à jour parallèle au trunk et aux autres branches. Si on aime, on peut utiliser plusieurs branches dans sa working copy, mais faut aimer

Maintenant, on appelle ça comme on veut.. j'ai juste choisi d'utiliser ce que conseillait la doc..

Ok pour toutes les infos .

Je décide donc de ne pas utiliser WebDAV, ce sera beaucoup plus simple.
Donc si je veux créer un repos, je fais : , mais si je veux supprimer ce repos, je fais comment ? Et où toutes ces informations sont-elles stockées ? Je veux dire, les numéros de versions, les différents fichiers à leurs différentes versions, les chemins, les branches, les troncs etc. Dans une base de données ? Elle est protégée avec quel mot de passe ? Elle est stockée où ?

J'espère que vous voyez où je veux en venir .

Merci .

si je veux supprimer ce repos, je fais comment ?

Aucune idée, à mon avis un rm -r devrait plutôt bien fonctionner, mais je laisserai quelqu'un d'autre le confirmer (t'as regardé le manuel ?)

Et où toutes ces informations sont-elles stockées ?

Il y a cent ans, SVN utilisait une base de données intégrée, à la SQLite, mais le système a depuis été remplacé par une arborescence de fichiers toute bête. Crée ton dépôt et tu verras, la plupart des fichiers sont lisibles par un humain.