[traduction]Qu'est ce que c'est que ce "bazaar"? ;)

Do Re Mi chel La Si Do wrote:

J'ai un avis qui va dans une autre direction.

Sur quoi et dans quelle direction ?
(Je suis d'accord pour ne pas systématiquement citer tout le message
auquel on répond, mais un minimum de contexte est vraiment le bienvenu.)

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.

Ça, c'est peut-être un défaut de subversion, mais pas des gestionnaires
de version en général.

Le principe du gestionnaire de version n'est pas intrinsèquement basé
sur une architecture client-serveur. Bazaar (mais aussi Arch, darcs et
sûrement bien d'autres) sont de tels outils décentralisés.
Si vous êtes intéressés, l'introduction à bzr ([1]), par exemple, donne
une idée générale de ce dont il s'agit.

Mais, en particulier, il n'y a pas besoin d'être en permanence sur
internet ou d'avoir des serveurs ftp pour utiliser un gestionnaire de
versions. On peut enregistrer ses changements localement pour
éventuellement les publier (par mail, serveur web, ssh, tout ce qu'on
veut) plus tard. Et on garde l'avantage d'avoir un historique, de faire
des branches et tout ce qui s'en suit.

Il faudrait, au moins, introduire des
réplications asynchrone intelligentes, un peu dans le genre de Lotus Notes.

Je ne connais pas Lotus Notes, et je ne sais pas ce qu'est une
réplication asynchrone intelligente. Mais s'il s'agit de pouvoir
enregistrer chez soi des changements pour les répliquer plus tard
ailleurs, ça existe déja (et c'est ce dont on parle).


Évidemment, c'est comme beaucoup d'outils : ça n'est pas toujours utile
et quand ça l'est, ça n'est pas forcément strictement indispensable. ;)


[1] http://bazaar.canonical.com/IntroductionToBzr

Encolpe Degoute wrote:

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.

Subversion n'est pas en Python. C'est entièrement du C ( ou du C++ )

Bonsoir !

Comment faire du travail collaboratif à travers Internet, sans accès
Internet ?

Tout les développements ne se font pas avec (la présence) Internet. En
gestion de production, par exemple, il n'y a aucun intérêt, pour de nombreux
postes, à être connecté à Internet. D'ailleurs, sur plusieurs installs, on a
mis ça sur un VLan, pour isoler le sous-réseau.
Les problèmes de télé-maintenance ont été résolus par uns passerelle (ou
répéteur, selon les logiciels).

...il y a par exemple le projet SVK

J'ai regardé. Premier problème, ce n'est pas en français.
Ensuite, j'ai lu : "...from local to remote repository if there's no
conflict..." Mais, s'il y a conflit, que se passe-t'il ?

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 ?

Par exemple, il arrive que je gère les paramètres du BIOS, dans les applis.
Difficile de gérer ça de façon intégrée.

Bazaar est entièrement distribué si je ne m'abuse.

Les systèmes distribués, c'est la bonne solution, si les canaux de
distribution sont variés, et maîtrisables. Trop souvent, ils sont imposés,
et on a guère de choix. C'est ce problème qui a d'ailleurs freiné le
développement des SGBD massivement distribués (ou hiérarchiquement
distribués, comme les SGBD "flocons de neige").

Si certains documents ne sont pas en texte, il est impossible de
travailler à plusieurs dessus.

Et pourtant, en pratique, il le faut bien.

surtout si ton projet s'étale sur plusieurs semaines.

La durée moyenne de mes projets, est d'un an. Avec un autre pic, sur
l'éternel (projets permanents, certains ont plus de vingt ans, et sont en
développement perpétuel).

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.

