structure de mon seveur subversion

structure de mon seveur subversion - Divers - Programmation

Marsh Posté le 04-05-2010 à 16:38:31    

Bonjour,
 
Je suis entrain de mettre en place un serveur subversion mais j'ai un peu du mal à comprendre comment je dois structurer mes dossiers.
Donc je pensais partir sur une structure de type :

Code :
  1. svn_repo
  2.   |
  3.   +---> project1
  4.   |        |
  5.   |        +---> trunk
  6.   |        |
  7.   |        +---> tags
  8.   |        |       |
  9.   |        |       +---> v1.0
  10.   |        |       |
  11.   |        |       +---> v2.0
  12.   |        |       |
  13.   |        |       +---> ...
  14.   |        |
  15.   |        +---> branches
  16.   |                |
  17.   |                +---> John
  18.   |                |
  19.   |                +---> Robert
  20.   |                |
  21.   |                +---> ...
  22.   |
  23.   +---> project2
  24.   |        |
  25.   |        +---> ...
  26.   |
  27.   +---> projectx ...


- dans les dossiers "trunk", j'ai la dernière version de mon programme en cours d'évolution
- dans les dossiers "tag", j'ai toutes les versions stables de mon projet
- dans les dossiers "branche", chaque utilisateur à un espace perso pour développer les versions temporaires
=> c'est bien comme ça qu'il faut faire ?
 
Ensuite la seconde question que je me pose est où faut-il que je définisse mon référentiel ?  
=> Au départ je pensais qu'il fallait le créer dans "svn_repo" mais le problème est que si par exemple je crée mon premier projet et que je le modifie plusieurs fois (j'arrive par exemple à la révision 10); si je crée un nouveau projet, il va être directement créé avec un numéro de version de 11 (et non pas de 1) vu que le référentiel est "svn_repo". C'est normal ? Ne dois-je pas plutôt créer plusieurs référentiels ? si oui sur quels dossiers ?
 
merci d'avance
 

Reply

Marsh Posté le 04-05-2010 à 16:38:31   

Reply

Marsh Posté le 04-05-2010 à 17:01:07    

si c'est pour faire une branche par utilisateur de manière permanente, m'est avis que vous allez galérer. C'est pas trop l'optique de SVN
Tu as vraiment besoin que ce soit SVN ? Tu ne peux pas utiliser un système de versionning qui soit plus orienté vers des utilisateurs indépendants ? (systèmes distribués à la git)


---------------
last.fm
Reply

Marsh Posté le 04-05-2010 à 17:19:31    

En y réfléchissant bien, je crois que c'est un peu bête de créer une branche par utilisateur dans "branches" => dans "branches", il y a aura plutôt différentes versions du programme en cours de développement avant validation (ça correspond mieux à l'optique de svn, non ?).
 
Lorsqu'on supprime un fichier dans le projet, il est quand même gardé en mémoire dans le repository, non ?
Donc si l'un des éléments qui est dans "branches" doit être supprimé (car le développement est terminé), il prendra quand même de la place dans le disque dur ?
 
 

Reply

Marsh Posté le 04-05-2010 à 17:38:15    

le fonctionnement que j'ai vu le plus souvent, c'est que tout le monde bosse sur Trunk, et quand tu veux livrer une version, tu crées une branche à la dernière révision stable du tronc.
 
Tu fais les fix sur la branche (ou mieux, sur le tronc, puis merge vers la branche)
 
 
Oui, si tu supprimes un fichier dans un projet, il est conservé sur le repository (ca te permet notamment de le retrouver quand tu récupères les révisions précédentes).
Les branches ne tiennent pas de place sur le disque (ou presque) ce sont les modifs que tu apportes à ces branches qui vont prendre de la place (exactement de la même manière que les modifs que tu fais sur le tronc).
 
Si c'est pour un projet perso, tu devrais pas avoir besoin de te soucier de la taille (surtout au prix actuel du tera octet)


---------------
last.fm
Reply

Marsh Posté le 04-05-2010 à 22:11:52    

theshockwave a écrit :

ou mieux, sur le tronc, puis merge vers la branche


