versioning system (VCS)

Basile Starynkevitch

30/04/2011 à 20:30

On Sat, 30 Apr 2011 19:45:05 +0200
"Jean-Yves F. Barbier" wrote:

> Et même sur un développement où je suis tout seul, je commite plu sieurs
> fois par jour. Le temps entre deux commit, c'est le temps élémentai re
> qu'on accepte de perdre. On a donc intérêt à ce qu'il ne soit pas trop
> long.

Wai, ça revient à ce que tu disais: tu commites toute l'arborescence et pas un
seul fichier; je suppose qu'il-y-a des mécanismes d'économie de place
(symlinks?) pour ne pas que le projet grandisse sur le HD à une vitesse
exponentielle?

Oui, et particulièrement sur GIT. Il enregistre et compresse (dans des
sous-répertoires cachés appellés .git) les données et les méta-do nnées
de versionnement de manière très efficace en place disque et rapide en
temps. Par exemple, l'arborescence complète de GCC dépasse le giga, et
les données internes à .git sont bien plus petites (peut-être 3 ou 10
fois moins). C'est plus complexe (mais c'est l'affaire de git) et plus
efficace que des liens symboliques. Bien évidemment, on ne touche
jamais aux répertoires .git.

Pour la manipulation des fichiers, on utilise la commande git en
préfixe. Ainsi, au lieu de renommer un fichier foo.c en bar.c avec la
commande 'mv foo.c bar.c' on tape 'git mv foo.c bar.c'. Il faut éviter
de manipuler l'arborescence de fichiers sans prévenir le versionneur
git.

En pratique, l'utilisation de git consomme peu de ressources (disque ou
temps CPU), même sur des gros projets comme GCC, sur ta machine locale.
Et GIT (contrairement à SVN) conserve la totalité de l'historique sur
la machine locale: Quand j'utilise git avec le clone d'un dépot
distant, j'ai tout l'historique sur mon laptop et je peux demander la
version d'une branche d'il y a deux ans sans accéder au réseau.

> C'est aussi un avantage de GIT sur SVN: il sait faire des branches
> facilement et il sait commiter rapidement.
>
> En gros, je commite souvent après correction d'un seul bogue ou ajout
> d'une seule fonction ou méthode (notamment quand elle est publique), ou
> ajout de quelques douzaines de lignes au maximum. Je commite toujours
> avant de partir (manger, ou chez moi). Si je travaille toute la
> journée, je vais svn commettre deux fois par jour au moins (sauf
> peut-être quand je chasse un bogue insidieux qui me prend plusieurs
> jours).

Et... ça ne fini pas par rendre sourd de commiter trop souvent? ;-)

Non. Il faut comprendre que git commit-er son code source sous Emacs
est aussi facile et aussi simple que sauvegarder son document sous
OpenOffice.

