Vrai faux problème. Puis ça fait "troll" (type sendmail ou bind).
> - difficile de faire du svn+ssh et du https en même temps (permissions casse-tête)
Imagines que svn+ssh n'est pas disponible et tu ne peux plus critiquer ça :-)
Le mode svn+ssh est arrivé sur le tard.
> - en https, le client stocke les passwords en clair, ce qui est nul.
Je suis d'accord, c'est nul. Mais comment faire autrement ? C'est comme pour le client mysql par exemple, il faut toujours entrer le mot de passe à chaque foi que le programme est lancé. Peut-être un serveur de mot de passe (sorte d'authentification persistante comme c'est fait sous Gnome pour l'utilisation temporaire du compte root).
> attention qd ils changent le format du repository entre les versions. parfois il faut faire un dump avant l'upgrade et un reload après
Vrai faux problème. Toutes les versions 1.0 sont compatibles.
Puis un dump/load n'est pas très long.
btw : il faut toujours un dump sous la main (en cas de catastrophe).
> apparemment berkeley db n'est pas si génial
Je ne sais pas pourquoi les gens aiment taper sur berkeley db. Mistère...
> pcq certains proposent d'utiliser un nv filesystem appelé FSFS
Il a des avantages et des défauts par rapport à Berkeley db. Actuellement, je reste sous Berkeley db qui marche parfaitement ici.
> subversion n'est pas dispo ds Debian/stable.
C'est un défaut de Debian et pas de subversion. Subversion (client) est dans RedHat depuis la RH8.0. Le serveur (via http ou svn://) est aussi dispo depuis FC1 en standard (pas dans Fedora Extra).
> uis un jour, j'ai installé un subversion pour toute l'équipe.
C'est vrai pour tout. Les gens n'aiment pas le changement et n'aime pas lire de doc. Ce n'est pas spécifique à Subversion.
Subversion a des défauts mais il est 100 fois plus "sain" et prometteur que CVS qui est un truc particuliairement "ugly".
[^] # Re: Subversion
Posté par itstimetogo . En réponse au message CVS ou Subversion, et comment ?. Évalué à 2.
Vrai faux problème. Puis ça fait "troll" (type sendmail ou bind).
> - difficile de faire du svn+ssh et du https en même temps (permissions casse-tête)
Imagines que svn+ssh n'est pas disponible et tu ne peux plus critiquer ça :-)
Le mode svn+ssh est arrivé sur le tard.
> - en https, le client stocke les passwords en clair, ce qui est nul.
Je suis d'accord, c'est nul. Mais comment faire autrement ? C'est comme pour le client mysql par exemple, il faut toujours entrer le mot de passe à chaque foi que le programme est lancé. Peut-être un serveur de mot de passe (sorte d'authentification persistante comme c'est fait sous Gnome pour l'utilisation temporaire du compte root).
> attention qd ils changent le format du repository entre les versions. parfois il faut faire un dump avant l'upgrade et un reload après
Vrai faux problème. Toutes les versions 1.0 sont compatibles.
Puis un dump/load n'est pas très long.
btw : il faut toujours un dump sous la main (en cas de catastrophe).
> apparemment berkeley db n'est pas si génial
Je ne sais pas pourquoi les gens aiment taper sur berkeley db. Mistère...
> pcq certains proposent d'utiliser un nv filesystem appelé FSFS
Il a des avantages et des défauts par rapport à Berkeley db. Actuellement, je reste sous Berkeley db qui marche parfaitement ici.
> subversion n'est pas dispo ds Debian/stable.
C'est un défaut de Debian et pas de subversion. Subversion (client) est dans RedHat depuis la RH8.0. Le serveur (via http ou svn://) est aussi dispo depuis FC1 en standard (pas dans Fedora Extra).
> uis un jour, j'ai installé un subversion pour toute l'équipe.
C'est vrai pour tout. Les gens n'aiment pas le changement et n'aime pas lire de doc. Ce n'est pas spécifique à Subversion.
Subversion a des défauts mais il est 100 fois plus "sain" et prometteur que CVS qui est un truc particuliairement "ugly".