La gestion des tag est vraiment, vraiment stupide. En fait, il n'y en a pas. Ce qui est pire. Il leur suffisait de pouvoir associer un texte unique (hum VERSION_1.0) par exemple à un numéro de commit, vraiment RIEN a faire. Mais pkoi ne l'ont-ils pas fait tout simplement????
Ce n'est pas dans la philosophie: Tags et branches ne sont pas des concepts à part entière (métadonnées). Rien ne t'empêche de te créer une commande qui applique une propertie sur le répertoire de ton tag au moment où tu le crées et avec un cp, genre:
svn propset mon-projet-release "VERSION_1.0" /monprojet/tag1.
Ainsi, si quelqu'un commite par erreur sur le tag tu pourras repérer rapidement la révision avant l'erreur avec un svn log et revenir en arrière ( http://svnbook.red-bean.com/en/1.5 /svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo ) ou démarrer une branche de patch genre
svn cp /monprojet/tag1@(marévisiontaggée) /monprojet/branches/version1-0-patch.
Après tout un tag ca sert juste à ça.
Je t'accorde que leur modèle est bancal, en témoigne la gestion foireuse des merge qui gère mal cette ambiguité.
C'est pas près de s'améliorer je crois.
Les hooks c'est à mon avis pour les gros projets, le notre ils suffit qu'on se disent que l'on ne va pas commiter sur des tags et ça suffira.
Au contraire, plus le projet est gros plus les hooks pénalisent. Chaque commit déclenche le hook même s'il ne fait rien. Enfin faudrait vérifier.
[^] # Re: checkout d'un sous-repertoire ... tout simplement
Posté par nomorepost . En réponse au message Empecher le checkout automatique des tags en svn. Évalué à 2.
La gestion des tag est vraiment, vraiment stupide. En fait, il n'y en a pas. Ce qui est pire. Il leur suffisait de pouvoir associer un texte unique (hum VERSION_1.0) par exemple à un numéro de commit, vraiment RIEN a faire. Mais pkoi ne l'ont-ils pas fait tout simplement????
Ce n'est pas dans la philosophie: Tags et branches ne sont pas des concepts à part entière (métadonnées). Rien ne t'empêche de te créer une commande qui applique une propertie sur le répertoire de ton tag au moment où tu le crées et avec un cp, genre:
svn propset mon-projet-release "VERSION_1.0" /monprojet/tag1.
Ainsi, si quelqu'un commite par erreur sur le tag tu pourras repérer rapidement la révision avant l'erreur avec un svn log et revenir en arrière ( http://svnbook.red-bean.com/en/1.5 /svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo ) ou démarrer une branche de patch genre
svn cp /monprojet/tag1@(marévisiontaggée) /monprojet/branches/version1-0-patch.
Après tout un tag ca sert juste à ça.
Je t'accorde que leur modèle est bancal, en témoigne la gestion foireuse des merge qui gère mal cette ambiguité.
C'est pas près de s'améliorer je crois.
Les hooks c'est à mon avis pour les gros projets, le notre ils suffit qu'on se disent que l'on ne va pas commiter sur des tags et ça suffira.
Au contraire, plus le projet est gros plus les hooks pénalisent. Chaque commit déclenche le hook même s'il ne fait rien. Enfin faudrait vérifier.