> Bien sûr, faire cent commit-s dans une journée serait quand même
> excessif. Un truc très important, c'est d'avoir un message clair
> associé à son commit (ce n'est pas facile). Dans un développmeent
> communautaire, c'est indispensable et fortement codifié (chaque entr ée
> d'un ChangeLog de GCC correspond à un commit). Quand je bosse tout
> seul, j'ai à tort la faiblesse de mettre des messages de commit trop
> courts, et je le regrette plus tard.

C'est là que j'ai coincé parce que je ne savais pas comment faire un
retrieve d'un ou qq fichiers des commits précédents: à chaque fois je me
retrouvais avec une version complète (et donc mes modifs récentes vir ées)

Pas avec GIT, tu peux demander de voir une branche de ton projet, puis
une autre. Bien sûr, avec tout système de version, il faut commit-er
très souvent, car le commit est l'étape élémentaire d'un versionneu r.
Par définition, un versionneur ne gère rien en dehors des commits, qui
sont donc une instruction pour le versionneur que l'état actuel de
l'arborescence est intéressante et significative à versionner. Tous les
versionneurs que je connais ne retiennent que les commits (à l'inverse
des systèmes de fichiers de VMS, où le noyau contenait un médiocre
versionneur).

Pour un débutant avec GIT (ou même SVN) qui a un projet personnel, il
faut commit-er très souvent, et il vaut mieux le faire trop que pas
assez. A la louche, il faut commit-er au moins une fois par heure (et
il est impératif de commit-er deux fois par jour). En plus, quand tu
bosses tout seul, tu n'as pas à suivre des règles sociales compliquées
(tu pourrais même commettre du code qui ne compile pas ou qui n'as pas
été du tout testé ou que tu sais être bogué ou incomplet.).

Quand on bosse à plusieurs dans un projet collaboratif de
développement, il y a des règles sociales et humaines pour le commit.
Dans GCC elles sont strictes. Chaque projet a ses habitudes.

Mais à mon avis tu n'as pas bien compris le principe des versionneurs.
Il me semble qu'une demi-heure de lecture avant de commencer à les
utiliser te serait utile. Par exemple
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

On Sat, 30 Apr 2011 19:45:05 +0200
"Jean-Yves F. Barbier" <12ukwn@gmail.com> wrote:

> Et même sur un développement où je suis tout seul, je commite plu sieurs
> fois par jour. Le temps entre deux commit, c'est le temps élémentai re
> qu'on accepte de perdre. On a donc intérêt à ce qu'il ne soit pas trop
> long.

Wai, ça revient à ce que tu disais: tu commites toute l'arborescence et pas un
seul fichier; je suppose qu'il-y-a des mécanismes d'économie de place
(symlinks?) pour ne pas que le projet grandisse sur le HD à une vitesse
exponentielle?

Oui, et particulièrement sur GIT. Il enregistre et compresse (dans des
sous-répertoires cachés appellés .git) les données et les méta-do nnées
de versionnement de manière très efficace en place disque et rapide en
temps. Par exemple, l'arborescence complète de GCC dépasse le giga, et
les données internes à .git sont bien plus petites (peut-être 3 ou 10
fois moins). C'est plus complexe (mais c'est l'affaire de git) et plus
efficace que des liens symboliques. Bien évidemment, on ne touche
jamais aux répertoires .git.

Pour la manipulation des fichiers, on utilise la commande git en
préfixe. Ainsi, au lieu de renommer un fichier foo.c en bar.c avec la
commande 'mv foo.c bar.c' on tape 'git mv foo.c bar.c'. Il faut éviter
de manipuler l'arborescence de fichiers sans prévenir le versionneur
git.

En pratique, l'utilisation de git consomme peu de ressources (disque ou
temps CPU), même sur des gros projets comme GCC, sur ta machine locale.
Et GIT (contrairement à SVN) conserve la totalité de l'historique sur
la machine locale: Quand j'utilise git avec le clone d'un dépot
distant, j'ai tout l'historique sur mon laptop et je peux demander la
version d'une branche d'il y a deux ans sans accéder au réseau.

> C'est aussi un avantage de GIT sur SVN: il sait faire des branches
> facilement et il sait commiter rapidement.
>
> En gros, je commite souvent après correction d'un seul bogue ou ajout
> d'une seule fonction ou méthode (notamment quand elle est publique), ou
> ajout de quelques douzaines de lignes au maximum. Je commite toujours
> avant de partir (manger, ou chez moi). Si je travaille toute la
> journée, je vais svn commettre deux fois par jour au moins (sauf
> peut-être quand je chasse un bogue insidieux qui me prend plusieurs
> jours).

Et... ça ne fini pas par rendre sourd de commiter trop souvent? ;-)

Non. Il faut comprendre que git commit-er son code source sous Emacs
est aussi facile et aussi simple que sauvegarder son document sous
OpenOffice.