Non [:pingouino] c'est mieux de fixer sur la branche, parce que rien ne dit que le trunk est compatible avec la branche, et le plus urgent c'est generalement de fixer la branche de prod, donc on commence par la

Reply

Marsh Posté le 05-05-2010 à 08:57:17    

merci pour vos réponses.
par contre j'ai une question (peut-être un peu bête, désolé) : que voulez-vous dire par le mot "fixer" ?
 
- Pour créer des copies dans le repo du projet (pour faire les branches "tags" et "branches" ) c'est quelle commande qu'il faut utiliser (j'utilise tortoiseSVN) ?
 
 
- Et pour le suivit de bug, vous faites comment (car a priori SVN n'est pas fait pour ça) ? j'ai vu qu'il existait des solutions comme track ou redmine mais ça me semble super lourd pour de petits projets (en grand nombre)...
=> je trouve SVN + tortoiseSVN, très pratique (mais je ne connais pas bien les autres solutions possibles)
 

Reply

Marsh Posté le 05-05-2010 à 10:53:22    

Emcy38 a écrit :

merci pour vos réponses.
par contre j'ai une question (peut-être un peu bête, désolé) : que voulez-vous dire par le mot "fixer" ?
 
- Pour créer des copies dans le repo du projet (pour faire les branches "tags" et "branches" ) c'est quelle commande qu'il faut utiliser (j'utilise tortoiseSVN) ?
 
 
- Et pour le suivit de bug, vous faites comment (car a priori SVN n'est pas fait pour ça) ? j'ai vu qu'il existait des solutions comme track ou redmine mais ça me semble super lourd pour de petits projets (en grand nombre)...
=> je trouve SVN + tortoiseSVN, très pratique (mais je ne connais pas bien les autres solutions possibles)
 


 
par "fixer", on veut dire corriger les problèmes. En général, quand tu te décides à faire ta branche, tu pars ensuite sur une phase de tests et tu corriges les erreurs.
 
Pour la branche, étant donné que ce n'est ni plus ni moins qu'une copie, j'aurais tendance à dire qu'il te suffit de faire un svn copy de ton arborescence au sein de ton repository. Ca doit sans doute être accessible depuis le repo browser. J'ai pas de svn sous la main ici pour vérifier, cela dit.
 
Pour le suivi des bugs (et tâches), tu as un paquet de solutions. Je n'ai pas vraiment d'avis sur le sujet, j'ai juste entendu du bien au sujet de redmine.


---------------
last.fm
Reply

Marsh Posté le 05-05-2010 à 13:29:37    

j'ai regardé un peu comment installer redmine, ça à l'air d'être un peu une usine à gaz (surtout si on veut l'installer sous windows)
 
 

souk a écrit :


Non [:pingouino] c'est mieux de fixer sur la branche, parce que rien ne dit que le trunk est compatible avec la branche, et le plus urgent c'est generalement de fixer la branche de prod, donc on commence par la


De ce que j'ai pu comprendre du fonctionnement de SVN, si un bug est découvert, on crée copie (peut être partielle) du trunk du projet vers une nouvelle branche de la partie "projetx/branches". Ensuite on fixe le bug et une fois que c'est validé on fusionne vers le trunk (sachant qu'entre la copie et la fusion, le trunk aura pu très bien évolué).
On pourrait très bien travailler directement sur le trunk aussi si la modification n'est pas trop grosse.
 
=> pour moi, toutes les données qui sont mises dans la partie "/projetx/tag" ne doivent jamais être modifiées (ce n'est que le trunk qui doit évoluer)

Message cité 1 fois
Message édité par Emcy38 le 05-05-2010 à 13:31:03
Reply

Marsh Posté le 05-05-2010 à 16:37:30    

Emcy38 a écrit :


=> pour moi, toutes les données qui sont mises dans la partie "/projetx/tag" ne doivent jamais être modifiées (ce n'est que le trunk qui doit évoluer)


 
quoiqu'il arrive, si, ce sera modifié. Que ce soit en corrigeant directement sur le tag un bug repéré après création du tag ou en mergeant une modif du trunk que tu veux finalement aussi incorporer dans ton livrable.


Message édité par theshockwave le 05-05-2010 à 16:37:49

---------------
last.fm
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed