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

Christophe Cavalaria

15/12/2005 à 01:07

jean-michel bain-cornu wrote:

J'ajouterais une 4ème chose : sécuriser l'utilisation des sources.

Oui aussi.

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...)

C'est pas sorcier ? On n'a pas du utiliser le même CVS alors :) De toute
façon, par définition un conflit c'est quand l'outil ne peux plus rien
faire alors je ne vois vraiment pas de quoi tu parles.

Do Re Mi chel La Si Do

15/12/2005 à 03:05

Bonsoir !

un animal poilu...

Les trolls seraient-ils d'origine portugaise ?

sources, sûrement géré dans un format propriétaire

Ben oui, tu as vu juste, c'est un élément fréquent.

leur scan de post-its où le cahier des charges est marqué

Là aussi, tu as vu juste.

Mais, bon, c'est quand même le client qui dirige. Sauf à se payer le luxe de
pouvoir rejeter des clients (j'ai vu ça dans l'informatique publique, mais
jamais dans le privé).

Bonne nuit.

MCI

jean-michel bain-cornu

15/12/2005 à 08:55

Christophe Cavalaria wrote:

jean-michel bain-cornu wrote:

J'ajouterais une 4ème chose : sécuriser l'utilisation des sources.

Oui aussi.

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...)

C'est pas sorcier ? On n'a pas du utiliser le même CVS alors :) De toute
façon, par définition un conflit c'est quand l'outil ne peux plus rien
faire alors je ne vois vraiment pas de quoi tu parles.

Très simple.
Quand tu fais un update et qu'il il y a un conflit à un endroit dans un
source, tu récupères ta modif et celle de l'autre programmeur avec un
caractère '>' ou '<' en marge qui te permet de savoir qui a codé la
ligne. A toi de décider (évidemment !) ce qu'il faut garder (et de faire
un commit). Et si j'ai bonne mémoire, si les deux modifs sont
identiques, pas de conflit.
A+
jm

Pour info:
----------------------------------------------------
Section A.17.2 de la doc :
A conflict was detected while trying to merge your changes to file with
changes from the source repository. file (the copy in your working
directory) is now the result of attempting to merge the two revisions;
an unmodified copy of your file is also in your working directory, with
the name `.#file.revision' where revision is the revision that your
modified file started from. Resolve the conflict as described in
Conflicts example. (Note that some systems automatically purge files
that begin with `.#' if they have not been accessed for a few days. If
you intend to keep a copy of your original file, it is a very good idea
to rename it.) Under VMS, the file name starts with `__' rather than `.#'.

----------------------------------------------------
Section 10.3 Conflicts example

Suppose revision 1.4 of `driver.c' contains this:

#include <stdio.h>

void main()
{
parse();
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? 0 : 1);
}

Revision 1.6 of `driver.c' contains this:

#include <stdio.h>

int main(int argc,
char **argv)
{
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(!!nerr);
}

Your working copy of `driver.c', based on revision 1.4, contains this
before you run `cvs update':

#include <stdlib.h>
#include <stdio.h>

void main()
{
init_scanner();
parse();
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

You run `cvs update':

$ cvs update driver.c
RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
retrieving revision 1.4
retrieving revision 1.6
Merging differences between 1.4 and 1.6 into driver.c
rcsmerge warning: overlaps during merge
cvs update: conflicts found in driver.c
C driver.c

CVS tells you that there were some conflicts. Your original working file
is saved unmodified in `.#driver.c.1.4'. The new version of `driver.c'
contains this:

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
<<<<<<< driver.c
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
====== exit(!!nerr);

1.6
}

Note how all non-overlapping modifications are incorporated in your
working copy, and that the overlapping section is clearly marked with
`<<<<<<<', `=======' and `>>>>>>>'.

You resolve the conflict by editing the file, removing the markers and
the erroneous line. Suppose you end up with this file:

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

You can now go ahead and commit this as revision 1.7.

$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
Checking in driver.c;
/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
new revision: 1.7; previous revision: 1.6
done