> Bien sûr, faire cent commit-s dans une journée serait quand même
> excessif. Un truc très important, c'est d'avoir un message clair
> associé à son commit (ce n'est pas facile). Dans un développmeent
> communautaire, c'est indispensable et fortement codifié (chaque entr ée
> d'un ChangeLog de GCC correspond à un commit). Quand je bosse tout
> seul, j'ai à tort la faiblesse de mettre des messages de commit trop
> courts, et je le regrette plus tard.

C'est là que j'ai coincé parce que je ne savais pas comment faire un
retrieve d'un ou qq fichiers des commits précédents: à chaque fois je me
retrouvais avec une version complète (et donc mes modifs récentes vir ées)

Pas avec GIT, tu peux demander de voir une branche de ton projet, puis
une autre. Bien sûr, avec tout système de version, il faut commit-er
très souvent, car le commit est l'étape élémentaire d'un versionneu r.
Par définition, un versionneur ne gère rien en dehors des commits, qui
sont donc une instruction pour le versionneur que l'état actuel de
l'arborescence est intéressante et significative à versionner. Tous les
versionneurs que je connais ne retiennent que les commits (à l'inverse
des systèmes de fichiers de VMS, où le noyau contenait un médiocre
versionneur).

Pour un débutant avec GIT (ou même SVN) qui a un projet personnel, il
faut commit-er très souvent, et il vaut mieux le faire trop que pas
assez. A la louche, il faut commit-er au moins une fois par heure (et
il est impératif de commit-er deux fois par jour). En plus, quand tu
bosses tout seul, tu n'as pas à suivre des règles sociales compliquées
(tu pourrais même commettre du code qui ne compile pas ou qui n'as pas
été du tout testé ou que tu sais être bogué ou incomplet.).

Quand on bosse à plusieurs dans un projet collaboratif de
développement, il y a des règles sociales et humaines pour le commit.
Dans GCC elles sont strictes. Chaque projet a ses habitudes.

Mais à mon avis tu n'as pas bien compris le principe des versionneurs.
Il me semble qu'une demi-heure de lecture avant de commencer à les
utiliser te serait utile. Par exemple
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110430202300.8a3ccb4a.basile@starynkevitch.net

Vous avez filtré cet utilisateur ! Consultez son message

On Sat, 30 Apr 2011 19:45:05 +0200
"Jean-Yves F. Barbier" wrote:

> Et même sur un développement où je suis tout seul, je commite plu sieurs
> fois par jour. Le temps entre deux commit, c'est le temps élémentai re
> qu'on accepte de perdre. On a donc intérêt à ce qu'il ne soit pas trop
> long.

Wai, ça revient à ce que tu disais: tu commites toute l'arborescence et pas un
seul fichier; je suppose qu'il-y-a des mécanismes d'économie de place
(symlinks?) pour ne pas que le projet grandisse sur le HD à une vitesse
exponentielle?

Oui, et particulièrement sur GIT. Il enregistre et compresse (dans des
sous-répertoires cachés appellés .git) les données et les méta-do nnées
de versionnement de manière très efficace en place disque et rapide en
temps. Par exemple, l'arborescence complète de GCC dépasse le giga, et
les données internes à .git sont bien plus petites (peut-être 3 ou 10
fois moins). C'est plus complexe (mais c'est l'affaire de git) et plus
efficace que des liens symboliques. Bien évidemment, on ne touche
jamais aux répertoires .git.

Pour la manipulation des fichiers, on utilise la commande git en
préfixe. Ainsi, au lieu de renommer un fichier foo.c en bar.c avec la
commande 'mv foo.c bar.c' on tape 'git mv foo.c bar.c'. Il faut éviter
de manipuler l'arborescence de fichiers sans prévenir le versionneur
git.

En pratique, l'utilisation de git consomme peu de ressources (disque ou
temps CPU), même sur des gros projets comme GCC, sur ta machine locale.
Et GIT (contrairement à SVN) conserve la totalité de l'historique sur
la machine locale: Quand j'utilise git avec le clone d'un dépot
distant, j'ai tout l'historique sur mon laptop et je peux demander la
version d'une branche d'il y a deux ans sans accéder au réseau.

> C'est aussi un avantage de GIT sur SVN: il sait faire des branches
> facilement et il sait commiter rapidement.
>
> En gros, je commite souvent après correction d'un seul bogue ou ajout
> d'une seule fonction ou méthode (notamment quand elle est publique), ou
> ajout de quelques douzaines de lignes au maximum. Je commite toujours
> avant de partir (manger, ou chez moi). Si je travaille toute la
> journée, je vais svn commettre deux fois par jour au moins (sauf
> peut-être quand je chasse un bogue insidieux qui me prend plusieurs
> jours).

