Le vendredi 19 mars 2010 à 15:45 +0100, Vincent BRACH a écrit : > 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
Merci, c'est exactement ce que je voulais savoir :-) En fait, je gardais la version stable (enfin, la plus stable :-p) dans "/trunk" et je mettais à côté la version en développement... Mais si quelqu'un télécharge le projet, il vas tomber sur la version stable, qui sera fonctionnelle pour l'utilisation, mais obsolète. Je vais donc mettre un peu d'ordre dans tout ça, ça me permettra de travailler plus efficacement :-) Merci à tous pour vos réponses :-) -- ╭─────────────────────────────────────────────╮ │ ⬚ [ xterm - r...@skami ] − □ X │ ├─────────────────────────────────────────────┤ │| r...@skami# cat /proc/info |│ │| Mail: <[email protected]> |│ │| Site: <http://sk18_website.sfhost.net> |│ │| Projet: <http://pspmt.googlecode.com> |│ │| r...@skami# |│ └─────────────────────────────────────────────┘ 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 ***