Possible. Mais, je pense qu'il y a un avenir pour les méthodes de
développement à itération ultra-courtes (genre "liquid computing") ; voire
sans itérations (développement simultané à l'utilisation). Je travaille, à
mes moments perdus, sur ça.
Mais je manque de moments perdus....



@-salutations

Michel Claveau

Bonsoir !

Je ne connais pas Lotus Notes, et je ne sais pas ce qu'est une
réplication asynchrone intelligente.

Pour simplifier, disons que Lotus Notes, c'est gros, c'est lourd, c'est
aussi gros, et lourd, et même très lourd.
Mais, Lorsque des postes nomades ont travaillé, et se rebranchent, même
temporairement, la réplication est automatique. Seules les modifications
sont échangées (et répercutées plus tard, sur les autres postes). Ce qui est
impressionnant, c'est de voir ce qui se passe, lorsque plusieurs postes non
connectés ont modifié la même partie d'un document (les différentes versions
sont conservées, avec un classement par utilisateur/chrono). De même si une
partie de document a été supprimée, et, simultanément, utilisée par un
poste, il est possible de se positionner sur n'importe quel point de regard.

Mais, qu'est-ce que c'est lourd !

http://bazaar.canonical.com/IntroductionToBzr

J'ai voulu regarder, mais ce n'est pas en français, ni en occitan. J'ai cru
à du breton (Bzr), mais je ne parle pas le breton.

D'après ce que j'en ai compris, la structure a l'air intéressante.

Par contre, ça me semble très orienté "texte ASCII a laisser le plus figé
possible". J'ai l'impression qu'une simple inversion de deux fonctions
(dans le but, limité, de changer l'ordre d'apparition dans une doc), ne sera
pas distinguée d'une modification fonctionnelle.
Cela peut s'avérer gênant, si les revues de code sont nombreuses.



@-salutations

Michel Claveau

On 13-12-2005, 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 ...).
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.

Soit t'es entrain d'essayer de reveiller un animal poilu alors qu'on est
à peine mercredi, soit explique nous ce que tu entends par "à
l'ancienne".

D'après ce que je lis au dessus, je comprend qu'aujourd'hui les
développeurs n'architecturent pas leur développement et n'ont aucune
méthode pour le faire, cela semble venir d'après toi d'une part du fait
qu'ils n'arrivent pas à configurer leur réseau ni leur poste et d'autre
part du fait qu'ils ont des problèmes avec leurs sources, sûrement géré
dans un format propriétaire. De plus ils n'arrivent pas à gérer leur
scan de postits où le cahier des charges est marqué. Et ça c'est
vraiment limitant alors qu'ils ont un scanner dernier cri sans fil et
tout.

En revanche ceux qui travaillent "à l'ancienne", c'est à dire en
profitant de la maturité des méthodes de développement qui ont fait
leur preuve, avec la rigueur des artisants d'antan qui construisaient
des maisons qui durent des siècles. Ceux qui commencent donc par
installer un système solide et fiable qui fonctionne parfaitement en
réseau, et utilisent des outils qu'ils maitrisent sur le bout des doigts
depuis 15 ans dont le format d'enregistrement n'a rien à cacher. Ceux là
lisent la documentation du gestionaire de version qui leur convient et
l'utilisent immédiatement avec d'autres développeurs du monde entier qui
suivent les mêmes principes.
Et donc tu disais que pour ceux-là c'est très intéressant, ils arrivent
à faire seul ou à plusieurs éparpillés dans le monde ce que n'arrive
toujours pas à faire une petite équipe de djeunz branchés dans le même
bureau surchauffé.

halala...

--
William Dodé - http://flibuste.net

On Wed, 14 Dec 2005 00:47:20 +0100, Do Re Mi chel La Si Do <enleverlesO.OmcO@OmclaveauO.com> wrote:

J'ai voulu regarder, mais ce n'est pas en français, ni en occitan. J'ai cru
à du breton (Bzr), mais je ne parle pas le breton.

C'est Bzh, le breton, pas Bzr... Une faute de frappe peut-être?

Kenavo ar c'hentañ!
--
python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17;8(%,5.Z65'*9--56l7+-'])"

On Wed, 14 Dec 2005 09:22:17 +0100, Eric Brunel <eric_brunel@despammed.com> wrote:
Aaaargh!

