Un intérêt pratique est aussi pour la gestion des droits. Avec CVS/Subversion, un contributeur qui n'a pas les droits sur le repository est obligé d'envoyer ses contribution par patch. C'est la galère pour lui si il met du temps à mettre sa contribution au point et qu'il est obligé de faire des updates entre temps. Une solution est de lui donner les droits en commit sur le repository central, mais on n'aime pas donner les droits à n'importe qui non plus. ...
Tu peux préciser ce point. Toujours en mettant à part le fait d'historiser des changements intermédiaires, en quoi est-ce différent d'un système centralisé ?
Tu fais un checkout du repository,
tu fais des modifs,
tu updates de temps à autre
et après soit tu commit parce que tu as obtenu les droits sur le repository soit tu envoies un patch.
Avec un sytème décentralisé le pb est le même si tu n'as pas de droit en ecriture sur l'archive principale ?
Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression.
Rien n'empêche de créer une branche par développeur et au moins le chef de projet voit où en est l'état d'avancement des changements que tu prends en charge.
Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
En disposant d'une copie de travail rien ne t'empêche de travailer en mode déconnecté, la seule limitation étant encore et toujours de ne pas pouvoir historiser de changements intermédiaires.(et encore c'est une feature qui devrait pouvoir être implémneté par clonage de working copy).
Les seuls outils que je connaisse qui souffrent de limitation sur ce point car les copies de travail sont connectée en permanence avec le serveur sont Clearcase avec les vues dynamiques (et pas snapshot), Vesta( http://www.vestasys.org/(...) ) et Aegis ( http://aegis.sourceforge.net/(...) )
[^] # Re: Bazaar
Posté par golum . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 2.
Tu peux préciser ce point. Toujours en mettant à part le fait d'historiser des changements intermédiaires, en quoi est-ce différent d'un système centralisé ?
Tu fais un checkout du repository,
tu fais des modifs,
tu updates de temps à autre
et après soit tu commit parce que tu as obtenu les droits sur le repository soit tu envoies un patch.
Avec un sytème décentralisé le pb est le même si tu n'as pas de droit en ecriture sur l'archive principale ?
Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression.
Rien n'empêche de créer une branche par développeur et au moins le chef de projet voit où en est l'état d'avancement des changements que tu prends en charge.
Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
En disposant d'une copie de travail rien ne t'empêche de travailer en mode déconnecté, la seule limitation étant encore et toujours de ne pas pouvoir historiser de changements intermédiaires.(et encore c'est une feature qui devrait pouvoir être implémneté par clonage de working copy).
Les seuls outils que je connaisse qui souffrent de limitation sur ce point car les copies de travail sont connectée en permanence avec le serveur sont Clearcase avec les vues dynamiques (et pas snapshot), Vesta( http://www.vestasys.org/(...) ) et Aegis ( http://aegis.sourceforge.net/(...) )