> Salut,
> 

Salut,

> Je fais un projet de logiciel libre (mon premier), et j'ai pour ça un
> dépôt Subversion (SVN).
> Je voudrais savoir comment marche un dépôt SVN d'habitude: à quoi 
> servent les répertoire "trunk" et "branches", quel est l'organisation
> habituelle d'un SVN, etc...

Je travail depuis quelques années avec subversion qui est un fabuleux
outil.

Un dépôt svn est une arborescence géré donc par subversion accessible la
plupart du temps via par un serveur web (en http ou https) pour la
communication entre ce dépôt et les copies de travail sur le/les postes
des développeurs...
Usuellement les arborescences d'un projet sous le contrôle de subversion
sont sur le dépôt de type :
projet
|-branches/
|-tags/
`-trunk/

- Le "trunk" est le tronc commun de développement, c'est en général dans
cette "branche" que l'on développe au fil de l'eau (enfin sur la copie
de travail local de cette branche) et qu'en suite on commit sur le dépôt
(par modification incrémentale). Chaque "commit" incrémente la version
courant générale du dépôt et celle de la révision de la dernière
modification de la branche courante.

- "tags" en général est utilisé pour "tagger" (copier) une version
fonctionnelle du tronc commun à un moment particulier (comme par exemple
à la livraison / déploiement d'une version logicielle).

Par exemple:
tags/
|-V1.00
|-V1.01-PourClientLambda
`-V1.02-LivraisonFinlande

En générale issue de svn cp URL[trunk] URL[tags/V1.00]

Outre la version 'r' subversion à un moment donné que l'on est capable
de récupérer si besoin (mais qu'on ne connait pas forcément - mais qu'on
peut retrouver dans les logs) ça permet de se dire "tiens mon client à
un problème avec la V1.01, moi j'ai fait pas mal de modification dans
mon tronc commun de développement.. Je souhaite identifier son bug dans
SA version à lui : qu'à cela ne tienne j'exporte la V1.01 du dépôt sur
ma machine et j'investigue..." (par exemple)

- "branches" en général est utilisé pour créer des branches de
développement (partie ou cas spécifiques) dans le buts d'être une fois
finalisé "mergé" dans le tronc commun...
(exemple : un cas particulier pour un client que je développe
spécialement pour lui, et qu'à terme il serait intéressant d'inclure
dans la version standard du logiciel pour d'autres client - mais sans se
mélanger les crayons entre le tronc commun de développement et une
partie spécifique...). Si on opère pas sur les mêmes fichiers ou partie
entre le tronc commun de développement et une branche le merge se passe
assez bien ensuite (les modifs/ajouts des deux côté sont fusionner pour
former une version finale...)
Par exemple
branches
|-ZimoulinAResterEnLair_PourClientCapricieux
|-NouvelleGestionDecodageBasNiveau


Je ne dis pas que c'est LA méthode ni l'Organisation parfaite, ma c'est
assez fréquemment utilisé de cette manière là.

Il s'agit d'un outils assez formidable également pour un travail
d'équipe, quand plusieurs (quelques unes ou même beaucoup) travail sur
un même projet, aussi bien dans la fonctionnalité de base de regrouper
et versionner le travail accomplis, mais également au niveau traçabilité
de développement.

Le wiki est assez bien fait http://fr.wikipedia.org/wiki/Subversion_%
28logiciel%29

La combinaison avec trac est très intéressante...

Pour ma part, j'ai travaillé 3 ans avec CVS précédemment pour ensuite
passé sous SVN et toujours satisfait de cette outil (même si git
aujourd'hui est plus en vogue pour des raisons techniques et linuxiennes
- forcément développé par Monsieur Torvalds .. ;))

> Je ne cherche pas à savoir comment on utilise la commande "svn" ou 
> comment on paramètre le dépôt (j'ai déjà le manuel pour ça :-) ), mais 
> des choses sur l'organisation en général de ce type de choses...
> 
> Si vous avez des liens, des infos ou des conseils, merci d'avance...

Espérant avoir pu t'apporter un peu d'infos,

A+
Vincent





 Diffusez cette liste aupres de vos relations :-)
            Linux Azur : http://linux-azur.org
       Vous etes responsable de vos propos.
*** Pas de message SMS, HTML ni de PJ SVP ***

Répondre à