Kenavo ar c'hentañ!
Il fallait lire:

Kenavo ar c'hentañ!
bien sûr (saleté de clavier...)
--
python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17;8(%,5.Z65'*9--56l7+-'])"

Salut, je viens d'installer bazaar, mais il n'a pas l'air de
fonctionner. j'ai l'erreur suivante:
il n'existe pas d'interface graphique pour bazaar parceque travailler
sur console sous winxp c'est carrement gonflant...
A++


Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.


C:Documents and SettingsJean-LucBureautraduc>dir
Le volume dans le lecteur C n'a pas de nom.
Le numéro de série du volume est C08B-1B4C

Répertoire de C:Documents and SettingsJean-LucBureautraduc

2005-12-14 00:01 <REP> .
2005-12-14 00:01 <REP> ..
2005-12-14 01:13 7 838 libjepgFR.tex
2005-12-13 23:35 3 218 libjpeg.tex
2005-12-13 23:59 10 794 preparetex.py
3 fichier(s) 21 850 octets
2 Rép(s) 4 885 131 264 octets libres

C:Documents and SettingsJean-LucBureautraduc>bzr init pythonfr
No handlers could be found for logger "bzr"
Traceback (most recent call last):
File "C:Python24Scriptsbzr", line 63, in ?
bzrlib.trace.enable_default_logging()
File "C:Python24Libsite-packagesbzrlibtrace.py", line 214, in
enable_defa
ult_logging
_file_handler.setLevel(level)
AttributeError: 'NoneType' object has no attribute 'setLevel'

Bonsoir !

Comment faire du travail collaboratif à travers Internet, sans accès
Internet ?

Tout les développements ne se font pas avec (la présence) Internet. En
gestion de production, par exemple, il n'y a aucun intérêt, pour de nombreux
postes, à être connecté à Internet. D'ailleurs, sur plusieurs installs, on a
mis ça sur un VLan, pour isoler le sous-réseau.
Les problèmes de télé-maintenance ont été résolus par uns passerelle (ou
répéteur, selon les logiciels).

Tout ce qu'il faut pour travailler avec un système de gestion de conf,
c'est un accès régulier au serveur central. Pour un projet d'entreprise,
évidement qu'il n'y a pas besoin d'internet.

...il y a par exemple le projet SVK

J'ai regardé. Premier problème, ce n'est pas en français.
Ensuite, j'ai lu : "...from local to remote repository if there's no
conflict..." Mais, s'il y a conflit, que se passe-t'il ?

S'il y a conflit, il se passe deux choses : la première c'est qu'il faut
arreter de travailler à plusieurs en même sur les mêmes lignes de code.
La deuxième c'est que c'est à l'utilisateur humain de prendre le conflit
et de le résoudre.

Un conflit ce n'est rien de plus qu'une situation ou l'outil ne peux pas
faire l'intégration de tes changements de façon automatique.

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 ?

Par exemple, il arrive que je gère les paramètres du BIOS, dans les applis.
Difficile de gérer ça de façon intégrée.

Je ne comprends toujours pas ce que tu veux dire ? Que viens faire le
BIOS dans cette affaire ? On parle ici d'un outil de travail colaboratif
sur des fichiers textes.

Bazaar est entièrement distribué si je ne m'abuse.

Les systèmes distribués, c'est la bonne solution, si les canaux de
distribution sont variés, et maîtrisables. Trop souvent, ils sont imposés,
et on a guère de choix. C'est ce problème qui a d'ailleurs freiné le
développement des SGBD massivement distribués (ou hiérarchiquement
distribués, comme les SGBD "flocons de neige").

C'est un projet opensource, si les canaux de distribution fournis ne te
plaisent pas, il te suffit de coder ce qui te manque ou de demander à qq
de le faire :)

Si certains documents ne sont pas en texte, il est impossible de
travailler à plusieurs dessus.

Et pourtant, en pratique, il le faut bien.

