jy[B]log

Commentaires

1. Le mercredi, juin 1 2005, 12:26 par Romain

C'est super. On va pouvoir reprendre les traductions. :)

Romain

2. Le mercredi, juin 1 2005, 12:32 par Batmat

Aaahh, ben voilà. Tu as entrevu la lumière ;)

3. Le mercredi, juin 1 2005, 22:01 par Pierrick

Seul ombre au tableau, la gestion des tags.

Je dirais plutôt que les tags sont restés pour ne pas trop dépayser les utilisateurs de CVS. En ce qui me concerne, ce qui remplace les tags, c'est les numéros de version propre au commit dans un dépôt complet et non plus propre à chaque fichier.

Sous CVS, un tag permet de retrouver facilement une liste de fichiers, chacun dans une version donnée. La plupart du temps, le tag correspond à un commit. Sous Subversion, tu as déjà un numéro de version pour ton commit. Ainsi tu peux récupérer soit uniquement les fichiers modifiés dans ton commit, soit la distribution complète au moment du commit.

Je dirais que la gestion des tags est différente, mais certainement pas une "ombre au tableau" :-)

4. Le jeudi, juin 2 2005, 10:01 par Laurentj

Si, pour moi, cela reste une ombre au tableau. va donc mémoriser les numeros de versions de commit dans SVN, pour chaque release de ton soft.. Dans CVS, au moins, le tag a un nom, un vrai, mémorisable facilement, et tu peux en recuperer la liste via les logs.

alors certes, dans svn, quand tu fais un tag, tu as aussi un nom, mais c'est finalement une branche, et qui est d'ailleurs modifiable. Bref, un tag dans subversion, ça ne correspond pas vraiment à un etat à un moment donné, sauf à etre rigoureux dans cette gestion, ne pas modifier quoique ce soit dans la branche du tag etc.. mais les erreurs sont toujours possibles. Au moins dans CVS, tu es sur qu' à un tag donné, cela correspond vraiment à un état donné d'une branche/tronc.

5. Le jeudi, juin 2 2005, 22:19 par Laurent Simon

Je suis également passé de CVS à SVN il y a quelques mois et j'ai été confronté au même problème. J'ai finalement trouvé une solution.

A partir du moment ou tu organise tes branches et tes tags dans des sous répertoires différents ( ./branches et ./tags par exemple), déjà tu fais bien la différence entre les tags et les branches mais de plus tu peux te servir de cette différence comme distinguo pour spécialiser la réaction de SVN à l'aide des scripts de Hook.

Pour ma part, je mets le script suivant sur le hook pre-commit afin d'interdire un commit sur un tag et de refuser les commits sans commentaires ailleurs :

REPOS="$1"
TXN="$2"

# Check for modification of tags.
# Reject tag modifications except creation and deletion
SVNLOOK=/usr/bin/svnlook
echo "=============== changed ================" >>/tmp/pre-commit.log
$SVNLOOK changed -t "$TXN" "$REPOS" >>/tmp/pre-commit.log
$SVNLOOK changed -t "$TXN" "$REPOS" | grep "tags/" >/dev/null
if [ $? -eq 0 ] ; then
   $SVNLOOK changed -t "$TXN" "$REPOS" | egrep "^[AD][[:space:]]+(.*/)?tags/[^/]+/$" >/dev/null
   if [ $? -ne 0 ] ; then
       echo >&2 "Les tags ne sont pas modifiables"
       exit 1
   fi
fi
#
# Make sure that the log message contains some text.
$SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" >/dev/null
if [ $? -ne 0 ] ; then
   echo >&2 "Pas de commentaires, pas de commit"
   exit 1
fi

exit 0

6. Le vendredi, juin 3 2005, 16:59 par Benoit

Pour Mozilla, ils ont encore dit au FOSDEM cette année qu'il avaient essayé mais rien à faire, le code est trop gros et l'historique est trop compliqué pour être importé dans un autre système. Il y aurait également tous les outils comme bonsai et tinderbox à reprogrammer.

Rechercher

• Accueil -
• Archives