[traduction]Qu'est ce que c'est que ce "bazaar"? ;)
38 réponses
Andréï
Salut,
c'est la première fois que je participe à un projet communautaire, et
la je commence a ne plus comprendre.
Sur la page de traduction il y a un mode d'emploi de "bazaar", mais
j'ai toujours pas compris a quoi celui servait.
et c'est quoi ces branches?
c'est un logiciel ftp?
:-?
Salut, c'est la première fois que je participe à un projet communautaire, et la je commence a ne plus comprendre. Sur la page de traduction il y a un mode d'emploi de "bazaar", mais j'ai toujours pas compris a quoi celui servait. et c'est quoi ces branches? c'est un logiciel ftp? :-?
Salut,
c'est la première fois que je participe à un projet communautaire, et la
je commence a ne plus comprendre.
Sur la page de traduction il y a un mode d'emploi de "bazaar", mais j'ai
toujours pas compris a quoi celui servait.
et c'est quoi ces branches?
c'est un logiciel ftp?
:-?
Salut, c'est la première fois que je participe à un projet communautaire, et la je commence a ne plus comprendre. Sur la page de traduction il y a un mode d'emploi de "bazaar", mais j'ai toujours pas compris a quoi celui servait. et c'est quoi ces branches? c'est un logiciel ftp? :-?
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion Cela permet de gérer les différentes versions d'un programme salut,
je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à un programme le role de donner un numéro à un programme? Le programmeur est trop bete pour savoir qu'après 1 c'est 2 qui vient? ou alors c'est moi? byebye :-?
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion
Cela permet de gérer les différentes versions d'un programme
salut,
je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à
un programme le role de donner un numéro à un programme? Le programmeur
est trop bete pour savoir qu'après 1 c'est 2 qui vient? ou alors c'est
moi?
byebye :-?
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion Cela permet de gérer les différentes versions d'un programme salut,
je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à un programme le role de donner un numéro à un programme? Le programmeur est trop bete pour savoir qu'après 1 c'est 2 qui vient? ou alors c'est moi? byebye :-?
Olivier
Hello,
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion Cela permet de gérer les différentes versions d'un programme
salut, je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à un programme le role de donner un numéro à un programme?
Moi aussi, j'ai mis du temps à voir l'intérêt, ça donne l'impression de se compliquer la vie pour rien, surtout quand on a très bien travaillé sans jusqu'alors, mais je m'y suis mis il y a un an, et maintenant, je ne *peux plus* travailler sans, même pour des projets individuels.
Ca t'apporte une sécurité et - une fois qu'on a pris le coup de main - une simplicité incroyable dans la gestion de ton code, à la fois au jour le jour, et quand tu te poses des questions du genre (par exemple) : tiens, ça serait bien que je réutilise telle fonction que j'avait écrite il y a trois mois quand j'avais voulu écrire mon appli avec [framework x], avant que je fasse des changements qui ont tout cassé, puis que je la supprime deux jours plus tard et que je bascule tout un mois après sous [framework y].
J'utilise subversion, et associé à trac (http://www.edgewall.com/trac/), qui te donne une interface graphique, l'historique commenté de tes révisions, une belle visualisation de tes diffs, la documentation de tes changesets (entre autre), ce n'est que du bonheur.
Olivier
Hello,
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion
Cela permet de gérer les différentes versions d'un programme
salut,
je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à un
programme le role de donner un numéro à un programme?
Moi aussi, j'ai mis du temps à voir l'intérêt, ça donne l'impression de
se compliquer la vie pour rien, surtout quand on a très bien travaillé
sans jusqu'alors, mais je m'y suis mis il y a un an, et maintenant, je
ne *peux plus* travailler sans, même pour des projets individuels.
Ca t'apporte une sécurité et - une fois qu'on a pris le coup de main -
une simplicité incroyable dans la gestion de ton code, à la fois au jour
le jour, et quand tu te poses des questions du genre (par exemple) :
tiens, ça serait bien que je réutilise telle fonction que j'avait écrite
il y a trois mois quand j'avais voulu écrire mon appli avec [framework
x], avant que je fasse des changements qui ont tout cassé, puis que je
la supprime deux jours plus tard et que je bascule tout un mois après
sous [framework y].
J'utilise subversion, et associé à trac (http://www.edgewall.com/trac/),
qui te donne une interface graphique, l'historique commenté de tes
révisions, une belle visualisation de tes diffs, la documentation de tes
changesets (entre autre), ce n'est que du bonheur.
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion Cela permet de gérer les différentes versions d'un programme
salut, je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à un programme le role de donner un numéro à un programme?
Moi aussi, j'ai mis du temps à voir l'intérêt, ça donne l'impression de se compliquer la vie pour rien, surtout quand on a très bien travaillé sans jusqu'alors, mais je m'y suis mis il y a un an, et maintenant, je ne *peux plus* travailler sans, même pour des projets individuels.
Ca t'apporte une sécurité et - une fois qu'on a pris le coup de main - une simplicité incroyable dans la gestion de ton code, à la fois au jour le jour, et quand tu te poses des questions du genre (par exemple) : tiens, ça serait bien que je réutilise telle fonction que j'avait écrite il y a trois mois quand j'avais voulu écrire mon appli avec [framework x], avant que je fasse des changements qui ont tout cassé, puis que je la supprime deux jours plus tard et que je bascule tout un mois après sous [framework y].
J'utilise subversion, et associé à trac (http://www.edgewall.com/trac/), qui te donne une interface graphique, l'historique commenté de tes révisions, une belle visualisation de tes diffs, la documentation de tes changesets (entre autre), ce n'est que du bonheur.
Olivier
bruno at modulix
Andréï wrote:
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion Cela permet de gérer les différentes versions d'un programme
salut, je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à un programme le role de donner un numéro à un programme? Le programmeur est trop bete pour savoir qu'après 1 c'est 2 qui vient?
Le problème n'est pas de numéroter, mais de * garder l'historique des modifications * pouvoir comparer, revenir en arrière, etc * pouvoir gérer des branches différentes, et les faire se rejoindre * pouvoir travailler à plusieurs sur un même projet sans se marcher sur les pieds
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Andréï wrote:
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion
Cela permet de gérer les différentes versions d'un programme
salut,
je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à un
programme le role de donner un numéro à un programme? Le programmeur est
trop bete pour savoir qu'après 1 c'est 2 qui vient?
Le problème n'est pas de numéroter, mais de
* garder l'historique des modifications
* pouvoir comparer, revenir en arrière, etc
* pouvoir gérer des branches différentes, et les faire se rejoindre
* pouvoir travailler à plusieurs sur un même projet sans se marcher sur
les pieds
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
C'est un gestionnaire de version comme CVS, GNU Arch, Subversion Cela permet de gérer les différentes versions d'un programme
salut, je vois pas trop l'utilité de ce type de logiciel, pourquoi confier à un programme le role de donner un numéro à un programme? Le programmeur est trop bete pour savoir qu'après 1 c'est 2 qui vient?
Le problème n'est pas de numéroter, mais de * garder l'historique des modifications * pouvoir comparer, revenir en arrière, etc * pouvoir gérer des branches différentes, et les faire se rejoindre * pouvoir travailler à plusieurs sur un même projet sans se marcher sur les pieds
-- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
R12y
On Tue, 13 Dec 2005 10:28:58 +0100, bruno at modulix wrote:
* pouvoir gérer des branches différentes, et les faire se rejoindre * pouvoir travailler à plusieurs sur un même projet sans se marcher sur les pieds
Au sujet de ces deux points:
Ce que tu cite comme avantage permet donc de gérer le fait que deux participant _peuvent_ modifier la même ressource en même temps. En supposant que les modifs ne soient pas "mergeables" (compatibilité, etc etc) on aura plutot ajouté un problème au lieu d'en résoudre, non?
En fait j'ai du mal à voir pourquoi la possibilité de modifier "chacun dans son coin" (c'est comme ça que j'interprete "sans se marcher sur les pieds") est un avantage. Pour moi, on devrait vérouiller un fichier sur lequel un membre du projet travaille déjà... ai-je tort?
PS: Attention au Follow-up.
-- Telephone portable "intelligent" (SmartPhone) GSM, GPRS,... Il est sous Linux, ne coute pas trop cher,... http://www.it2l.com/product_info.php?cPath&products_idE6
On Tue, 13 Dec 2005 10:28:58 +0100, bruno at modulix wrote:
* pouvoir gérer des branches différentes, et les faire se rejoindre
* pouvoir travailler à plusieurs sur un même projet sans se marcher sur
les pieds
Au sujet de ces deux points:
Ce que tu cite comme avantage permet donc de gérer le fait que deux
participant _peuvent_ modifier la même ressource en même temps. En
supposant que les modifs ne soient pas "mergeables" (compatibilité, etc
etc) on aura plutot ajouté un problème au lieu d'en résoudre, non?
En fait j'ai du mal à voir pourquoi la possibilité de modifier "chacun
dans son coin" (c'est comme ça que j'interprete "sans se marcher sur les
pieds") est un avantage. Pour moi, on devrait vérouiller un fichier sur
lequel un membre du projet travaille déjà... ai-je tort?
PS: Attention au Follow-up.
--
Telephone portable "intelligent" (SmartPhone) GSM, GPRS,...
Il est sous Linux, ne coute pas trop cher,...
http://www.it2l.com/product_info.php?cPath&products_idE6
On Tue, 13 Dec 2005 10:28:58 +0100, bruno at modulix wrote:
* pouvoir gérer des branches différentes, et les faire se rejoindre * pouvoir travailler à plusieurs sur un même projet sans se marcher sur les pieds
Au sujet de ces deux points:
Ce que tu cite comme avantage permet donc de gérer le fait que deux participant _peuvent_ modifier la même ressource en même temps. En supposant que les modifs ne soient pas "mergeables" (compatibilité, etc etc) on aura plutot ajouté un problème au lieu d'en résoudre, non?
En fait j'ai du mal à voir pourquoi la possibilité de modifier "chacun dans son coin" (c'est comme ça que j'interprete "sans se marcher sur les pieds") est un avantage. Pour moi, on devrait vérouiller un fichier sur lequel un membre du projet travaille déjà... ai-je tort?
PS: Attention au Follow-up.
-- Telephone portable "intelligent" (SmartPhone) GSM, GPRS,... Il est sous Linux, ne coute pas trop cher,... http://www.it2l.com/product_info.php?cPath&products_idE6
jean-michel bain-cornu
Bonjour, R12y wrote:
On Tue, 13 Dec 2005 10:28:58 +0100, bruno at modulix wrote:
* pouvoir gérer des branches différentes, et les faire se rejoindre * pouvoir travailler à plusieurs sur un même projet sans se marcher sur les pieds
Au sujet de ces deux points:
Ce que tu cite comme avantage permet donc de gérer le fait que deux participant _peuvent_ modifier la même ressource en même temps. En supposant que les modifs ne soient pas "mergeables" (compatibilité, etc etc) on aura plutot ajouté un problème au lieu d'en résoudre, non? Il est très rare qu'on travaille à plusieurs sur la même portion de
code. Si cela arrive, c'est un problème en soi, qui est signalé par le gestionnaire de version.
En fait j'ai du mal à voir pourquoi la possibilité de modifier "chacun dans son coin" (c'est comme ça que j'interprete "sans se marcher sur les pieds") est un avantage. Pour moi, on devrait vérouiller un fichier sur lequel un membre du projet travaille déjà... ai-je tort? Oui, surtout si les gens qui travaillent sur le projet sont nombreux,
s'ils ne sont pas au même endroit, s'ils ne bossent pas à la même heure, s'ils sont anonymes, etc. La question du verrou sur un source en cours de modif est un vieux débat (CVS contre PVCS/Clearcase/etc) qui a ses deux camps, mais qui n'empêche pas la sécurité apportée par ce type d'outil : tout code est 'imperdable'.
PS: Attention au Follow-up.
ça voudrait-il dire qu'on est hors sujet ?
A+ jm
Bonjour,
R12y wrote:
On Tue, 13 Dec 2005 10:28:58 +0100, bruno at modulix wrote:
* pouvoir gérer des branches différentes, et les faire se rejoindre
* pouvoir travailler à plusieurs sur un même projet sans se marcher sur
les pieds
Au sujet de ces deux points:
Ce que tu cite comme avantage permet donc de gérer le fait que deux
participant _peuvent_ modifier la même ressource en même temps. En
supposant que les modifs ne soient pas "mergeables" (compatibilité, etc
etc) on aura plutot ajouté un problème au lieu d'en résoudre, non?
Il est très rare qu'on travaille à plusieurs sur la même portion de
code. Si cela arrive, c'est un problème en soi, qui est signalé par le
gestionnaire de version.
En fait j'ai du mal à voir pourquoi la possibilité de modifier "chacun
dans son coin" (c'est comme ça que j'interprete "sans se marcher sur les
pieds") est un avantage. Pour moi, on devrait vérouiller un fichier sur
lequel un membre du projet travaille déjà... ai-je tort?
Oui, surtout si les gens qui travaillent sur le projet sont nombreux,
s'ils ne sont pas au même endroit, s'ils ne bossent pas à la même heure,
s'ils sont anonymes, etc.
La question du verrou sur un source en cours de modif est un vieux débat
(CVS contre PVCS/Clearcase/etc) qui a ses deux camps, mais qui n'empêche
pas la sécurité apportée par ce type d'outil : tout code est 'imperdable'.
On Tue, 13 Dec 2005 10:28:58 +0100, bruno at modulix wrote:
* pouvoir gérer des branches différentes, et les faire se rejoindre * pouvoir travailler à plusieurs sur un même projet sans se marcher sur les pieds
Au sujet de ces deux points:
Ce que tu cite comme avantage permet donc de gérer le fait que deux participant _peuvent_ modifier la même ressource en même temps. En supposant que les modifs ne soient pas "mergeables" (compatibilité, etc etc) on aura plutot ajouté un problème au lieu d'en résoudre, non? Il est très rare qu'on travaille à plusieurs sur la même portion de
code. Si cela arrive, c'est un problème en soi, qui est signalé par le gestionnaire de version.
En fait j'ai du mal à voir pourquoi la possibilité de modifier "chacun dans son coin" (c'est comme ça que j'interprete "sans se marcher sur les pieds") est un avantage. Pour moi, on devrait vérouiller un fichier sur lequel un membre du projet travaille déjà... ai-je tort? Oui, surtout si les gens qui travaillent sur le projet sont nombreux,
s'ils ne sont pas au même endroit, s'ils ne bossent pas à la même heure, s'ils sont anonymes, etc. La question du verrou sur un source en cours de modif est un vieux débat (CVS contre PVCS/Clearcase/etc) qui a ses deux camps, mais qui n'empêche pas la sécurité apportée par ce type d'outil : tout code est 'imperdable'.
PS: Attention au Follow-up.
ça voudrait-il dire qu'on est hors sujet ?
A+ jm
R12y
La question du verrou sur un source en cours de modif est un vieux débat
Ok. Merci pour ces précisions.
PS: Attention au Follow-up. ça voudrait-il dire qu'on est hors sujet ?
Pas vraiment, mais qu'il y a un meilleur endroit pour en parler :-).
-- Telephone portable "intelligent" (SmartPhone) GSM, GPRS,... Il est sous Linux, ne coute pas trop cher,... http://www.it2l.com/product_info.php?cPath&products_idE6
La question du verrou sur un source en cours de modif est un vieux débat
Ok. Merci pour ces précisions.
PS: Attention au Follow-up.
ça voudrait-il dire qu'on est hors sujet ?
Pas vraiment, mais qu'il y a un meilleur endroit pour en parler :-).
--
Telephone portable "intelligent" (SmartPhone) GSM, GPRS,...
Il est sous Linux, ne coute pas trop cher,...
http://www.it2l.com/product_info.php?cPath&products_idE6
La question du verrou sur un source en cours de modif est un vieux débat
Ok. Merci pour ces précisions.
PS: Attention au Follow-up. ça voudrait-il dire qu'on est hors sujet ?
Pas vraiment, mais qu'il y a un meilleur endroit pour en parler :-).
-- Telephone portable "intelligent" (SmartPhone) GSM, GPRS,... Il est sous Linux, ne coute pas trop cher,... http://www.it2l.com/product_info.php?cPath&products_idE6
Do Re Mi chel La Si Do
Bonsoir !
J'ai un avis qui va dans une autre direction.
J'avais voulu essayer subversion. Mais, je me suis vite rendu compte que cet outil, est, en fait très structurant. Il impose une architecture, des façons de travailler, des méthodes de développement. Sans le dire.
Et, (malheureusement ?) cela était incompatible avec les projets sur lesquels j'avais voulu tester. En pratique, la moitié des postes n'avaient pas à Internet, ou à du FTP (alors, WebDav ...). De plus, ces projets tiennent compte de la configuration de chaque poste. Y compris jusqu'au système.
Cela faisait beaucoup choses qui ne pouvaient pas être pris en compte, ou pas traités de façon complète. Le principe du client-serveur synchrone est déjà trop restrictif, à mon sens. Il faudrait, au moins, introduire des réplications asynchrone intelligentes, un peu dans le genre de Lotus Notes.
Et puis, il est difficile de prendre en compte les sources, s'ils ne sont pas ASCII. Pas facile d'associer des documents externes au PAQL.
Etc.
Bref, j'ai ressenti ça comme une limitation à la créativité du développement, et à une lourdeur non compensée par les aspects positifs.
Ceci dit, dans certaines SSII "à l'ancienne", ça doit être intéressant.
@-salutations
Michel Claveau
Bonsoir !
J'ai un avis qui va dans une autre direction.
J'avais voulu essayer subversion. Mais, je me suis vite rendu compte que cet
outil, est, en fait très structurant. Il impose une architecture, des façons
de travailler, des méthodes de développement. Sans le dire.
Et, (malheureusement ?) cela était incompatible avec les projets sur
lesquels j'avais voulu tester. En pratique, la moitié des postes n'avaient
pas à Internet, ou à du FTP (alors, WebDav ...).
De plus, ces projets tiennent compte de la configuration de chaque poste. Y
compris jusqu'au système.
Cela faisait beaucoup choses qui ne pouvaient pas être pris en compte, ou
pas traités de façon complète. Le principe du client-serveur synchrone est
déjà trop restrictif, à mon sens. Il faudrait, au moins, introduire des
réplications asynchrone intelligentes, un peu dans le genre de Lotus Notes.
Et puis, il est difficile de prendre en compte les sources, s'ils ne sont
pas ASCII. Pas facile d'associer des documents externes au PAQL.
Etc.
Bref, j'ai ressenti ça comme une limitation à la créativité du
développement, et à une lourdeur non compensée par les aspects positifs.
Ceci dit, dans certaines SSII "à l'ancienne", ça doit être intéressant.
J'avais voulu essayer subversion. Mais, je me suis vite rendu compte que cet outil, est, en fait très structurant. Il impose une architecture, des façons de travailler, des méthodes de développement. Sans le dire.
Et, (malheureusement ?) cela était incompatible avec les projets sur lesquels j'avais voulu tester. En pratique, la moitié des postes n'avaient pas à Internet, ou à du FTP (alors, WebDav ...). De plus, ces projets tiennent compte de la configuration de chaque poste. Y compris jusqu'au système.
Cela faisait beaucoup choses qui ne pouvaient pas être pris en compte, ou pas traités de façon complète. Le principe du client-serveur synchrone est déjà trop restrictif, à mon sens. Il faudrait, au moins, introduire des réplications asynchrone intelligentes, un peu dans le genre de Lotus Notes.
Et puis, il est difficile de prendre en compte les sources, s'ils ne sont pas ASCII. Pas facile d'associer des documents externes au PAQL.
Etc.
Bref, j'ai ressenti ça comme une limitation à la créativité du développement, et à une lourdeur non compensée par les aspects positifs.
Ceci dit, dans certaines SSII "à l'ancienne", ça doit être intéressant.
@-salutations
Michel Claveau
Christophe Cavalaria
Do Re Mi chel La Si Do wrote:
Bonsoir !
J'ai un avis qui va dans une autre direction.
J'avais voulu essayer subversion. Mais, je me suis vite rendu compte que cet outil, est, en fait très structurant. Il impose une architecture, des façons de travailler, des méthodes de développement. Sans le dire.
Et, (malheureusement ?) cela était incompatible avec les projets sur lesquels j'avais voulu tester. En pratique, la moitié des postes n'avaient pas à Internet, ou à du FTP (alors, WebDav ...).
Comment faire du travail collaboratif à travers Internet, sans accès Internet ?
Sinon, pour les machines qui n'ont pas un accès permanent ou quasi permanent à Internet, il y a par exemple le projet SVK : http://svk.elixus.org/ C'est une surcouche au dessus de Subversion qui permet une organisation distribuée. Bazaar-ng est aussi un système distribué. Tu peux travailler sur ta version locale comme si tu avais accès au serveur principal sauf que tu ne peux pas récupérer les changements des autres bien sur. Quand tu as un accès au serveur principal, alors tu n'as plus qu'à récupérer les changements et envoyer les tiens. Très pratiques pour ceux qui veulent travailler dans le train par exemple.
De plus, ces projets tiennent compte de la configuration de chaque poste. Y compris jusqu'au système.
Je ne comprend pas ce que tu veux dire par la ?
Cela faisait beaucoup choses qui ne pouvaient pas être pris en compte, ou pas traités de façon complète. Le principe du client-serveur synchrone est déjà trop restrictif, à mon sens. Il faudrait, au moins, introduire des réplications asynchrone intelligentes, un peu dans le genre de Lotus Notes.
Bazaar est entièrement distribué si je ne m'abuse. Il n'y a pas de serveur central, mais souvent, par convention on décide d'un ordinateur principal. C'est quand même pratique d'avoir un point central ou mettre en commun tous les changements et pour que les gens extérieurs puissent suivre le projet.
Et puis, il est difficile de prendre en compte les sources, s'ils ne sont pas ASCII. Pas facile d'associer des documents externes au PAQL.
Ce problème est un problème classique. Si certains documents ne sont pas en texte, il est impossible de travailler à plusieurs dessus.
Etc.
Bref, j'ai ressenti ça comme une limitation à la créativité du développement, et à une lourdeur non compensée par les aspects positifs.
Au contraire, c'est un atout indéniable, même si tu es seul sur un projet. Essaye un jour pour voir tu ne pourras plus t'en passer, surtout si ton projet s'étale sur plusieurs semaines.
Ceci dit, dans certaines SSII "à l'ancienne", ça doit être intéressant.
Les système de gestion de conf/version sont l'avenir ( et même le présent ). Ne pas en utiliser c'est comme l'âge de pierre du développement informatique.
Do Re Mi chel La Si Do wrote:
Bonsoir !
J'ai un avis qui va dans une autre direction.
J'avais voulu essayer subversion. Mais, je me suis vite rendu compte que
cet outil, est, en fait très structurant. Il impose une architecture, des
façons de travailler, des méthodes de développement. Sans le dire.
Et, (malheureusement ?) cela était incompatible avec les projets sur
lesquels j'avais voulu tester. En pratique, la moitié des postes
n'avaient pas à Internet, ou à du FTP (alors, WebDav ...).
Comment faire du travail collaboratif à travers Internet, sans accès
Internet ?
Sinon, pour les machines qui n'ont pas un accès permanent ou quasi permanent
à Internet, il y a par exemple le projet SVK : http://svk.elixus.org/ C'est
une surcouche au dessus de Subversion qui permet une organisation
distribuée. Bazaar-ng est aussi un système distribué. Tu peux travailler
sur ta version locale comme si tu avais accès au serveur principal sauf que
tu ne peux pas récupérer les changements des autres bien sur. Quand tu as
un accès au serveur principal, alors tu n'as plus qu'à récupérer les
changements et envoyer les tiens. Très pratiques pour ceux qui veulent
travailler dans le train par exemple.
De plus, ces projets tiennent compte de la configuration de chaque poste.
Y compris jusqu'au système.
Je ne comprend pas ce que tu veux dire par la ?
Cela faisait beaucoup choses qui ne pouvaient pas être pris en compte, ou
pas traités de façon complète. Le principe du client-serveur synchrone
est déjà trop restrictif, à mon sens. Il faudrait, au moins, introduire
des réplications asynchrone intelligentes, un peu dans le genre de Lotus
Notes.
Bazaar est entièrement distribué si je ne m'abuse. Il n'y a pas de serveur
central, mais souvent, par convention on décide d'un ordinateur principal.
C'est quand même pratique d'avoir un point central ou mettre en commun tous
les changements et pour que les gens extérieurs puissent suivre le projet.
Et puis, il est difficile de prendre en compte les sources, s'ils ne sont
pas ASCII. Pas facile d'associer des documents externes au PAQL.
Ce problème est un problème classique. Si certains documents ne sont pas en
texte, il est impossible de travailler à plusieurs dessus.
Etc.
Bref, j'ai ressenti ça comme une limitation à la créativité du
développement, et à une lourdeur non compensée par les aspects positifs.
Au contraire, c'est un atout indéniable, même si tu es seul sur un projet.
Essaye un jour pour voir tu ne pourras plus t'en passer, surtout si ton
projet s'étale sur plusieurs semaines.
Ceci dit, dans certaines SSII "à l'ancienne", ça doit être intéressant.
Les système de gestion de conf/version sont l'avenir ( et même le présent ).
Ne pas en utiliser c'est comme l'âge de pierre du développement
informatique.
J'avais voulu essayer subversion. Mais, je me suis vite rendu compte que cet outil, est, en fait très structurant. Il impose une architecture, des façons de travailler, des méthodes de développement. Sans le dire.
Et, (malheureusement ?) cela était incompatible avec les projets sur lesquels j'avais voulu tester. En pratique, la moitié des postes n'avaient pas à Internet, ou à du FTP (alors, WebDav ...).
Comment faire du travail collaboratif à travers Internet, sans accès Internet ?
Sinon, pour les machines qui n'ont pas un accès permanent ou quasi permanent à Internet, il y a par exemple le projet SVK : http://svk.elixus.org/ C'est une surcouche au dessus de Subversion qui permet une organisation distribuée. Bazaar-ng est aussi un système distribué. Tu peux travailler sur ta version locale comme si tu avais accès au serveur principal sauf que tu ne peux pas récupérer les changements des autres bien sur. Quand tu as un accès au serveur principal, alors tu n'as plus qu'à récupérer les changements et envoyer les tiens. Très pratiques pour ceux qui veulent travailler dans le train par exemple.
De plus, ces projets tiennent compte de la configuration de chaque poste. Y compris jusqu'au système.
Je ne comprend pas ce que tu veux dire par la ?
Cela faisait beaucoup choses qui ne pouvaient pas être pris en compte, ou pas traités de façon complète. Le principe du client-serveur synchrone est déjà trop restrictif, à mon sens. Il faudrait, au moins, introduire des réplications asynchrone intelligentes, un peu dans le genre de Lotus Notes.
Bazaar est entièrement distribué si je ne m'abuse. Il n'y a pas de serveur central, mais souvent, par convention on décide d'un ordinateur principal. C'est quand même pratique d'avoir un point central ou mettre en commun tous les changements et pour que les gens extérieurs puissent suivre le projet.
Et puis, il est difficile de prendre en compte les sources, s'ils ne sont pas ASCII. Pas facile d'associer des documents externes au PAQL.
Ce problème est un problème classique. Si certains documents ne sont pas en texte, il est impossible de travailler à plusieurs dessus.
Etc.
Bref, j'ai ressenti ça comme une limitation à la créativité du développement, et à une lourdeur non compensée par les aspects positifs.
Au contraire, c'est un atout indéniable, même si tu es seul sur un projet. Essaye un jour pour voir tu ne pourras plus t'en passer, surtout si ton projet s'étale sur plusieurs semaines.
Ceci dit, dans certaines SSII "à l'ancienne", ça doit être intéressant.
Les système de gestion de conf/version sont l'avenir ( et même le présent ). Ne pas en utiliser c'est comme l'âge de pierre du développement informatique.
Encolpe Degoute
Comment faire du travail collaboratif à travers Internet, sans accès Internet ?
Sinon, pour les machines qui n'ont pas un accès permanent ou quasi permanent à Internet, il y a par exemple le projet SVK : http://svk.elixus.org/ C'est une surcouche au dessus de Subversion qui permet une organisation distribuée.
C'est amusant svk: une surcouche PERL d'un logiciel Python. Les mongueurs ont vraiment du temps libre.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Comment faire du travail collaboratif à travers Internet, sans accès
Internet ?
Sinon, pour les machines qui n'ont pas un accès permanent ou quasi permanent
à Internet, il y a par exemple le projet SVK : http://svk.elixus.org/ C'est
une surcouche au dessus de Subversion qui permet une organisation
distribuée.
C'est amusant svk:
une surcouche PERL d'un logiciel Python.
Les mongueurs ont vraiment du temps libre.
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Comment faire du travail collaboratif à travers Internet, sans accès Internet ?
Sinon, pour les machines qui n'ont pas un accès permanent ou quasi permanent à Internet, il y a par exemple le projet SVK : http://svk.elixus.org/ C'est une surcouche au dessus de Subversion qui permet une organisation distribuée.
C'est amusant svk: une surcouche PERL d'un logiciel Python. Les mongueurs ont vraiment du temps libre.
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