Tu n'as pas compris. Si il n'y a pas de solution technique permetant à
plusieures personnes de travailler en même temps sur un fichier, alors
ils ne peuvent pas le faire point ! Les systèmes de gestion de conf
standards fournissent les outils pour travailler à plusieurs sur des
fichiers texte parceque c'est le plus facile à faire. Et ce n'est pas
facile du tout ! Surtout quand tu commences à parler en terme de
branche, de merge etc ...

surtout si ton projet s'étale sur plusieurs semaines.

La durée moyenne de mes projets, est d'un an. Avec un autre pic, sur
l'éternel (projets permanents, certains ont plus de vingt ans, et sont en
développement perpétuel).

J'aurais du dire plusieures semaines ou plus alors :)

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.

Possible. Mais, je pense qu'il y a un avenir pour les méthodes de
développement à itération ultra-courtes (genre "liquid computing") ; voire
sans itérations (développement simultané à l'utilisation). Je travaille, à
mes moments perdus, sur ça.
Mais je manque de moments perdus....

Sans doute. En quoi cela pose problème pour utiliser un outils de
gestion de conf ? Cela n'a rien à voir.



On va reprendre depuis le début. A quoi sert un système de gestion de
conf ? Cela sert à 3 choses uniquement :
- se souvenir de l'historique de tous les changements qui ont été fait
de manière à toujours pouvoir revenir aux version antérieures et
toujours pouvoir comprendre pourquoi un chagement a été fait
- gérer plusieures versions différentes en même temps et faciliter la
recopie de changements d'une version à l'autre. Cas d'usage classique :
un projet qui livre une version stable et qui continue à déveloper la
prochaine version. Si des bugs apparaissent dans la version stable, il
suffit de corriger et de temps en temps, tu merge tous les chagements
fait dans la version de developement pour ne pas avoir à corriger les
bugs 2 fois. Ou inversement, si un bug est découvert dans la version
stable et qu'il est déjà corrigé dans la version de dev, il est possible
d'extraire la correction de bug pour l'appliquer sur la version stable.
- travailler à plusieur sur une base de données. Suivant la puissance du
système il y a 2 niveaux possibles :
* chacun son fichier. Niveau le plus bas mais certaines personnes
pensent que c'est la bonne façon de faire de toute façon.
* plusieures personnes sur des fichiers de type bien précis. Dans ce
cas, c'est plusieures personnes peuvent modifier en même temps un
fichier texte du moment qu'ils ne font pas de modifs trop proches les
unes des autres.
* liberté complète. Pratiquement impossible à faire car il faut coder
le support pour chaque type de fichier.

Bonsoir,
Christophe wrote:

Bonsoir !

Comment faire du travail collaboratif à travers Internet, sans
accès Internet ?

Tout les développements ne se font pas avec (la présence) Internet. En
gestion de production, par exemple, il n'y a aucun intérêt, pour de
nombreux postes, à être connecté à Internet. D'ailleurs, sur plusieurs
installs, on a mis ça sur un VLan, pour isoler le sous-réseau.
Les problèmes de télé-maintenance ont été résolus par uns passerelle
(ou répéteur, selon les logiciels).

Tout ce qu'il faut pour travailler avec un système de gestion de conf,
c'est un accès régulier au serveur central. Pour un projet d'entreprise,
évidement qu'il n'y a pas besoin d'internet.

...il y a par exemple le projet SVK

J'ai regardé. Premier problème, ce n'est pas en français.
Ensuite, j'ai lu : "...from local to remote repository if there's no
conflict..." Mais, s'il y a conflit, que se passe-t'il ?

S'il y a conflit, il se passe deux choses : la première c'est qu'il faut
arreter de travailler à plusieurs en même sur les mêmes lignes de code.
La deuxième c'est que c'est à l'utilisateur humain de prendre le conflit
et de le résoudre.

Un conflit ce n'est rien de plus qu'une situation ou l'outil ne peux pas
faire l'intégration de tes changements de façon automatique.

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 ?

Par exemple, il arrive que je gère les paramètres du BIOS, dans les
applis. Difficile de gérer ça de façon intégrée.

Je ne comprends toujours pas ce que tu veux dire ? Que viens faire le
BIOS dans cette affaire ? On parle ici d'un outil de travail colaboratif
sur des fichiers textes.

Bazaar est entièrement distribué si je ne m'abuse.

Les systèmes distribués, c'est la bonne solution, si les canaux de
distribution sont variés, et maîtrisables. Trop souvent, ils sont
imposés, et on a guère de choix. C'est ce problème qui a d'ailleurs
freiné le développement des SGBD massivement distribués (ou
hiérarchiquement distribués, comme les SGBD "flocons de neige").

C'est un projet opensource, si les canaux de distribution fournis ne te
plaisent pas, il te suffit de coder ce qui te manque ou de demander à qq
de le faire :)

