Concernant les images, chartres graphiques, UML, XML (wtf, vous savez pas merger un xml ? ), ....
résoult guère le problème en général.
Tout est affaire de point de vue.
Bizarrement la technique de l'évitement est aussi de mise chez les prosélytes des DVCS
"Ca gère pas mais c'est pas grave."
La paille dans l'oeil, la poutre, et tout ce qui s'ensuit.
Les projets libres de taille importante gèrent beaucoup moins de fichiers de ce type là qu'en entreprise, donc forcément c'est moins important pour eux. Et si un dev est obligé de refaire le boulot 2 fois, ca n'a guère de conséquence car il ne s'en prendra qu'à lui même et ne rendra de compte à personne.
Ca rejoint ma remarque initiale , les DVCS ne sont pas des outils universels et se prêtent beaucoup mieux aux projets communautaires.
Sauvegarde de façon centralisé. Euh kékidi ? Il y'a un serveur de référence qui peut être sauvegardé sans problème.
Sauf que si un développeur développe une feature pendant un certains temps et ne push pas sa branche par négligence ou ignorance et que son disque crash tout son son travail est perdu.
Le dev svn ne perd que son dernier changeset.
Ou alors il faut déployer une solution de sauvegarde automatique sur les postes ce qui n'est pas toujours aisé en entreprise
Tout repose donc sur la vigilance du développeur
Quand à la dernière remarque, Rome ne s'est pas fait en un jour. Git est bien plus jeune que svn, et son intégration dans de nombreux outils va bon train (voir différents post dans ce thread). 2 ans après la sortie de svn, lorsque cvs était encore roi, aurai-tu continuer à utiliser cvs au lieu de svn ?
Sur ce point je suis réservé, git est conçu pour Linux et j'imagine qu'il faudra des changements importants pour qu'il soit acceptable sur Windows.
Ce sera un frein à son adoption dans les IDEs et autres outils mutli-plateformes.
Sur ce point, je suis plus optimiste pour bazaar-ng et mercurial.
[^] # Re: Re:
Posté par Bozo_le_clown . En réponse au journal Git ou Mercurial ?. Évalué à 2.
Concernant les images, chartres graphiques, UML, XML (wtf, vous savez pas merger un xml ? ), ....
résoult guère le problème en général.
Tout est affaire de point de vue.
Bizarrement la technique de l'évitement est aussi de mise chez les prosélytes des DVCS
"Ca gère pas mais c'est pas grave."
La paille dans l'oeil, la poutre, et tout ce qui s'ensuit.
Les projets libres de taille importante gèrent beaucoup moins de fichiers de ce type là qu'en entreprise, donc forcément c'est moins important pour eux. Et si un dev est obligé de refaire le boulot 2 fois, ca n'a guère de conséquence car il ne s'en prendra qu'à lui même et ne rendra de compte à personne.
Ca rejoint ma remarque initiale , les DVCS ne sont pas des outils universels et se prêtent beaucoup mieux aux projets communautaires.
Sauvegarde de façon centralisé. Euh kékidi ? Il y'a un serveur de référence qui peut être sauvegardé sans problème.
Sauf que si un développeur développe une feature pendant un certains temps et ne push pas sa branche par négligence ou ignorance et que son disque crash tout son son travail est perdu.
Le dev svn ne perd que son dernier changeset.
Ou alors il faut déployer une solution de sauvegarde automatique sur les postes ce qui n'est pas toujours aisé en entreprise
Tout repose donc sur la vigilance du développeur
Quand à la dernière remarque, Rome ne s'est pas fait en un jour. Git est bien plus jeune que svn, et son intégration dans de nombreux outils va bon train (voir différents post dans ce thread). 2 ans après la sortie de svn, lorsque cvs était encore roi, aurai-tu continuer à utiliser cvs au lieu de svn ?
Sur ce point je suis réservé, git est conçu pour Linux et j'imagine qu'il faudra des changements importants pour qu'il soit acceptable sur Windows.
Ce sera un frein à son adoption dans les IDEs et autres outils mutli-plateformes.
Sur ce point, je suis plus optimiste pour bazaar-ng et mercurial.