Et... ça ne fini pas par rendre sourd de commiter trop souvent? ;-)

Non. Il faut comprendre que git commit-er son code source sous Emacs
est aussi facile et aussi simple que sauvegarder son document sous
OpenOffice.

> Bien sûr, faire cent commit-s dans une journée serait quand même
> excessif. Un truc très important, c'est d'avoir un message clair
> associé à son commit (ce n'est pas facile). Dans un développmeent
> communautaire, c'est indispensable et fortement codifié (chaque entr ée
> d'un ChangeLog de GCC correspond à un commit). Quand je bosse tout
> seul, j'ai à tort la faiblesse de mettre des messages de commit trop
> courts, et je le regrette plus tard.

C'est là que j'ai coincé parce que je ne savais pas comment faire un
retrieve d'un ou qq fichiers des commits précédents: à chaque fois je me
retrouvais avec une version complète (et donc mes modifs récentes vir ées)

Pas avec GIT, tu peux demander de voir une branche de ton projet, puis
une autre. Bien sûr, avec tout système de version, il faut commit-er
très souvent, car le commit est l'étape élémentaire d'un versionneu r.
Par définition, un versionneur ne gère rien en dehors des commits, qui
sont donc une instruction pour le versionneur que l'état actuel de
l'arborescence est intéressante et significative à versionner. Tous les
versionneurs que je connais ne retiennent que les commits (à l'inverse
des systèmes de fichiers de VMS, où le noyau contenait un médiocre
versionneur).

Pour un débutant avec GIT (ou même SVN) qui a un projet personnel, il
faut commit-er très souvent, et il vaut mieux le faire trop que pas
assez. A la louche, il faut commit-er au moins une fois par heure (et
il est impératif de commit-er deux fois par jour). En plus, quand tu
bosses tout seul, tu n'as pas à suivre des règles sociales compliquées
(tu pourrais même commettre du code qui ne compile pas ou qui n'as pas
été du tout testé ou que tu sais être bogué ou incomplet.).

Quand on bosse à plusieurs dans un projet collaboratif de
développement, il y a des règles sociales et humaines pour le commit.
Dans GCC elles sont strictes. Chaque projet a ses habitudes.

Mais à mon avis tu n'as pas bien compris le principe des versionneurs.
Il me semble qu'une demi-heure de lecture avant de commencer à les
utiliser te serait utile. Par exemple
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Aéris

30/04/2011 à 20:30

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 30/04/2011 19:50, Jean-Yves F. Barbier a écrit :

Wai, ça revient à ce que tu disais: tu commites toute l'arborescence et pas un
seul fichier; je suppose qu'il-y-a des mécanismes d'économie de place
(symlinks?) pour ne pas que le projet grandisse sur le HD à une vitesse
exponentielle?

Un SCM ne stocke que des diff, pas les fichiers complets.

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNvE42AAoJEK8zQvxDY4P9Iu8H/R+KLpDicDZtRoaDKrC/0JYT
UI0EzeTk92Re+4y2WgNw4BgnNFHd3DaqZ8d9soS5Ib/ciKKja0ebFyOchRpbPdeN
EmYstaF7fA0gz64wbMAZqzx7x3qqIvkFS/HK4cdCUoBy+7HEsnbbC002KM9yg3Hk
RETLkd7UP6edkXpGljwA2HmMmcv48tDAmfGTwA/5QjQnXIuFJ2EFf9XLGuiF4tya
RnHQtS3dedtFecIk9VqT6bkC5mv3ucB0ZW8OC+pVz0t0fEqpb16T6RRn794qiMG0
3QOsEJ5VUO/7cVZd7vo/ZiXhFIzoy5GBlOZRbspFWU09j6yn2+qYnO/ASFKHFnA =L2Sk
-----END PGP SIGNATURE-----

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/4dbc4e36$0$19739$

Jean-Yves F. Barbier

30/04/2011 à 21:10

On Sat, 30 Apr 2011 20:00:22 +0200, AÃ©ris wrote:

Un SCM ne stocke que des diff, pas les fichiers complets.

Honhon, donc je suppose qu'il-y-a aussi des mÃ©canismes de sÃ©curit Ã© qui
prennent le relais si, par exemple, je dÃ©cide de virer les 100 premiers
commits? (de faÃ§on Ã "reconstituer" la base-0 du diff)

--
Obviously the only rational solution to your problem is suicide.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Basile Starynkevitch

30/04/2011 à 21:30

On Sat, 30 Apr 2011 20:59:37 +0200
"Jean-Yves F. Barbier" wrote:

On Sat, 30 Apr 2011 20:00:22 +0200, Aéris wrote:

> Un SCM ne stocke que des diff, pas les fichiers complets.

Honhon, donc je suppose qu'il-y-a aussi des mécanismes de sécurité qui
prennent le relais si, par exemple, je décide de virer les 100 premiers
commits? (de façon à "reconstituer" la base-0 du diff)

Ça n'a aucun sens de virer des commits. un versionneur conserve par
définition même tout l'historique, puisqu'il permet au minimum de
revenir ou de comparer avec n'importe quelle version passée.

On ne peut donc pas supprimer des commits. On peut tout au plus
modifier certains (ou tous les) fichiers (gérés par le versionneurs)
pour qu'ils reviennent dans l'état où ils était il y a (par exemple) un
moins. Ensuite, on va par exemple commit-er ce nouvel état là. Mais le
versionneur a bien enregistré tous les états commit-és par définiti on
même.

J'insiste, on ne vire pas des commits: l'historique géré par un
versionneur est toujours "chronologiquement" croissante! Tout au plus
on peut commit-er un état de l'arborescence qui se trouve être le même
(ou ressembler un peu à) l'état de cette arborescence il y a un mois ou
une année.

Mais le rôle d'un versionneur c'est évidemment d'être capable de
restituer l'état de l'arborescence à n'importe quelle date (ou point de
commit) dans le passé (ou dans une aitre branche, etc.).