Si certains documents ne sont pas en texte, il est impossible de
travailler à plusieurs dessus.

Et pourtant, en pratique, il le faut bien.

Tu n'as pas compris. Si il n'y a pas de solution technique permetant à
plusieures personnes de travailler en même temps sur un fichier, alors
ils ne peuvent pas le faire point ! Les systèmes de gestion de conf
standards fournissent les outils pour travailler à plusieurs sur des
fichiers texte parceque c'est le plus facile à faire. Et ce n'est pas
facile du tout ! Surtout quand tu commences à parler en terme de
branche, de merge etc ...

surtout si ton projet s'étale sur plusieurs semaines.

La durée moyenne de mes projets, est d'un an. Avec un autre pic, sur
l'éternel (projets permanents, certains ont plus de vingt ans, et
sont en développement perpétuel).

J'aurais du dire plusieures semaines ou plus alors :)

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.

Possible. Mais, je pense qu'il y a un avenir pour les méthodes de
développement à itération ultra-courtes (genre "liquid computing") ;
voire sans itérations (développement simultané à l'utilisation). Je
travaille, à mes moments perdus, sur ça.
Mais je manque de moments perdus....

Sans doute. En quoi cela pose problème pour utiliser un outils de
gestion de conf ? Cela n'a rien à voir.



On va reprendre depuis le début. A quoi sert un système de gestion de
conf ? Cela sert à 3 choses uniquement :
- se souvenir de l'historique de tous les changements qui ont été fait
de manière à toujours pouvoir revenir aux version antérieures et
toujours pouvoir comprendre pourquoi un chagement a été fait
- gérer plusieures versions différentes en même temps et faciliter la
recopie de changements d'une version à l'autre. Cas d'usage classique :
un projet qui livre une version stable et qui continue à déveloper la
prochaine version. Si des bugs apparaissent dans la version stable, il
suffit de corriger et de temps en temps, tu merge tous les chagements
fait dans la version de developement pour ne pas avoir à corriger les
bugs 2 fois. Ou inversement, si un bug est découvert dans la version
stable et qu'il est déjà corrigé dans la version de dev, il est possible
d'extraire la correction de bug pour l'appliquer sur la version stable.
- travailler à plusieur sur une base de données. Suivant la puissance du
système il y a 2 niveaux possibles :
* chacun son fichier. Niveau le plus bas mais certaines personnes
pensent que c'est la bonne façon de faire de toute façon.
* plusieures personnes sur des fichiers de type bien précis. Dans ce
cas, c'est plusieures personnes peuvent modifier en même temps un
fichier texte du moment qu'ils ne font pas de modifs trop proches les
unes des autres.
* liberté complète. Pratiquement impossible à faire car il faut coder
le support pour chaque type de fichier.
J'ajouterais une 4ème chose : sécuriser l'utilisation des sources.

Pour revenir au 3ème point, CVS gère très bien les conflits de modifs
sur des lignes identiques. Je me demande bien pourquoi les outils plus
modernes ne le feraient pas (c'est pourtant pas sorcier...)
A+
jm