For your protection, CVS will refuse to check in a file if a conflict
occurred and you have not resolved the conflict. Currently to resolve a
conflict, you must change the timestamp on the file. In previous
versions of CVS, you also needed to insure that the file contains no
conflict markers. Because your file may legitimately contain conflict
markers (that is, occurrences of `>>>>>>> ' at the start of a line that
don't mark a conflict), the current version of CVS will print a warning
and proceed to check in the file.

If you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end for
CVS) you can use an Emacs package called emerge to help you resolve
conflicts. See the documentation for pcl-cvs.

Christophe Cavalaria wrote:

jean-michel bain-cornu wrote:

J'ajouterais une 4ème chose : sécuriser l'utilisation des sources.

Oui aussi.

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...)

C'est pas sorcier ? On n'a pas du utiliser le même CVS alors :) De toute
façon, par définition un conflit c'est quand l'outil ne peux plus rien
faire alors je ne vois vraiment pas de quoi tu parles.

Très simple.
Quand tu fais un update et qu'il il y a un conflit à un endroit dans un
source, tu récupères ta modif et celle de l'autre programmeur avec un
caractère '>' ou '<' en marge qui te permet de savoir qui a codé la
ligne. A toi de décider (évidemment !) ce qu'il faut garder (et de faire
un commit). Et si j'ai bonne mémoire, si les deux modifs sont
identiques, pas de conflit.
A+
jm

Pour info:
----------------------------------------------------
Section A.17.2 de la doc :
A conflict was detected while trying to merge your changes to file with
changes from the source repository. file (the copy in your working
directory) is now the result of attempting to merge the two revisions;
an unmodified copy of your file is also in your working directory, with
the name `.#file.revision' where revision is the revision that your
modified file started from. Resolve the conflict as described in
Conflicts example. (Note that some systems automatically purge files
that begin with `.#' if they have not been accessed for a few days. If
you intend to keep a copy of your original file, it is a very good idea
to rename it.) Under VMS, the file name starts with `__' rather than `.#'.

----------------------------------------------------
Section 10.3 Conflicts example

Suppose revision 1.4 of `driver.c' contains this:

#include <stdio.h>

void main()
{
parse();
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? 0 : 1);
}

Revision 1.6 of `driver.c' contains this:

#include <stdio.h>

int main(int argc,
char **argv)
{
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(!!nerr);
}

Your working copy of `driver.c', based on revision 1.4, contains this
before you run `cvs update':

#include <stdlib.h>
#include <stdio.h>

void main()
{
init_scanner();
parse();
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

You run `cvs update':

$ cvs update driver.c
RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
retrieving revision 1.4
retrieving revision 1.6
Merging differences between 1.4 and 1.6 into driver.c
rcsmerge warning: overlaps during merge
cvs update: conflicts found in driver.c
C driver.c

CVS tells you that there were some conflicts. Your original working file
is saved unmodified in `.#driver.c.1.4'. The new version of `driver.c'
contains this:

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
<<<<<<< driver.c
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
====== exit(!!nerr);

1.6
}

Note how all non-overlapping modifications are incorporated in your
working copy, and that the overlapping section is clearly marked with
`<<<<<<<', `=======' and `>>>>>>>'.

You resolve the conflict by editing the file, removing the markers and
the erroneous line. Suppose you end up with this file:

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

You can now go ahead and commit this as revision 1.7.

$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
Checking in driver.c;
/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
new revision: 1.7; previous revision: 1.6
done

For your protection, CVS will refuse to check in a file if a conflict
occurred and you have not resolved the conflict. Currently to resolve a
conflict, you must change the timestamp on the file. In previous
versions of CVS, you also needed to insure that the file contains no
conflict markers. Because your file may legitimately contain conflict
markers (that is, occurrences of `>>>>>>> ' at the start of a line that
don't mark a conflict), the current version of CVS will print a warning
and proceed to check in the file.

If you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end for
CVS) you can use an Emacs package called emerge to help you resolve
conflicts. See the documentation for pcl-cvs.

Vous avez filtré cet utilisateur ! Consultez son message

Christophe Cavalaria wrote:

jean-michel bain-cornu wrote:

J'ajouterais une 4ème chose : sécuriser l'utilisation des sources.

Oui aussi.

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...)

C'est pas sorcier ? On n'a pas du utiliser le même CVS alors :) De toute
façon, par définition un conflit c'est quand l'outil ne peux plus rien
faire alors je ne vois vraiment pas de quoi tu parles.

Très simple.
Quand tu fais un update et qu'il il y a un conflit à un endroit dans un
source, tu récupères ta modif et celle de l'autre programmeur avec un
caractère '>' ou '<' en marge qui te permet de savoir qui a codé la
ligne. A toi de décider (évidemment !) ce qu'il faut garder (et de faire
un commit). Et si j'ai bonne mémoire, si les deux modifs sont
identiques, pas de conflit.
A+
jm

Pour info:
----------------------------------------------------
Section A.17.2 de la doc :
A conflict was detected while trying to merge your changes to file with
changes from the source repository. file (the copy in your working
directory) is now the result of attempting to merge the two revisions;
an unmodified copy of your file is also in your working directory, with
the name `.#file.revision' where revision is the revision that your
modified file started from. Resolve the conflict as described in
Conflicts example. (Note that some systems automatically purge files
that begin with `.#' if they have not been accessed for a few days. If
you intend to keep a copy of your original file, it is a very good idea
to rename it.) Under VMS, the file name starts with `__' rather than `.#'.

----------------------------------------------------
Section 10.3 Conflicts example

Suppose revision 1.4 of `driver.c' contains this:

#include <stdio.h>

void main()
{
parse();
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? 0 : 1);
}

Revision 1.6 of `driver.c' contains this:

#include <stdio.h>

int main(int argc,
char **argv)
{
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(!!nerr);
}

Your working copy of `driver.c', based on revision 1.4, contains this
before you run `cvs update':

#include <stdlib.h>
#include <stdio.h>

void main()
{
init_scanner();
parse();
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

You run `cvs update':

$ cvs update driver.c
RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
retrieving revision 1.4
retrieving revision 1.6
Merging differences between 1.4 and 1.6 into driver.c
rcsmerge warning: overlaps during merge
cvs update: conflicts found in driver.c
C driver.c

CVS tells you that there were some conflicts. Your original working file
is saved unmodified in `.#driver.c.1.4'. The new version of `driver.c'
contains this:

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
<<<<<<< driver.c
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
====== exit(!!nerr);

1.6
}

Note how all non-overlapping modifications are incorporated in your
working copy, and that the overlapping section is clearly marked with
`<<<<<<<', `=======' and `>>>>>>>'.

You resolve the conflict by editing the file, removing the markers and
the erroneous line. Suppose you end up with this file:

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
fprintf(stderr, "tc: No args expected.n");
exit(1);
}
if (nerr == 0)
gencode();
else
fprintf(stderr, "No code generated.n");
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

You can now go ahead and commit this as revision 1.7.

$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
Checking in driver.c;
/usr/local/cvsroot/yoyodyne/tc/driver.c,v <-- driver.c
new revision: 1.7; previous revision: 1.6
done

For your protection, CVS will refuse to check in a file if a conflict
occurred and you have not resolved the conflict. Currently to resolve a
conflict, you must change the timestamp on the file. In previous
versions of CVS, you also needed to insure that the file contains no
conflict markers. Because your file may legitimately contain conflict
markers (that is, occurrences of `>>>>>>> ' at the start of a line that
don't mark a conflict), the current version of CVS will print a warning
and proceed to check in the file.

If you use release 1.04 or later of pcl-cvs (a GNU Emacs front-end for
CVS) you can use an Emacs package called emerge to help you resolve
conflicts. See the documentation for pcl-cvs.

William Dode

15/12/2005 à 09:10

On 13-12-2005, Do Re Mi chel La Si Do wrote:

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.

Ca ne va pas tarder, en attendant jettes un coup d'oeuil ici, c'est un
parent de bazaar (bazaar étant plus simple d'utilisation et impose moins
de contraintes sur les noms etc.)
http://flibuste.net/libre/tlafr

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.

Si ce sera traité comme une modification et distingué tout simplement
par le commentaire
bzr commit -m "réorganisation des fonctions"

Pourquoi chercher plus compliqué ?

Cela peut s'avérer gênant, si les revues de code sont nombreuses.

@-salutations

Michel Claveau

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

On 13-12-2005, Do Re Mi chel La Si Do wrote:

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.

Ca ne va pas tarder, en attendant jettes un coup d'oeuil ici, c'est un
parent de bazaar (bazaar étant plus simple d'utilisation et impose moins
de contraintes sur les noms etc.)
http://flibuste.net/libre/tlafr

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.

Si ce sera traité comme une modification et distingué tout simplement
par le commentaire
bzr commit -m "réorganisation des fonctions"

Pourquoi chercher plus compliqué ?

Cela peut s'avérer gênant, si les revues de code sont nombreuses.

@-salutations

Michel Claveau

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

Vous avez filtré cet utilisateur ! Consultez son message

William Dode

15/12/2005 à 10:03

On 15-12-2005, Do Re Mi chel La Si Do wrote:

Bonsoir !

un animal poilu...

Les trolls seraient-ils d'origine portugaise ?

sources, sûrement géré dans un format propriétaire

Ben oui, tu as vu juste, c'est un élément fréquent.

leur scan de post-its où le cahier des charges est marqué

Là aussi, tu as vu juste.

Mais, bon, c'est quand même le client qui dirige. Sauf à se payer le luxe de
pouvoir rejeter des clients (j'ai vu ça dans l'informatique publique, mais
jamais dans le privé).

Quand tu vas acheter du pain tu n'explique pas au boulanger comment il
doit pétrir sa farine, sinon tu le fais tout seul... Il n'y a donc pas à
rejeter un client mais à lui expliquer.

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

Christophe Cavalaria

15/12/2005 à 12:03

jean-michel bain-cornu wrote:

Christophe Cavalaria wrote:
jean-michel bain-cornu wrote:

J'ajouterais une 4ème chose : sécuriser l'utilisation des sources.

Oui aussi.

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...)

C'est pas sorcier ? On n'a pas du utiliser le même CVS alors :) De toute
façon, par définition un conflit c'est quand l'outil ne peux plus rien
faire alors je ne vois vraiment pas de quoi tu parles.

Très simple.
Quand tu fais un update et qu'il il y a un conflit à un endroit dans un
source, tu récupères ta modif et celle de l'autre programmeur avec un
caractère '>' ou '<' en marge qui te permet de savoir qui a codé la
ligne. A toi de décider (évidemment !) ce qu'il faut garder (et de faire
un commit). Et si j'ai bonne mémoire, si les deux modifs sont
identiques, pas de conflit.

Je sais bien ce qu'est un conflit. Pour moi, dire que CVS les gère est faux
car les conflits arrivent justement quand CVS ne sais plus quoi faire :)
Alors il pose la question à l'utilisateur.

Sur ce point, SVN fait beaucoup mieux les choses. Outre le fait que le
format de présentation du conflit est identique, il va aussi ajouter dans
le répertoire courant 3 fichiers ( plus ou moins suivant la situation ) :
- le fichier code.c.mine qui contient la version non modifiée avant update
- le fichier code.c.1234 qui contient la version que tu avais récupéré sur
l'update précedent
- le fichier code.c.1276 qui contient la version que tu as essayé de
récupérer sur le dernier update

Le fichier code.c sera modifié avec les marqueurs <<< et >>> comme pour CVS.
Tant que tu n'as pas effacé tous les fichiers en plus, il te refuse de
faire un commit.

En cas de fichier binaire, il y aura un fichier en moins. Si je me souviens
bien, code.c.mine ne sera pas présent et SVN aura laissé code.c non modifié

jean-michel bain-cornu wrote:

Christophe Cavalaria wrote:

jean-michel bain-cornu wrote:

J'ajouterais une 4ème chose : sécuriser l'utilisation des sources.

Oui aussi.

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...)

C'est pas sorcier ? On n'a pas du utiliser le même CVS alors :) De toute
façon, par définition un conflit c'est quand l'outil ne peux plus rien
faire alors je ne vois vraiment pas de quoi tu parles.

Très simple.
Quand tu fais un update et qu'il il y a un conflit à un endroit dans un
source, tu récupères ta modif et celle de l'autre programmeur avec un
caractère '>' ou '<' en marge qui te permet de savoir qui a codé la
ligne. A toi de décider (évidemment !) ce qu'il faut garder (et de faire
un commit). Et si j'ai bonne mémoire, si les deux modifs sont
identiques, pas de conflit.

Je sais bien ce qu'est un conflit. Pour moi, dire que CVS les gère est faux
car les conflits arrivent justement quand CVS ne sais plus quoi faire :)
Alors il pose la question à l'utilisateur.

Sur ce point, SVN fait beaucoup mieux les choses. Outre le fait que le
format de présentation du conflit est identique, il va aussi ajouter dans
le répertoire courant 3 fichiers ( plus ou moins suivant la situation ) :
- le fichier code.c.mine qui contient la version non modifiée avant update
- le fichier code.c.1234 qui contient la version que tu avais récupéré sur
l'update précedent
- le fichier code.c.1276 qui contient la version que tu as essayé de
récupérer sur le dernier update

Le fichier code.c sera modifié avec les marqueurs <<< et >>> comme pour CVS.
Tant que tu n'as pas effacé tous les fichiers en plus, il te refuse de
faire un commit.

En cas de fichier binaire, il y aura un fichier en moins. Si je me souviens
bien, code.c.mine ne sera pas présent et SVN aura laissé code.c non modifié

Vous avez filtré cet utilisateur ! Consultez son message

Do Re Mi chel La Si Do

15/12/2005 à 14:38

Bonjour !

Quand tu vas acheter du pain tu n'explique pas au boulanger comment il
doit ...

Alors, là, tu tombes mal (ou bien). Mon père était meunier. Et, de 8 ans à
20 ans, j'ai travaillé au moulin, durant les vacances scolaires, les
week-end, etc. (à 20 ans, j'ai découvert l'informatique).

Donc, question farine, j'en connais suffisamment pour expliquer bien des
choses aux vendeuses des boulangeries (aux vendeuses, hein, pas aux
boulangers. Eux, ils dorment dans la journée).

:-)

@+

MCI

Do Re Mi chel La Si Do

15/12/2005 à 15:00

Bonjour !

J'ai regardé, et lu, rapidement, mais complètement, le site que tu as
indiqué.

D'abord, merci pour le lien (et la traduction).

Ensuite, et bien, cela m'a confirmé dans les limites de ce genre d'outil. En
gros, on a un LOG des DIFF
Et les limites de DIFF (ou de FC sous windows) sont telles que j'ai fait mes
propres outils d'analyse des différences (de fichiers textes). Comme
beaucoup de monde, je suppose.

Bref, j'ai l'impression que cela ajoute de la lourdeur, sans couvrir assez
de besoins en contrepartie. Par exemple, pour gérer mes versions, j'ai un
outil (maison) qui réalise automatiquement le mise à jour des CD (jusqu'à
l'ISO), qui fait du FTP automatique, qui envoie des mails d'annonce (avec ou
sans pièces jointes). Autant de choses que je ne retrouve pas dans les
outils de gestion de version.

Déjà, mes logiciels étant allègrement multi-langages, et multi-outils, avec
des formats différents, y compris pour les sources, ça va accrocher dur,
avec TLA, SVC, Tortoise, subversion, et compagnie. J'avais essayé Proview
(pas les écrans, le gestionnaire de projets) ; mais, là aussi, ça ne m'avais
pas emballé.

Donc, pour l'instant, je me contente de mes scripts, en attendant de trouver
mieux, ou d'avoir le temps de faire un truc qui me convienne.

Néanmoins, merci encore pour ce lien en français.

@-salutations

Michel Claveau

Christophe Cavalaria

15/12/2005 à 15:42

Do Re Mi chel La Si Do wrote:

Bonjour !

J'ai regardé, et lu, rapidement, mais complètement, le site que tu as
indiqué.

D'abord, merci pour le lien (et la traduction).

Ensuite, et bien, cela m'a confirmé dans les limites de ce genre d'outil.
En gros, on a un LOG des DIFF
Et les limites de DIFF (ou de FC sous windows) sont telles que j'ai fait
mes propres outils d'analyse des différences (de fichiers textes). Comme
beaucoup de monde, je suppose.

Je doute fortement que beaucoup de monde se soit amusé à recoder diff juste
parcequ'il a des limitations ( léquelles d'ailleurs ? ). Sinon, je ferais
remarquer que bazaar-ng est plus qu'un simple log de differences. C'est
aussi un ensemble d'outils pour manipuler differentes branches et faciliter
la fusion des changements de plusieurs developeurs et/ou entre plusieurs
branches.

Bref, j'ai l'impression que cela ajoute de la lourdeur, sans couvrir assez
de besoins en contrepartie. Par exemple, pour gérer mes versions, j'ai un
outil (maison) qui réalise automatiquement le mise à jour des CD (jusqu'à
l'ISO), qui fait du FTP automatique, qui envoie des mails d'annonce (avec
ou sans pièces jointes). Autant de choses que je ne retrouve pas dans les
outils de gestion de version.

Ce n'est pas le rôle d'un outil de gestion de version de faire ça. C'est le
rôle d'un outils de packaging. Ce même outils de packaging doit bien être
codé un jour et peut profiter de la gestion de version.

Après, voici un exemple de comment livrer une version automatiquement avec
CVS :
cd repertoire_du_projet
cvs update
./packversion.sh

Et voila, c'était dur il faut bien dire.

A on me soufle qu'il suffit de commencer le script packversion.sh par la
commande "cvs update" pour économiser une étape. Et bien sur, il ne faut
pas oublier de mettre un CD vierge dans le lecteur sinon le programme de
gravure ne va pas pouvoir fonctionner.

Complexité du script ? Environ un 15aine de lignes maximum du moment que les
outils sont tous disponibles. Cela inclue bien sur l'envoit de mail,
l'upload sur FTP de l'installeur et le lancement du programme de gravure.

Déjà, mes logiciels étant allègrement multi-langages,

Je ne vois pas en quoi le fait que ça soit multi-langage pose un problème
quelconque.

et multi-outils,

Et alors ?

avec des formats différents, y compris pour les sources, ça va accrocher
dur,

Tu as du code source au format binaire maintenant ? Je croyais que tout
langage de programmation sérieux utilisait des fichiers texte.

avec TLA, SVC, Tortoise, subversion, et compagnie. J'avais essayé
Proview (pas les écrans, le gestionnaire de projets) ; mais, là aussi, ça
ne m'avais pas emballé.

TLA, SVN et BZR ne sont pas des outils de gestion de projet mais des outils
de gestion de code. Ne pas confondre. Proview a juste l'air d'être un IDE
qui date de l'époque de Win95 et qui n'a pas été mis à jour depuis ( du
moins ce que j'en ai trouvé sur google )

Donc, pour l'instant, je me contente de mes scripts, en attendant de
trouver mieux, ou d'avoir le temps de faire un truc qui me convienne.

C'est bien de critiquer les outils de gestion de version existant mais il
faudrait quand même savoir à quoi ils servent avant de dire que tes scripts
font bien le travail. Ceci car je te parle d'un outil qui gère les
changements dans le code et les différentes version des logiciels et tu me
parles d'un outil servant à compiler et packager une version.

Do Re Mi chel La Si Do wrote:

Bonjour !

J'ai regardé, et lu, rapidement, mais complètement, le site que tu as
indiqué.

D'abord, merci pour le lien (et la traduction).

Ensuite, et bien, cela m'a confirmé dans les limites de ce genre d'outil.
En gros, on a un LOG des DIFF
Et les limites de DIFF (ou de FC sous windows) sont telles que j'ai fait
mes propres outils d'analyse des différences (de fichiers textes). Comme
beaucoup de monde, je suppose.

Je doute fortement que beaucoup de monde se soit amusé à recoder diff juste
parcequ'il a des limitations ( léquelles d'ailleurs ? ). Sinon, je ferais
remarquer que bazaar-ng est plus qu'un simple log de differences. C'est
aussi un ensemble d'outils pour manipuler differentes branches et faciliter
la fusion des changements de plusieurs developeurs et/ou entre plusieurs
branches.

Bref, j'ai l'impression que cela ajoute de la lourdeur, sans couvrir assez
de besoins en contrepartie. Par exemple, pour gérer mes versions, j'ai un
outil (maison) qui réalise automatiquement le mise à jour des CD (jusqu'à
l'ISO), qui fait du FTP automatique, qui envoie des mails d'annonce (avec
ou sans pièces jointes). Autant de choses que je ne retrouve pas dans les
outils de gestion de version.

Ce n'est pas le rôle d'un outil de gestion de version de faire ça. C'est le
rôle d'un outils de packaging. Ce même outils de packaging doit bien être
codé un jour et peut profiter de la gestion de version.

Après, voici un exemple de comment livrer une version automatiquement avec
CVS :
cd repertoire_du_projet
cvs update
./packversion.sh

Et voila, c'était dur il faut bien dire.

A on me soufle qu'il suffit de commencer le script packversion.sh par la
commande "cvs update" pour économiser une étape. Et bien sur, il ne faut
pas oublier de mettre un CD vierge dans le lecteur sinon le programme de
gravure ne va pas pouvoir fonctionner.

Complexité du script ? Environ un 15aine de lignes maximum du moment que les
outils sont tous disponibles. Cela inclue bien sur l'envoit de mail,
l'upload sur FTP de l'installeur et le lancement du programme de gravure.

Déjà, mes logiciels étant allègrement multi-langages,

Je ne vois pas en quoi le fait que ça soit multi-langage pose un problème
quelconque.

et multi-outils,

Et alors ?

avec des formats différents, y compris pour les sources, ça va accrocher
dur,

Tu as du code source au format binaire maintenant ? Je croyais que tout
langage de programmation sérieux utilisait des fichiers texte.

avec TLA, SVC, Tortoise, subversion, et compagnie. J'avais essayé
Proview (pas les écrans, le gestionnaire de projets) ; mais, là aussi, ça
ne m'avais pas emballé.

TLA, SVN et BZR ne sont pas des outils de gestion de projet mais des outils
de gestion de code. Ne pas confondre. Proview a juste l'air d'être un IDE
qui date de l'époque de Win95 et qui n'a pas été mis à jour depuis ( du
moins ce que j'en ai trouvé sur google )

Donc, pour l'instant, je me contente de mes scripts, en attendant de
trouver mieux, ou d'avoir le temps de faire un truc qui me convienne.

C'est bien de critiquer les outils de gestion de version existant mais il
faudrait quand même savoir à quoi ils servent avant de dire que tes scripts
font bien le travail. Ceci car je te parle d'un outil qui gère les
changements dans le code et les différentes version des logiciels et tu me
parles d'un outil servant à compiler et packager une version.

Vous avez filtré cet utilisateur ! Consultez son message

Do Re Mi chel La Si Do wrote:

Bonjour !

J'ai regardé, et lu, rapidement, mais complètement, le site que tu as
indiqué.

D'abord, merci pour le lien (et la traduction).

Ensuite, et bien, cela m'a confirmé dans les limites de ce genre d'outil.
En gros, on a un LOG des DIFF
Et les limites de DIFF (ou de FC sous windows) sont telles que j'ai fait
mes propres outils d'analyse des différences (de fichiers textes). Comme
beaucoup de monde, je suppose.

Je doute fortement que beaucoup de monde se soit amusé à recoder diff juste
parcequ'il a des limitations ( léquelles d'ailleurs ? ). Sinon, je ferais
remarquer que bazaar-ng est plus qu'un simple log de differences. C'est
aussi un ensemble d'outils pour manipuler differentes branches et faciliter
la fusion des changements de plusieurs developeurs et/ou entre plusieurs
branches.

Bref, j'ai l'impression que cela ajoute de la lourdeur, sans couvrir assez
de besoins en contrepartie. Par exemple, pour gérer mes versions, j'ai un
outil (maison) qui réalise automatiquement le mise à jour des CD (jusqu'à
l'ISO), qui fait du FTP automatique, qui envoie des mails d'annonce (avec
ou sans pièces jointes). Autant de choses que je ne retrouve pas dans les
outils de gestion de version.

Ce n'est pas le rôle d'un outil de gestion de version de faire ça. C'est le
rôle d'un outils de packaging. Ce même outils de packaging doit bien être
codé un jour et peut profiter de la gestion de version.

Après, voici un exemple de comment livrer une version automatiquement avec
CVS :
cd repertoire_du_projet
cvs update
./packversion.sh

Et voila, c'était dur il faut bien dire.

A on me soufle qu'il suffit de commencer le script packversion.sh par la
commande "cvs update" pour économiser une étape. Et bien sur, il ne faut
pas oublier de mettre un CD vierge dans le lecteur sinon le programme de
gravure ne va pas pouvoir fonctionner.

Complexité du script ? Environ un 15aine de lignes maximum du moment que les
outils sont tous disponibles. Cela inclue bien sur l'envoit de mail,
l'upload sur FTP de l'installeur et le lancement du programme de gravure.

Déjà, mes logiciels étant allègrement multi-langages,

Je ne vois pas en quoi le fait que ça soit multi-langage pose un problème
quelconque.

et multi-outils,

Et alors ?

avec des formats différents, y compris pour les sources, ça va accrocher
dur,

Tu as du code source au format binaire maintenant ? Je croyais que tout
langage de programmation sérieux utilisait des fichiers texte.

avec TLA, SVC, Tortoise, subversion, et compagnie. J'avais essayé
Proview (pas les écrans, le gestionnaire de projets) ; mais, là aussi, ça
ne m'avais pas emballé.

TLA, SVN et BZR ne sont pas des outils de gestion de projet mais des outils
de gestion de code. Ne pas confondre. Proview a juste l'air d'être un IDE
qui date de l'époque de Win95 et qui n'a pas été mis à jour depuis ( du
moins ce que j'en ai trouvé sur google )

Donc, pour l'instant, je me contente de mes scripts, en attendant de
trouver mieux, ou d'avoir le temps de faire un truc qui me convienne.

C'est bien de critiquer les outils de gestion de version existant mais il
faudrait quand même savoir à quoi ils servent avant de dire que tes scripts
font bien le travail. Ceci car je te parle d'un outil qui gère les
changements dans le code et les différentes version des logiciels et tu me
parles d'un outil servant à compiler et packager une version.

Do Re Mi chel La Si Do

15/12/2005 à 19:11

Bonsoir !

Juste deux détails :

Je croyais que tout langage de programmation sérieux utilisait des
fichiers texte.

ça, ce n'est qu'une idée fausse, que rien ne justifie.

Dans Paradox, par exemple, le langage est intégré au GUI, et le code est lié
à chaque objet, jusque dans l'enregistrement dans les fichiers binaires.

Cela peut être intéressant. Par exemple, si on copie un champ, tous les
morceaux de code reliés suivent, avec les propriétés. On peut ainsi se faire
des bibliothèques d'objets, directement utilisables, avec de simples
copier/coller, et avec une gestion évènementielle complète.

Sinon, Proview date de 1999, mais la dernière version date de février 2005.
Ce n'est pas un simple gestionnaire de projets, car il permet de manipuler
les ensembles de codes, et d'objets. Une sorte de mélange de glade, de
gestion d'entrepôts d'objets, et d'éditeurs. Le tout auto-scriptable.

Mais ça ne me convient pas, pour autant.

@-salutations

Michel Claveau

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

10 réponses

Veuillez sélectionner un problème