L'historique d'une arborescence versionnée est toujours croissante,
même si des fichiers sont revenus à leur état antérieur.

C'est un peu comme dans un registre d'état civil: même à ma mort, je
n'y serais pas effacé, on ajoutera juste la mention que je suis mort.

Et il me semble que la notion de sécurité n'a rien à voir avec le
versionnement (sauf évidemment quand il s'agit de versionner les
commits de users différents, avec toute la problèmatique des droits
d'accès, qui peuvent être indépendants de ceux du noyau Linux).

Donc je ne comprends pas cette remarque sur "des mécanismes de sécurit é
qui prennent le relais si, par exemple, je décide de virer les 100
premiers commits?". Ca n'a pas grand chose à voir avec la sécurité
(sauf si on se place du point de vue d'un serveur de versionnement et
de l'authentification; celle de git me parait robuste). Et surtout, ça
n'a aucun sens de virer des commits: sauf dans les régimes staliniens,
on ne ré-écrit pas l'Histoire. Un versionneur enregistre l'histoire
d'une arborescence.

Un versionneur est au minimum un outil qui accepte des ordres de commit
concernant une arborescence source, en conserve l'historique, et qui
est capable de restaurer (ou de comparer) cette arborescence à l'état
qu'elle avait à n'importe quel commit dans le passé.

Mais parler de virer un commit n'a aucun sens.

(git est assez compliqué et permet le 'git rebase -i' qui semble s'en
rapprocher. Mais je n'en conçois pas l'intérêt, et c'est violemment
documenté comme étant absoluement à éviter, au moins pour les déb utants
dont je suis encore).

J'insiste, la terminologie employée à tort par Jean-Yves [comme "virer
un commit" qui me fait hurler] me fait penser qu'il y a des concepts
des versionneurs qui lui échappent.

Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

On Sat, 30 Apr 2011 20:59:37 +0200
"Jean-Yves F. Barbier" <12ukwn@gmail.com> wrote:

On Sat, 30 Apr 2011 20:00:22 +0200, Aéris <aeris@imirhil.fr> wrote:

> Un SCM ne stocke que des diff, pas les fichiers complets.

Honhon, donc je suppose qu'il-y-a aussi des mécanismes de sécurité qui
prennent le relais si, par exemple, je décide de virer les 100 premiers
commits? (de façon à "reconstituer" la base-0 du diff)

Ça n'a aucun sens de virer des commits. un versionneur conserve par
définition même tout l'historique, puisqu'il permet au minimum de
revenir ou de comparer avec n'importe quelle version passée.

On ne peut donc pas supprimer des commits. On peut tout au plus
modifier certains (ou tous les) fichiers (gérés par le versionneurs)
pour qu'ils reviennent dans l'état où ils était il y a (par exemple) un
moins. Ensuite, on va par exemple commit-er ce nouvel état là. Mais le
versionneur a bien enregistré tous les états commit-és par définiti on
même.

J'insiste, on ne vire pas des commits: l'historique géré par un
versionneur est toujours "chronologiquement" croissante! Tout au plus
on peut commit-er un état de l'arborescence qui se trouve être le même
(ou ressembler un peu à) l'état de cette arborescence il y a un mois ou
une année.

Mais le rôle d'un versionneur c'est évidemment d'être capable de
restituer l'état de l'arborescence à n'importe quelle date (ou point de
commit) dans le passé (ou dans une aitre branche, etc.).

L'historique d'une arborescence versionnée est toujours croissante,
même si des fichiers sont revenus à leur état antérieur.

C'est un peu comme dans un registre d'état civil: même à ma mort, je
n'y serais pas effacé, on ajoutera juste la mention que je suis mort.

Et il me semble que la notion de sécurité n'a rien à voir avec le
versionnement (sauf évidemment quand il s'agit de versionner les
commits de users différents, avec toute la problèmatique des droits
d'accès, qui peuvent être indépendants de ceux du noyau Linux).

Donc je ne comprends pas cette remarque sur "des mécanismes de sécurit é
qui prennent le relais si, par exemple, je décide de virer les 100
premiers commits?". Ca n'a pas grand chose à voir avec la sécurité
(sauf si on se place du point de vue d'un serveur de versionnement et
de l'authentification; celle de git me parait robuste). Et surtout, ça
n'a aucun sens de virer des commits: sauf dans les régimes staliniens,
on ne ré-écrit pas l'Histoire. Un versionneur enregistre l'histoire
d'une arborescence.

Un versionneur est au minimum un outil qui accepte des ordres de commit
concernant une arborescence source, en conserve l'historique, et qui
est capable de restaurer (ou de comparer) cette arborescence à l'état
qu'elle avait à n'importe quel commit dans le passé.

Mais parler de virer un commit n'a aucun sens.

(git est assez compliqué et permet le 'git rebase -i' qui semble s'en
rapprocher. Mais je n'en conçois pas l'intérêt, et c'est violemment
documenté comme étant absoluement à éviter, au moins pour les déb utants
dont je suis encore).

J'insiste, la terminologie employée à tort par Jean-Yves [comme "virer
un commit" qui me fait hurler] me fait penser qu'il y a des concepts
des versionneurs qui lui échappent.

Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110430212340.e5b016a3.basile@starynkevitch.net

Vous avez filtré cet utilisateur ! Consultez son message

On Sat, 30 Apr 2011 20:59:37 +0200
"Jean-Yves F. Barbier" wrote:

On Sat, 30 Apr 2011 20:00:22 +0200, Aéris wrote:

> Un SCM ne stocke que des diff, pas les fichiers complets.

Honhon, donc je suppose qu'il-y-a aussi des mécanismes de sécurité qui
prennent le relais si, par exemple, je décide de virer les 100 premiers
commits? (de façon à "reconstituer" la base-0 du diff)

Ça n'a aucun sens de virer des commits. un versionneur conserve par
définition même tout l'historique, puisqu'il permet au minimum de
revenir ou de comparer avec n'importe quelle version passée.

On ne peut donc pas supprimer des commits. On peut tout au plus
modifier certains (ou tous les) fichiers (gérés par le versionneurs)
pour qu'ils reviennent dans l'état où ils était il y a (par exemple) un
moins. Ensuite, on va par exemple commit-er ce nouvel état là. Mais le
versionneur a bien enregistré tous les états commit-és par définiti on
même.

J'insiste, on ne vire pas des commits: l'historique géré par un
versionneur est toujours "chronologiquement" croissante! Tout au plus
on peut commit-er un état de l'arborescence qui se trouve être le même
(ou ressembler un peu à) l'état de cette arborescence il y a un mois ou
une année.

Mais le rôle d'un versionneur c'est évidemment d'être capable de
restituer l'état de l'arborescence à n'importe quelle date (ou point de
commit) dans le passé (ou dans une aitre branche, etc.).

L'historique d'une arborescence versionnée est toujours croissante,
même si des fichiers sont revenus à leur état antérieur.

C'est un peu comme dans un registre d'état civil: même à ma mort, je
n'y serais pas effacé, on ajoutera juste la mention que je suis mort.

Et il me semble que la notion de sécurité n'a rien à voir avec le
versionnement (sauf évidemment quand il s'agit de versionner les
commits de users différents, avec toute la problèmatique des droits
d'accès, qui peuvent être indépendants de ceux du noyau Linux).

Donc je ne comprends pas cette remarque sur "des mécanismes de sécurit é
qui prennent le relais si, par exemple, je décide de virer les 100
premiers commits?". Ca n'a pas grand chose à voir avec la sécurité
(sauf si on se place du point de vue d'un serveur de versionnement et
de l'authentification; celle de git me parait robuste). Et surtout, ça
n'a aucun sens de virer des commits: sauf dans les régimes staliniens,
on ne ré-écrit pas l'Histoire. Un versionneur enregistre l'histoire
d'une arborescence.

Un versionneur est au minimum un outil qui accepte des ordres de commit
concernant une arborescence source, en conserve l'historique, et qui
est capable de restaurer (ou de comparer) cette arborescence à l'état
qu'elle avait à n'importe quel commit dans le passé.

Mais parler de virer un commit n'a aucun sens.

(git est assez compliqué et permet le 'git rebase -i' qui semble s'en
rapprocher. Mais je n'en conçois pas l'intérêt, et c'est violemment
documenté comme étant absoluement à éviter, au moins pour les déb utants
dont je suis encore).

J'insiste, la terminologie employée à tort par Jean-Yves [comme "virer
un commit" qui me fait hurler] me fait penser qu'il y a des concepts
des versionneurs qui lui échappent.

Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Aéris

30/04/2011 à 21:50

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 30/04/2011 21:10, Jean-Yves F. Barbier a écrit :

Honhon, donc je suppose qu'il-y-a aussi des mécanismes de sécurité qui
prennent le relais si, par exemple, je décide de virer les 100 premiers
commits? (de façon à "reconstituer" la base-0 du diff)

Il est impossible de supprimer des commits.
Au mieux tu feras un 101ième commit qui annulera les 100ers.

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNvGJ7AAoJEK8zQvxDY4P9WrkH/0+jfz+jTqM97vwHA/eFlw9+
wzaopc71gBCN2Eis4QbljDBKwApcqYAKaleis6BC64gBRB7qV+vH65HKJ5vdkf73
skU7p905ACD0LvU6R2NK1t4Zyq5ORX6zZdRRXrrdF9kUspJHGQE1fiXg2cxegPik
mj2TVgeWo1lK+4N+z/msxaMedKCgIil3L8zSP0pzCEbjM5HRAGIYSMmw0P47oytL
xjcgw9178PnEzjjLpGp3CGQEFj839eHFU1uPRQs8wc9JsXRQnGIf3G1pYfdqlxTV
YUi5uiuMq/xw3OUB4YHDxDouKi0o1KO30ZAxkZ0lRIlcNX42Tbj6aRTr6pgP9T8 =HFJQ
-----END PGP SIGNATURE-----

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/4dbc6280$0$24553$

Aéris

30/04/2011 à 22:00

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 30/04/2011 19:20, Bernard Schoenacker a écrit :

es tu sûr de ne pas parler de la versio libre de VMS ?
lien :
http://fr.wikipedia.org/wiki/OpenVMS

Il n'y a pas de version libre de VMS.
Malgré le nom, il s'agit d'un OS propriétaire.

Mais cet OS a l'avantage d'intégrer un SCM en natif dans le filesystem,
tout fichier est associé à une version qui s'incrémente à chaque
enregistrement et toute version peut être accédée n'importe quand

reste à trouver la branche pour GNU ...

Il n'y en a pas, sauf à utiliser des émulateurs ou des virtualiseurs.

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNvGOmAAoJEK8zQvxDY4P9RwsH/2SAAKZJOJCEdn3zY5mMoHVC
W5xZmOIzZDS351lXgTXyECO33kRXnqpIYyCqqYHtY58GkGrPgK8ZJEaTVeYGw9LG
iiXVV3nWJ4OtJ/P8rBidGv1Tatw/hGLMgFT+utylcrOKlVqPDd0YacTG8/Wejq9/
reBnOBtDlrtEW78lKUGkCx3q6krHGS5rAkY9n/DTRwxJjI/2UmABIbuM4z3/+P/w
puv+z5S+C/r2OUjg5VOtF6zbBRCXjALj87IWJTGSShy9/yU/bHSo4zgoJ8+W0Kxt
dYOTdh53ZlwsmSm/r3QEuSGY3JkdoHhyBNApKaqr2PVIX6o36H42IFRYRD3GTew =+yQq
-----END PGP SIGNATURE-----

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/4dbc63a6$0$19044$

Stephane Bortzmeyer

30/04/2011 à 23:20

On Sat, Apr 30, 2011 at 09:31:50PM +0200,
Aéris wrote
a message of 42 lines which said:

Mais cet OS a l'avantage d'intégrer un SCM en natif dans le
filesystem, tout fichier est associé à une version qui s'incrémente
à chaque enregistrement et toute version peut être accédée n'importe
quand

J'ai été ingénieur système VMS pendant des années et appeler son
(excellent) système de fichiers un VCS est *très* exagéré :

- pas de message de commits par version,
- pas de stockage infini (VMS ne garde que les N dernières versions,
où N est réglable)
- pas de branches, ni de tags.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Aéris

30/04/2011 à 23:50

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 30/04/2011 23:20, Stephane Bortzmeyer a écrit :

J'ai été ingénieur système VMS pendant des années et appeler son
(excellent) système de fichiers un VCS est *très* exagéré :

- pas de message de commits par version,
- pas de stockage infini (VMS ne garde que les N dernières versions,
où N est réglable)
- pas de branches, ni de tags.

Je te le concède totalement =)
Mais c'est tellement unique et sympa comme fonctionnement que cela
méritait d'être signalé.

- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNvH9JAAoJEK8zQvxDY4P95hkIALWlkrhahhR59eXcIuM/yWlC
7J3zodTSpJ0+8MuERI9WbcOfgvo/Ql5jGRYoZ/OzqVCG2+lSpmRgQ8oPeNsKkmLz
i5n/KS6jBrpGLEdW5vTXrXC4y4885hqvG/Y6pt1OtNeF6xJbwqiTLEnL6ISEmDXS
SbgcAXWTyLMPvxiCce7O3ddgWCjJXk7jS7nYkqWUyelqsn6OR4kj3viVs349RMDB
yJf9j2m6Z+xVieew2ItRMcm0oNGHAHrCQKP8fGvDWqtk0PAArqkhhTs3KoDnPLxe
ShZktQVnLB3gwGXuacmi6Uy/HCE/K3/TBzUtFzIzLiFkr/tRLmdZCbPH0Ho0jqI =z3tZ
-----END PGP SIGNATURE-----

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/4dbc7f49$0$19123$

versioning system (VCS)

8 réponses

Veuillez sélectionner un problème