Re: versioning system (VCS)
Le Sat, Apr 30, 2011 at 09:23:40PM +0200, Basile Starynkevitch a écrit : 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éfinition même. Bonjour, Git peut supprimer des commits, c'est à dire réécrire l'histoire, par exemple avec les commandes rebase et filter-branch. On s'en sert par exemple pour rendre plus synthétique un changement développé en privé, pour effacer définitivement un fichier trop gros après s'être mordu les doigts de l'avoir inclus, ou pour oublier entièrement un fichier dont on s'aperçoit longtemps après l'avoir ajouté qu'il n'était pas redistribuable, et caetera. C'est bien sûr une utilisation avancée qu'il n'est pas nécessaire de maîtriser au début. Bon dimanche, -- Charles Plessy Illkirch-Graffenstaden, Alsace, France. -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110501064439.ga9...@merveille.plessy.net
Re: versioning system (VCS)
On Sat, Apr 30, 2011 at 11:23:20PM +0200, Aéris ae...@imirhil.fr wrote a message of 33 lines which said: http://www.bortzmeyer.org/time-and-space-in-vcs.html Certes mais c'est très fortement conseillé? Non, pour les raisons expliquées dans l'article que je cite. D'autre part, avec les VCS décentralsiés comme git, chaque copie de travail contient *tout* l'historique, ce qui est un « gaspillage » bien pire. Enfin, comparez la taille du dépôt d'un VCS de codes sources avec celles des vidéos qu'on trouve aujourd'hui sur tous les disques durs et vous verrez que ce n'est pas le VCS qu'il faut optimiser... -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110501084635.ga3...@sources.org
Re: versioning system (VCS)
On Sat, Apr 30, 2011 at 09:23:40PM +0200, Basile Starynkevitch bas...@starynkevitch.net wrote a message of 88 lines which said: Et surtout, ça n'a aucun sens de virer des commits: sauf dans les régimes staliniens, on ne ré-écrit pas l'Histoire. Il existe plusieurs cas où c'est utile, le plus évident étant lorsqu'on a commité dans un dépôt public un fichier qu'on n'avait pas le droit de distribuer. C'est pourquoi tous les VCS disposent de mécanismes « staliniens », plus ou moins pratiques. Par exemple pour Subversion : http://subversion.apache.org/faq.html#removal Un autre exemple d'une bonne raison : http://stackoverflow.com/questions/205296/delete-file-contents-from-svn-history Mais je suis d'accord qu'il s'agit d'opérations exceptionnelles, réservées aux cas où on a fait une grosse bêtise. Le style de travail que décrivait Jean-Yves F. Barbier, à coup de réécriture systématique de l'histoire, est en effet surprenant, et certainement mal géré par les VCS existants. -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110501085256.gb3...@sources.org
Re: versioning system (VCS)
On Sun, 1 May 2011 10:52:56 +0200, Stephane Bortzmeyer steph...@sources.org wrote: ... Mais je suis d'accord qu'il s'agit d'opérations exceptionnelles, réservées aux cas où on a fait une grosse bêtise. Le style de travail que décrivait Jean-Yves F. Barbier, à coup de réécriture systématique de l'histoire, est en effet surprenant, et certainement mal géré par les VCS existants. En fait, je 'gadais plutôt la taille globale et le nombre de commits sur le principe: plucékyena moincékyadlaplace, mais grâce aux commentaires de Basile et avec quelques lectures en sus, j'ai découvert qu'entre les différentes méthodes de type diff et la compression mon inquiétude était sans fondement. Par exemple, la méthode delta de Fossil: http://www.fossil-scm.org/index.html/doc/trunk/www/delta_encoder_algorithm.wiki donne des résultats impressionnants adossée à zlib: http://fossil-scm.org/index.html/doc/trunk/www/stats.wiki De plus la facilité d'utilisation en fait un outil simple et puissant; il assure même la sécurité: après un commit j'ai renommé mon trunk/ en trunk_OFF/ pour voir, dès que j'ai relancé Fossil il a reconstitué trunk/! -- Never look a gift horse in the mouth. -- Saint Jerome -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110501120610.1f53c91e@anubis.defcon1
Re: versioning system (VCS)
On Sun, 1 May 2011 10:52:56 +0200
Stephane Bortzmeyer steph...@sources.org wrote:
On Sat, Apr 30, 2011 at 09:23:40PM +0200,
Basile Starynkevitch bas...@starynkevitch.net wrote
a message of 88 lines which said:
Et surtout, ça n'a aucun sens de virer des commits: sauf dans les
régimes staliniens, on ne ré-écrit pas l'Histoire.
Il existe plusieurs cas où c'est utile, le plus évident étant
lorsqu'on a commité dans un dépôt public un fichier qu'on n'avait pas
le droit de distribuer. C'est pourquoi tous les VCS disposent de
mécanismes « staliniens », plus ou moins pratiques. [...]
Mais je suis d'accord qu'il s'agit d'opérations exceptionnelles,
réservées aux cas où on a fait une grosse bêtise.
Oui, je suis d'accord, et dans un autre message j'avais évoqué la
manière de GIT pour ce faire. Mais moi même, je n'ai *jamais* eu besoin
de ré-ecrire l'histoire (mais j'ai dû une fois aider un collègue qui
avant mis sous Svn un fichier qui n'avait rien à voir...).
Le style de travail que décrivait Jean-Yves F. Barbier, à coup de réécriture
systématique
de l'histoire, est en effet surprenant, et certainement mal géré par
les VCS existants.
Tout à fait, et Jean-Yves m'a laissé l'impression de ne pas bien
comprendre comment la plupart des développeurs utilisent les VCS.
J'espère que nous aurions un peu réussi à changer sa façon de voir...
Cordialement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110501122731.eaf732a7.bas...@starynkevitch.net
versioning system (VCS)
Salut liste, je ne connais ces systèmes que pour récupérer une version, mais maintenant, pour un dev, j'ai besoin d'en utiliser un. J'ai besoin de: * Plusieurs branches (stable, unstable, dev), * Pouvoir revenir (dès fois) de bcp de versions en arrière sur certains fichiers seulement, * Et surtout que ça ne soit pas une usine à gaz nécessitant la lecture de 200 pages de doc pour apprendre à se servir de chaque ordre possible (un poil intuitif, ça changerait:) Donc vos expériences sont le bienvenu. JY -- like: When being alive at the same time is a wonderful coincidence. -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430153922.72cc07a9@anubis.defcon1
Re: versioning system (VCS)
Le Sat, 30 Apr 2011 15:39:22 +0200, Jean-Yves F. Barbier 12u...@gmail.com a écrit : Salut liste, je ne connais ces systèmes que pour récupérer une version, mais maintenant, pour un dev, j'ai besoin d'en utiliser un. J'ai besoin de: * Plusieurs branches (stable, unstable, dev), * Pouvoir revenir (dès fois) de bcp de versions en arrière sur certains fichiers seulement, * Et surtout que ça ne soit pas une usine à gaz nécessitant la lecture de 200 pages de doc pour apprendre à se servir de chaque ordre possible (un poil intuitif, ça changerait:) Donc vos expériences sont le bienvenu. JY Bonjour, serait il possible d'être un peut plus disert sur le sujet concernant un équivalent de : -a) CVS -b) SVN -c) GIT est il possible de savoir si les clients sont win32 ou uniquement GNU ... liens : http://www.linux-pour-lesnuls.com/cvs.php slt bernard -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430160607.4ec61639.bernard.schoenacker_free.fr@hamtaro
Re: versioning system (VCS)
On Sat, 30 Apr 2011 15:39:22 +0200
Jean-Yves F. Barbier 12u...@gmail.com wrote:
je ne connais ces systèmes que pour récupérer une version, mais
maintenant, pour un dev, j'ai besoin d'en utiliser un.
Tu n'as pas indiqué quel genre de développement c'est.
J'ai besoin de:
* Plusieurs branches (stable, unstable, dev),
* Pouvoir revenir (dès fois) de bcp de versions en arrière sur certains
fichiers seulement,
* Et surtout que ça ne soit pas une usine à gaz nécessitant la lecture de
200 pages de doc pour apprendre à se servir de chaque ordre possible (un
poil intuitif, ça changerait:)
Une question importante est de savoir qui va (au début, et surtout dans
l'avenir) utiliser ce versionneur. Vas tu l'utiliser tout seul pour un
développement sur lequel tu es le seul à travailler? Est-ce que les
contributeurs futurs à ton développement logiciel seront proches ou
éloignés? Développes tu sous et pour Linux? S'agit-il d'une application
web? Est-ce un petit développement ex nihilo, ou bien pars tu d'un
logiciel source existant? S'agit-il de développer un logiciel libre? Ou
un logiciel qui pourrait plus tard être accédé voire modifié (via le
versionneur) par une grosse communauté? (Ainsi, même pour du
développement propriétaire, on ne fait pas les mêmes choix de
versionneurs dans une grosse multi nationale et dans une toute petite
PME)? S'il y a d'autres développeurs actuellement sur ce projet, à
quels versionneurs sont-ils habitués? Quel est le volume prévisible des
sources (ou autres, on pourrait aussi versionner des photos.. etc...) à
versionner? Est-ce que la connectivité est suffisante (par exemple,
accédera-t-on à ce versionneur depuis un autre continent?).
Un autre point très important: il n'est pas du tout nécessaire de
maitriser la totalité des fonctionalités d'un versionneur pour
l'utiliser avec profit. Par exemple concret, je connais mal git, mais
je l'utilise avec satisfaction pour des petits développements
personnels (logiciels ou documentation), et je n'en comprends pas tout.
Le livre Pragmatic Guide to Git de Travis Swicegood me parait clair.
Enfin, il faut savoir que changer de versionneur pendant un
développement est une opération délicate (qui peut nécessiter
l'interdiction de l'accès aux sources versionnées pendant plus d'une
journée), et une telle migration doit être planifiée et testée à
l'avance. Ainsi, le compilateur GCC a mis des années à passer de CVS à
SVN.
Il faut aussi savoir si on veut un versionnement centralisé (qui
convient probablement mieux à du logiciel propriétaire développé par
une équipe locale) ou un versionnement distribué.
Je te conseille donc git (surtout si tu veux un versionnement
distribué, mais je m'en sers aussi pour des projets où je suis tout
seul). La documentation complète est effectivement grosse, mais on est
pas du tout obligé de la lire en entier. Je ne connais pas du tout les
subtilités de git mais j'arrive à m'en servir sur des projets neufs
(c'est probablement plus difficile de migrer vers git depuis autre
chose).
Si tu voulais absoluement un versionnement centralisé (que je te
déconseille), tu pourrais prendre subversion.
Je ne te conseille pas bzr ni mercurial, mais je les connais très mal
et ne m'en sers que pour rapatrier du code source d'un logiciel libre
déposé ailleurs.
Il existe des entreprises qui vendent le service de versionnement. L'un
des avantages, c'est ipso facto de constituer une sauvegarde à
distance. Par exemple http://myversioncontrol.com/ ou http://github.com/
Pour du logiciel libre GPL, on trouve assez facilement des versionneurs
gratuits.
A priori je te conseille git, mais j'avoue l'utiliser avec satisfaction
sans en maitriser toutes facettes.
Cordialement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110430160717.49beac9b.bas...@starynkevitch.net
Re: versioning system (VCS)
On Sat, 30 Apr 2011 16:06:07 +0200
Bernard Schoenacker bernard.schoenac...@free.fr wrote:
serait il possible d'être un peut plus disert sur le sujet
concernant un équivalent de :
-a) CVS
C'est mort CVS. SVN l'a remplacé, et il est déjà assez largement
obsolète, même s'il est très utilisé.
-b) SVN
http://fr.wikipedia.org/wiki/Subversion_(logiciel)
-c) GIT
http://fr.wikipedia.org/wiki/Git
est il possible de savoir si les clients sont win32 ou uniquement
GNU ...
Il me semble que la plupart des versionneurs libres ont des clients
pour des systèmes microsoft. Cela étant dit, je n'ai quasiment jamais
utilisé Windows (mais j'utilise Linux depuis 1993, et j'utilisais Unix
en 1985 - je développais sous SunOS3.5 à l'époque.) et je ne suis pas
la bonne personne pour en parler.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110430161925.7ee2090e.bas...@starynkevitch.net
Re: versioning system (VCS)
On Sat, 30 Apr 2011 16:07:17 +0200, Basile Starynkevitch bas...@starynkevitch.net wrote: Une question importante est de savoir qui va (au début, et surtout dans l'avenir) utiliser ce versionneur. Vas tu l'utiliser tout seul pour un développement sur lequel tu es le seul à travailler? Vi Est-ce que les contributeurs futurs à ton développement logiciel seront proches ou éloignés? Les 2 Développes tu sous et pour Linux? Vi, mais avec poss d'extension à d'autres OS (par contribs) S'agit-il d'une application web? Non Est-ce un petit développement ex nihilo, ou bien pars tu d'un logiciel source existant? Ex-nihilo S'agit-il de développer un logiciel libre? Je ne sais pas encore (si c'est non, c'est parce que je souhaiterai exclure toute organisation gouvernementale afférente) un logiciel qui pourrait plus tard être accédé voire modifié (via le versionneur) par une grosse communauté? Non, tout au plus certains devs choisis (Ainsi, même pour du développement propriétaire, on ne fait pas les mêmes choix de versionneurs dans une grosse multi nationale et dans une toute petite PME)? Plutôt une chtite PME S'il y a d'autres développeurs actuellement sur ce projet, à quels versionneurs sont-ils habitués? Non, pas avant une version 0.99 Quel est le volume prévisible des sources à versionner? Tout au plus qq mégas (seulement du code en texte et qq icones/images (figées)) Est-ce que la connectivité est suffisante (par exemple, accédera-t-on à ce versionneur depuis un autre continent?). Oui (fibre) Un autre point très important: il n'est pas du tout nécessaire de maitriser la totalité des fonctionalités d'un versionneur pour l'utiliser avec profit. Par exemple concret, je connais mal git, mais je l'utilise avec satisfaction pour des petits développements personnels (logiciels ou documentation), et je n'en comprends pas tout. Le livre Pragmatic Guide to Git de Travis Swicegood me parait clair. J'ai jeté un oeil, mais je n'ai pas trouvé comment revenir en AR sur un seul fichier. Enfin, il faut savoir que changer de versionneur pendant un développement est une opération délicate (qui peut nécessiter l'interdiction de l'accès aux sources versionnées pendant plus d'une journée), et une telle migration doit être planifiée et testée à l'avance. Ainsi, le compilateur GCC a mis des années à passer de CVS à SVN. C'est ben pour ça que je pose la question ici: j'ai lu quelques articles sur la toile et tous disent cela. Il faut aussi savoir si on veut un versionnement centralisé (qui convient probablement mieux à du logiciel propriétaire développé par une équipe locale) ou un versionnement distribué. C'est une pierre d'achoppement: pour certaines parties, je souhaite rester seul maître de l'incorporation ou non des devs externes; mais pour d'autres (où je suis peu à l'aise) il est possible que certains pans soient entièrement externalisés. Je te conseille donc git (surtout si tu veux un versionnement distribué, mais je m'en sers aussi pour des projets où je suis tout seul). La documentation complète est effectivement grosse, mais on est pas du tout obligé de la lire en entier. Je ne connais pas du tout les subtilités de git mais j'arrive à m'en servir sur des projets neufs (c'est probablement plus difficile de migrer vers git depuis autre chose). Comme dit plus haut et parce que je procède souvent par tâtonnements, je dois-être en mesure de pouvoir revenir en AR d'une ou plusieurs versions seulement sur certains fichiers, mais c'est justement ce que je n'ai pas trouvé dans git. Si tu voulais absoluement un versionnement centralisé (que je te déconseille), tu pourrais prendre subversion. Non, je ne pense pas (et puis, qui peut le plus peut le moins:) Je ne te conseille pas bzr ni mercurial, mais je les connais très mal et ne m'en sers que pour rapatrier du code source d'un logiciel libre déposé ailleurs. Mercurial semble encore plus abscon que git (mais testé il-y-a un certain temps), quant'à Bazaar je ne connais pas mais il existe en tant que package. Il existe des entreprises qui vendent le service de versionnement. L'un des avantages, c'est ipso facto de constituer une sauvegarde à distance. Par exemple http://myversioncontrol.com/ ou http://github.com/ Pour l'instant, non (j'ai la possibilité d'aller pêcher dans le svr alimenté en fibre à partir de chez moi, donc il est facile de faire un rsync régulier.) A priori je te conseille git, mais j'avoue l'utiliser avec satisfaction sans en maitriser toutes facettes. Je veux bien, mais à la condition exprimée ci-dessus. -- Your analyst has you mixed up with another patient. Don't believe a thing he tells you. -- 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-requ...@lists.debian.org En cas de soucis, contactez
Re: versioning system (VCS)
Le Sat, Apr 30, 2011 at 04:48:23PM +0200, Jean-Yves F. Barbier a écrit : J'ai jeté un oeil, mais je n'ai pas trouvé comment revenir en AR sur un seul fichier. Bonjour, je conseille aussi Git. Il est facile de récupérer une ancienne version d'un fichier seulement, avec la commande « git checkout ». http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one-file Pour les collègues sous windows, il y a Tortoise Git, qui est très pratique et s'installe facilement. http://code.google.com/p/tortoisegit/ Amicalement, -- Charles Plessy Illkirch-Graffenstaden, Alsace, France -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430145812.ga12...@merveille.plessy.net
Re: versioning system (VCS)
On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy ple...@debian.org wrote: je conseille aussi Git. Il est facile de récupérer une ancienne version d'un fichier seulement, avec la commande « git checkout ». http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one-file Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je souhaite pouvoir revenir en AR d'un nombre _quelconque_ de révisions sur n'importe quel fichier Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à la fin, soit le fichier final correspond à mes attentes, soit je pioche dans plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie du dev est peut-être uniquement du ressort personnel et pas du système de VCS?) -- Marriage is an institution in which two undertake to become one, and one undertakes to become nothing. -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430172103.776c82da@anubis.defcon1
Re: versioning system (VCS)
Le Sat, 30 Apr 2011 17:21:03 +0200, Jean-Yves F. Barbier 12u...@gmail.com a écrit : On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy ple...@debian.org wrote: je conseille aussi Git. Il est facile de récupérer une ancienne version d'un fichier seulement, avec la commande « git checkout ». http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one-file Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je souhaite pouvoir revenir en AR d'un nombre _quelconque_ de révisions sur n'importe quel fichier Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à la fin, soit le fichier final correspond à mes attentes, soit je pioche dans plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie du dev est peut-être uniquement du ressort personnel et pas du système de VCS?) bonjour, puisque ce doit être le bazard, voici le lien : http://fr.wikipedia.org/wiki/Darcs http://www.darcs.net/ slt bernard -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430174457.7be7b35f.bernard.schoenacker_free.fr@hamtaro
Re: versioning system (VCS)
On Sat, 30 Apr 2011 17:21:03 +0200
Jean-Yves F. Barbier 12u...@gmail.com wrote:
Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à
la fin, soit le fichier final correspond à mes attentes, soit je pioche dans
plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai
pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie
du dev est peut-être uniquement du ressort personnel et pas du système de
VCS?)
Les branches de GIT sont faites pour ça (et les tags aussi). On peut
vraiement en avoir beaucoup (même si personnellement je les utilise
peu). Donc il me semble que c'est ton point de vue qui pourrait
changer: tu pourrais raisonner non pas en termes de fichiers
individuels, mais en terme d'arborescence complète, et alors c'est
exactement ce que permet les branches de GIT (il parait que tu pourrais
en avoir des millions).
Moi au contraire, dans mes développements personnels (seulement), je ne
raisonne pas comme ça, et je reviens rarement en arrière (même si ça
peut m'arriver) et j'ai donc peu de branches. Par contre, pour un
développement communautaire, les branches me paraissent essentielles.
Mon impression sur GIT c'est que c'est un outil *très* puissant, et
qu'il y a plusieurs façons *très* différentes de s'en servir. A toi de
découvres quelle manière de l'utiliser correspond à tes besoins.
Par contre, GIT comme SVN raisonnent plutôt en terme de versionnement
d'une arborescence entière, pas de fichiers individuels (comme le
faisaient RCS ou CVS ou SCCS), et je crois que c'est un progrès
essentiel. Un fichier isolé a rarement du sens, il s'inscrit dans un
contexte qui est précisément l'arborescence manipulée.
Cordialement
PS. Il faut quand même noter que la notion de versionnement et de chose
versionnée varie sensiblement d'un versionneur à un autre. Les concepts
sont différents, et donc aussi la terminologie!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet 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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110430174800.07791a67.bas...@starynkevitch.net
Re: versioning system (VCS)
Jean-Yves F. Barbier 12u...@gmail.com writes: On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy ple...@debian.org wrote: je conseille aussi Git. Il est facile de récupérer une ancienne version d'un fichier seulement, avec la commande « git checkout ». http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one-file Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je souhaite pouvoir revenir en AR d'un nombre _quelconque_ de révisions sur n'importe quel fichier git checkout permet de revenir à n'importe qu'elle version du fichier: $ git checkout commit -- file récupère le fichier file dans la version ou il se trouvait à l'époque du commit commit (on parle de commit avec git plus que de révisions). En plus git possède des interfaces graphique comme gitk ou giggle qui permette (entre autre) de ne regarder que les commits où un certain fichier a évolué. Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à la fin, soit le fichier final correspond à mes attentes, soit je pioche dans plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie du dev est peut-être uniquement du ressort personnel et pas du système de VCS?) git permet certainement de faire ça. Dans ce genre de cas ma méthode est de faire 36 branches correspondants au différentes idée que j'ai pour résoudre le problème, et je choisi celle qui me va à la fin, mais c'est certainement pas la seul façon de faire. -- Rémi Vanicat -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/87oc3n68as@debian.org
Re: versioning system (VCS)
On Sat, 30 Apr 2011 17:48:00 +0200, Basile Starynkevitch bas...@starynkevitch.net wrote: On Sat, 30 Apr 2011 17:21:03 +0200 Jean-Yves F. Barbier 12u...@gmail.com wrote: Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à la fin, soit le fichier final correspond à mes attentes, soit je pioche dans plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie du dev est peut-être uniquement du ressort personnel et pas du système de VCS?) Les branches de GIT sont faites pour ça (et les tags aussi). On peut vraiement en avoir beaucoup (même si personnellement je les utilise peu). Donc il me semble que c'est ton point de vue qui pourrait changer: tu pourrais raisonner non pas en termes de fichiers individuels, mais en terme d'arborescence complète, et alors c'est exactement ce que permet les branches de GIT (il parait que tu pourrais en avoir des millions). Le soucis c'est que je ne suis un programmeur pro, je cherche juste à créer le pgm qui me manque afin qu'il soit exactement comme je veux, ce qui prend en Gal pômal de temps (et explique les retours en AR.) Ce que tu dis est malheureusement ce que j'avais compris lors de différents tests: tu est limité à toute l'arborescence, sans pouvoir descendre au niveau fichier, à moins que de rétablir *toute* la branche antérieure voulue - ce qui ne correspond pas à mes attentes (juste un fichier par-ci par-là.) -- Take that, you hostile sons-of-bitches! -- James Coburn, in the finale of _The_President's_Analyst_ -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430180705.30413477@anubis.defcon1
Re: versioning system (VCS)
On Sat, 30 Apr 2011 17:57:47 +0200, Rémi Vanicat vani...@debian.org wrote: ... git checkout permet de revenir à n'importe qu'elle version du fichier: $ git checkout commit -- file récupère le fichier file dans la version ou il se trouvait à l'époque du commit commit (on parle de commit avec git plus que de révisions). Ha, meilleur! Pour être sur d'avoir bien compris: $ git checkout a8445d2551ca45ef -- monfichieramoiquejeveuxdanscecommit et ça roule? En plus git possède des interfaces graphique comme gitk ou giggle qui permette (entre autre) de ne regarder que les commits où un certain fichier a évolué. Je n'avais testé que gitk, je vais retester avec giggle Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à la fin, soit le fichier final correspond à mes attentes, soit je pioche dans plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie du dev est peut-être uniquement du ressort personnel et pas du système de VCS?) git permet certainement de faire ça. Dans ce genre de cas ma méthode est de faire 36 branches correspondants au différentes idée que j'ai pour résoudre le problème, et je choisi celle qui me va à la fin, mais c'est certainement pas la seul façon de faire. ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de toutes les modifs d'un fichier jusqu'au commit final) -- Thank God I've always avoided persecuting my enemies. -- Adolf Hitler -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430181202.61e3ae92@anubis.defcon1
Re: versioning system (VCS)
Le 30 avril 2011 18:12, Jean-Yves F. Barbier 12u...@gmail.com a écrit : On Sat, 30 Apr 2011 17:57:47 +0200, Rémi Vanicat vani...@debian.org wrote: ... git checkout permet de revenir à n'importe qu'elle version du fichier: $ git checkout commit -- file récupère le fichier file dans la version ou il se trouvait à l'époque du commit commit (on parle de commit avec git plus que de révisions). Ha, meilleur! Pour être sur d'avoir bien compris: $ git checkout a8445d2551ca45ef -- monfichieramoiquejeveuxdanscecommit et ça roule? En plus git possède des interfaces graphique comme gitk ou giggle qui permette (entre autre) de ne regarder que les commits où un certain fichier a évolué. Je n'avais testé que gitk, je vais retester avec giggle Il y a aussi gitg (rapide) et beaucoup d'autres pour environnement KDE. A noter le fameux tig : un navigateur Git en curses, c'est à dire une interface graphique textuelle. Il est extrèmement rapide. Concernant l'exploration de l'historique d'un seul fichier, beaucoup d'outils reprennent les principes des outils de ligne de commande de Git : _ma_commande_git_ --- mon/fichier Par exemple, tig fonctionne ainsi. Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à la fin, soit le fichier final correspond à mes attentes, soit je pioche dans plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie du dev est peut-être uniquement du ressort personnel et pas du système de VCS?) git permet certainement de faire ça. Dans ce genre de cas ma méthode est de faire 36 branches correspondants au différentes idée que j'ai pour résoudre le problème, et je choisi celle qui me va à la fin, mais c'est certainement pas la seul façon de faire. ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de toutes les modifs d'un fichier jusqu'au commit final) En fait, il faut voir Git comme un outil de très bas niveau. Linus lui même se défend d'avoir créer un VCS, plutôt un outils pour construire de VCS. Ainsi, la très grosse difficulté de Git correspond à la question que tu as posé à très juste titre : de quelle manière est-ce que je vais utiliser Git pour améliorer mon organisation. Pour cela, malheureusement, il faut à la fois connaître Git et être clair sur ton organisation actuelle. Ensuite, tu peux utiliser Git comme il faut. Bref, tout ça pour dire qu'il faut certainement que tu te lances dans l'aventure, pour essayer, découvrir. Et surtout, fait des sauvegardes avant de lancer des commandes dont tu doute du résultat. Pour les sauvegardes, tu peux faire des git clone pour copier tout l'historique, ou simplement des git archive pour garder un instantané de ton projet. Enfin, sans remettre en doute la compétence des inscrits à cette liste, si l'anglais ne te dérrange pas trop, je t'invite à aller sur la liste de discussion de Git. Malgré son nom en devel c'est sur cette liste que le support est apporté aux nouveaux. Bon courage. -- Guilhem BONNEFILLE -=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com -=- mailto:guilhem.bonnefi...@gmail.com -=- http://nathguil.free.fr/ -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinwe00VbrQVqxnEGYc3=_9jyge...@mail.gmail.com
Re: versioning system (VCS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 30/04/2011 16:10, Bernard Schoenacker a écrit : est il possible de savoir si les clients sont win32 ou uniquement GNU ... Git est un vrai bordel à installer «proprement» sous win. Pour un DSCM à la fois Linux et Windows, j'aurais tendance à plutôt partir sur du Mercurial, surtout si c'est pour le moment du dev en local qui peut migrer sur du dev distant. SVN est globalement à éviter. Même s'il reste extrèmement utilisé (mais pour des raisons historiques et non de performances), il montre les limites des «mauvais» choix techniques utilisés (matérialisation des tags et des branches, faibles performances sur les branch/merge, utilisation d'un serveur centralisé…). Autre problème, le manque flagrant d'amélioration des fonctionnalités (comme l'amélioration de la gestion des rename/move qui est extrèmement problématique) depuis un long moment déjà. - -- Aeris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNvDRoAAoJEK8zQvxDY4P9e7oH/A5qCBKqRjD0h3AGzXMnxoll 9ocmE8V4WwDLiohWahLm8no+Hr2UiYRJAH3m24g7Q3OIuQpQBOA1BApjR3ZOS2WR aEmUXRy/S3U8bdPM9NAhzFQqgkTTxrS/0vH56SLgJBk2/bFJ2kzar0eBpBtChCNF R7tNuQGHpkn6JCrh6b/bJBQ3w5mNdnh6gEyZ5P+emRua2csG8jX1SW3Ut3B18M2u R86nCjR3mbnrt6linTsWoZd3pGb2CWI0segbpgadt+NEFMWnkmCY4Vb8bmV66llZ VrnPXrtZb6a0YdpPnH3sZC6Q5Lxrp0L1YKBe72LHYlEPsCc6JM1JOpyLzkUIzb8= =rIUl -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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4dbc346e$0$4860$426a7...@news.free.fr
Re: versioning system (VCS)
On Sat, 30 Apr 2011 17:50:08 +0200 Jean-Yves F. Barbier 12u...@gmail.com wrote: parce que je procède en tâtonnant, et que des fois il m'est arrivé de modifier un fichier et de m'apercevoir qu'une des versions précédentes était meilleure Il me semble que tu as trop d'a priori sur ta façon de faire (et surtout sur la terminologie). Il est possible que GIT permette de satisfaire exactement ce besoin là, mais de manière différente et avec une terminologie différente. J'ai l'impression que tu pourrais voir ton souhait exaucé simplement en faisant très souvent des branches ou des tags (et tu peux créer sous GIT une branche en partant par exemple de l'état d'il y a une semaine de ta branche courante, tu n'as donc pas besoin de prévoir à l'avance ce que tu ferais) et en considérant que tu fusionnes (merge) partiellement des branches, ce que GIT sait faire très bien (mais ce que je fais rarement, et donc que j'aurais du mal à expliquer en détail) A mon avis, tu n'as pas assez expliqué ton besoin, et surtout le genre de projet pour lequel tu veux un versionneur. Si on tente de deviner en aveugle, on ne peut pas aider. C'est un ERP écrit en python (parce que malheureusement, le port de wx dans wxLUA n'a pas intégré le côté virtuel des fonctions que j'utilise le plus, comme wxCtrlList) Et en quoi ceci t'oblige à voir ton projet comme un jeu de fichiers versionnés isolément, plutôt que comme une arborescence versionnée (et branchée souvent)? Je me sers (trop) rarement des branches de GIT, mais il me semble qu'on peut facilement et à coût très faible en avoir vraiement plein (et les fusionner ensemble avec finesse) et que ça devrait résoudre ton besoin. Par contre, il ne faut plus penser en terme de versionneemnt de fichiers isolés. Moi, j'aurais peur de me perdre avec beaucoup de branches (et donc c'est à cause de ma petite tête que j'en limite le nombre), mais si tu veux en avoir des milliers ou même plus GIT sait faire. Le point important, c'est que branche ou version signifie des choses *très* différentes d'un versionneur à un autre, et il faut comprendre un peu les concepts cléfs d'un versionneur avant de l'utiliser. Je n'arrive toujours pas à comprendre pourquoi tu imagines ton projet devoir être versionné fichier par fichier indépendamment... Un projet de développement logiciel, c'est toujours le versionnement d'une arborescence toute entière [avec peut-être une exception quand des données sont dans autre chose qu'un fichier, par exemple dans une base de données comme MySQL ou PostGresQL; mais même dans ce cas, on se ramenerait à des fichiers en considérant qu'on versionne l'état dumpé d'un SGBD. Bien sûr, ça passe moins à l'échelle, mais on versionne rarement une base de données d'un tera octet, et quand on voit les choses comme ça, c'est peut-être dans la base elle même qu'on stocke les versions variées de ses objets]. Mon impression vague serait que tu devrais reconsidérer ton besoin en l'exprimant autrement... Peut-être qu'en discutant dans un forum dédié à GIT ta façon de faire tu aurais des réponses plus précises... Je n'ai pas du tout compris pourquoi ton besoin des fois il m'est arrivé de modifier un fichier et de m'apercevoir qu'une des versions précédentes était meilleure implique de versionner les fichiers isolément... Pourquoi ne vois tu pas ton besoin comme le souhait de fusionner, intelligemment et partiellement, des branches différentes? Es tu sûr de versionner des fichiers isolément (ça me semble une hérésie digne de CVS ou RCS) et non pas de versionner une arborescence entière ??? Moi j'ai l'impression que dans mes développements il m'arrive aussi de tatonner et de m'apercevoir qu'une des versions précédentes d'un fichier était meilleure, mais je regarde ça en terme d'arborescence (et peut-être d'extraction ou de fusion partielle de quelques fichiers isolés entre branches). Bref, je ne comprends pas du tout cette idée de versionner des fichiers individuellement. Pour moi, c'est hélàs ce que faisait RCS ou SCCS (et même CVS) -ils ne savaient versionner que des fichiers, c'était un défaut rédhibitoire- alors que tous les versionneurs actuels savent (avec raison) versionner des arborescences entières!!! Ma vague intuition est que ton point de vue est trop restrictif: le versionnement [de sous-ensembles] d'arborescences entières de fichiers est strictement plus puissant que le versionnement individuel de fichiers. Il me semble que changer de point de vue (sans changer ta façon de travailler) suffirait à te faire accepter un versionneur récent. (Il faut juste comprendre que version et branche et parfois même arborescence désignent des concepts différents de ce qu'on croit parfois imaginer). Par analogie, c'est un peu comme si tu ne voulais pas avoir des répertoires, mais que tu tenais à travailler avec seulement des fichiers (comme sur disquettes à l'époque des débuts de MS-DOS). Si tu y tiens, tu peux travailler dans un seul répertoire et y retrouver un feeling
Re: versioning system (VCS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 30/04/2011 18:10, Jean-Yves F. Barbier a écrit : Ce que tu dis est malheureusement ce que j'avais compris lors de différents tests: tu est limité à toute l'arborescence, sans pouvoir descendre au niveau fichier, à moins que de rétablir *toute* la branche antérieure voulue - ce qui ne correspond pas à mes attentes (juste un fichier par-ci par-là.) Le concept de branche est attaché à une arborescence mais tout système de version digne de ce nom est capable de revenir sur un seul fichier à n'importe quelle version antérieure de n'importe quelle branche (update ou même directement export). Après, j'ai du mal à imaginer un cas d'utilisation qui demanderait d'utiliser cette fonctionnalité de manière massive et j'aurais tendance à dire que cela relève plus du domaine des mauvaises pratiques de développement que d'autre chose. - -- Aeris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNvDlXAAoJEK8zQvxDY4P9YssH/2CdjtMGRUkmhdEtuLNrMzn/ oChGmPCxS896reea22H0GD7BYAb9hstJtgNJhNjH01W9HfiJWzyidl6fB3GXhwW4 USyW3n3NoOyaRrqPQYZBMaj3+qcqsXvEMWZGKGYJbgWwCPxmhwstqlEjOnAxSqA1 7TJGyS7DrobRZG5DJ5L4cUKFqqsjhe03pSeGl1YipWkjAg6/KrLF1XbocZN1PZAh kGJwurE3loC6MxVW1t2LWkJ6ADimng0VIV28A7tZoURDcRQ/74NGdw3l3WFKU4qE iHLdRm4QSL2dJcgUsZ9Rx5Qdgy9hK4u4dmHYfcg+H6ReGZy9SU5iG2P1M4NU2es= =gqtC -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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4dbc395d$0$25564$426a3...@news.free.fr
Re: versioning system (VCS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit : ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de toutes les modifs d'un fichier jusqu'au commit final) Non, tu veux garder les traces de tous les commits d'un fichier jusqu'au tag final =) Tout SCM aura besoin que tu commites tes fichiers pour en suivre les modifications. Il n'y a pas de sauvegarde en temps réel (sauf à être sur du VMS :þ). - -- Aeris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNvDn0AAoJEK8zQvxDY4P9YLEH/0n3KYWTBkpB8HUmFyyo6gpu 2NlkEyyZG8HWO8rlKUlwOWiqNzQ+1yvKLrM5Hk5VYCqZjKPmybCQoqK+ryRjqmZ0 AmxJP8nwz9PZL9Qt5YayZBQEXM/8VAlPkYEzWlKcxyjoWOdXkLJFXsGMmGdGL1sA yZnl/sfK0mUWiC9MSUA0/S7b27+FnkZbH/s7whNxdD7BVRPEPm/ROIPCDVmUc7jC qjnL7+teG/3/w9aTLy94MBsonpOAvL4INIdnahpytsP9h0d09hTpga2GVbvnC/qS FTVodvZNHMZHjSun0cRVQFNvhBRPmCK1IzMIWVNPqLPFIqAHp51B1qoinP4WHhc= =ksiu -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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4dbc39f4$0$25564$426a3...@news.free.fr
Re: versioning system (VCS)
Le Sat, 30 Apr 2011 18:10:22 +0200, Aéris ae...@imirhil.fr a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 30/04/2011 16:10, Bernard Schoenacker a écrit : est il possible de savoir si les clients sont win32 ou uniquement GNU ... Git est un vrai bordel à installer «proprement» sous win. Pour un DSCM à la fois Linux et Windows, j'aurais tendance à plutôt partir sur du Mercurial, surtout si c'est pour le moment du dev en local qui peut migrer sur du dev distant. SVN est globalement à éviter. Même s'il reste extrêmement utilisé (mais pour des raisons historiques et non de performances), il montre les limites des «mauvais» choix techniques utilisés (matérialisation des tags et des branches, faibles performances sur les branch/merge, utilisation d'un serveur centralisé…). Autre problème, le manque flagrant d'amélioration des fonctionnalités (comme l'amélioration de la gestion des rename/move qui est extrêmement problématique) depuis un long moment déjà. - -- Aeris Bonjour, j'ai demandé qui participait avec son système d'exploitation afin de définir exactement le gestionnaire CVS ou équivalent et pouvant rester le plus constant quelque soit l'utilisateur connecté avec un client quelconque. une fois l'ensemble des paramètres ainsi définis il ne reste plus qu'à trouver le bon outil reste à trouver le greffon pour gecko ou équivalent. cqfd slt bernard -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430190004.5ba662c8.bernard.schoenacker_free.fr@hamtaro
Re: versioning system (VCS)
Le Sat, 30 Apr 2011 18:33:56 +0200, Aéris ae...@imirhil.fr a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit : ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de toutes les modifs d'un fichier jusqu'au commit final) Non, tu veux garder les traces de tous les commits d'un fichier jusqu'au tag final =) Tout SCM aura besoin que tu commites tes fichiers pour en suivre les modifications. Il n'y a pas de sauvegarde en temps réel (sauf à être sur du VMS :þ). - -- Aeris bonjour, es tu sûr de ne pas parler de la versio nlibre de VMS ? lien : http://fr.wikipedia.org/wiki/OpenVMS reste à trouver la branche pour GNU ... solution : http://www.wherry.com/gadgets/retrocomputing/vax-simh.html slt bernard -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430191514.63aa4695.bernard.schoenacker_free.fr@hamtaro
Re: versioning system (VCS)
On Sat, 30 Apr 2011 18:33:56 +0200
Aéris ae...@imirhil.fr wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 30/04/2011 18:20, Jean-Yves F. Barbier a écrit :
ben d'après ce que j'ai compris, si (enfin si je veux garder les traces de
toutes les modifs d'un fichier jusqu'au commit final)
Je confirme. Et d'ailleurs, c'est une règle de base dans les gros
projets collaboratifs (comme GCC). On commit des *petites*
modifications, souvent de quelques lignes ou douzaines de lignes.
Par exemple, sur GCC (versionné avec SVN), il y a 173221 commits depuis
son origine (dans les années 1985?). Et les 5 derniers (obtenus par
svn log --limit 5) sont!
0
r173221 | burnus | 2011-04-30 18:33:47 +0200 (Sat, 30 Apr 2011) | 8 lines
2011-04-30 Tobias Burnus bur...@net-b.de
PR fortran/48821
* gfortran.dg/import9.f90: New, proper test.
* gfortran.dg/interface_37.f90: Remove bogus
test (bogus copy of interface_36.f90).
r173220 | dougkwan | 2011-04-30 18:26:23 +0200 (Sat, 30 Apr 2011) | 6 lines
2011-04-30 Doug Kwan dougk...@google.com
* include/Makefile.am (install-freestanding-headers): Also install
cxxabi_tweaks.h.
* include/Makefile.in: Regenerate.
r173219 | burnus | 2011-04-30 17:54:49 +0200 (Sat, 30 Apr 2011) | 12 lines
2011-04-30 Tobias Burnus bur...@net-b.de
PR fortran/48800
* decl.c (gfc_match_import): Don't try to find the
symbol if already found.
2011-04-30 Tobias Burnus bur...@net-b.de
PR fortran/48800
* gfortran.dg/interface_37.f90: New.
r173217 | dnovillo | 2011-04-30 17:20:58 +0200 (Sat, 30 Apr 2011) | 31 lines
cp/ChangeLog
2011-04-29 Le-Chun Wu l...@google.com
* cp-tree.h (LOOKUP_EXPLICIT_TMPL_ARGS): Define.
* call.c (build_new_function_call): Set it for TEMPLATE_ID_EXPRs.
(build_over_call): Use it to determine whether to emit a NULL
warning for template function instantiations.
(build_new_method_call): Set LOOKUP_EXPLICIT_TMPL_ARGS if
EXPLICIT_TARGS is set.
2011-04-29 Diego Novillo dnovi...@google.com
Le-Chun Wu l...@google.com
* call.c (conversion_null_warnings): Also handle assignments
when warning about NULL conversions.
testsuite/ChangeLog
2011-04-29 Le-Chun Wu l...@google.com
* g++.dg/warn/Wnull-conversion-1.C: New.
* g++.dg/warn/Wnull-conversion-2.C: New.
2011-04-29 Le-Chun Wu l...@google.com
* g++.dg/warn/Wconversion-null-2.C: Do not expect a NULL
warning in implicitly instantiated templates.
2011-04-29 Diego Novillo dnovi...@google.com
* g++.old-deja/g++.other/null3.C: Expect warning about converting
boolean to a pointer.
r173216 | hubicka | 2011-04-30 16:08:03 +0200 (Sat, 30 Apr 2011) | 5 lines
* ipa-inline.c (can_inline_edge_p): Disregard limits when
inlining into function with flatten attribute.
(want_inline_small_function_p): Be more realistic about inlining
cold calls where callee size grows.
Le dernier commit de cette liste (r173216) est le patch ci-dessous
(je ne donne pas le patch du ChangeLog, il est ci dessu).
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c(revision 173215)
+++ gcc/ipa-inline.c(revision 173216)
@@ -272,9 +272,11 @@
FIXME: this is obviously wrong for LTO where STRUCT_FUNCTION is missing.
Move the flag into cgraph node or mirror it in the inline summary. */
else if (DECL_STRUCT_FUNCTION (e-callee-decl)
- DECL_STRUCT_FUNCTION
(e-callee-decl)-can_throw_non_call_exceptions
+ DECL_STRUCT_FUNCTION
+ (e-callee-decl)-can_throw_non_call_exceptions
!(DECL_STRUCT_FUNCTION (e-caller-decl)
-DECL_STRUCT_FUNCTION
(e-caller-decl)-can_throw_non_call_exceptions))
+DECL_STRUCT_FUNCTION
+(e-caller-decl)-can_throw_non_call_exceptions))
{
e-inline_failed = CIF_NON_CALL_EXCEPTIONS;
inlinable = false;
@@ -288,6 +290,11 @@
}
/* Check if caller growth allows the inlining. */
else if (!DECL_DISREGARD_INLINE_LIMITS (e-callee-decl)
+ !lookup_attribute (flatten,
+DECL_ATTRIBUTES
+ (e-caller-global.inlined_to
+ ? e-caller-global.inlined_to-decl
+ : e-caller-decl))
Re: versioning system (VCS)
On Sat, 30 Apr 2011 19:25:50 +0200, Basile Starynkevitch bas...@starynkevitch.net wrote: Je confirme. Et d'ailleurs, c'est une règle de base dans les gros projets collaboratifs (comme GCC). On commit des *petites* modifications, souvent de quelques lignes ou douzaines de lignes. Par exemple, sur GCC (versionné avec SVN), il y a 173221 commits depuis son origine (dans les années 1985?). Et les 5 derniers (obtenus par svn log --limit 5) sont! Effectivement, ça fait bcp! Comme tu peux le voir, les développeurs de gcc commettent des petits patchs le plus souvent (quelques dizaines de lignes modifiées par commit). Il peut arriver que la description du commit (c'est à dire l'entrée dans un ChangeLog) soit presque aussi grosse que le changement commis. C'est aussi dû à la règle sociale de GCC: on ne peut y commettre que du code qui a été revu et approuvé par autrui. Et même sur un développement où je suis tout seul, je commite plusieurs fois par jour. Le temps entre deux commit, c'est le temps élémentaire 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? 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? ;-) 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) -- Colorado: Where they don't buy M M's, 'cause they're so hard to peel. -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430194505.22e76aa3@anubis.defcon1
Re: versioning system (VCS)
On Sat, 30 Apr 2011 19:45:05 +0200
Jean-Yves F. Barbier 12u...@gmail.com wrote:
Et même sur un développement où je suis tout seul, je commite plusieurs
fois par jour. Le temps entre deux commit, c'est le temps élémentaire
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-donné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 versionneur.
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: basileatstarynkevitchdotnet 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
Re: versioning system (VCS)
-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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4dbc4e36$0$19739$426a7...@news.free.fr
Re: versioning system (VCS)
On Sat, 30 Apr 2011 20:00:22 +0200, Aéris ae...@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) -- 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430205937.0c19991d@anubis.defcon1
Re: versioning system (VCS)
On Sat, 30 Apr 2011 20:59:37 +0200
Jean-Yves F. Barbier 12u...@gmail.com wrote:
On Sat, 30 Apr 2011 20:00:22 +0200, Aéris ae...@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éfinition
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ébutants
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: basileatstarynkevitchdotnet 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-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110430212340.e5b016a3.bas...@starynkevitch.net
Re: versioning system (VCS)
-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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4dbc6280$0$24553$426a7...@news.free.fr
Re: versioning system (VCS)
-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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4dbc63a6$0$19044$426a3...@news.free.fr
Re: versioning system (VCS)
On Sat, Apr 30, 2011 at 09:31:50PM +0200, Aéris ae...@imirhil.fr 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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430211352.ga3...@sources.org
Re: versioning system (VCS)
On Sat, Apr 30, 2011 at 08:00:22PM +0200, Aéris ae...@imirhil.fr wrote a message of 34 lines which said: Un SCM ne stocke que des diff, pas les fichiers complets. Ça n'est absolument pas obligatoire. http://www.bortzmeyer.org/time-and-space-in-vcs.html -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20110430211446.gb3...@sources.org
Re: versioning system (VCS)
-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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4dbc7f49$0$19123$426a7...@news.free.fr
Re: versioning system (VCS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 30/04/2011 23:20, Stephane Bortzmeyer a écrit : Ça n'est absolument pas obligatoire. http://www.bortzmeyer.org/time-and-space-in-vcs.html Certes mais c'est très fortement conseillé? - -- Aeris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNvH3DAAoJEK8zQvxDY4P9sqAH/158BwfH2JTUlwVAyGQrrbX2 /8N+vuUGCRpkf13i1qX6oV6bdL5GHaSA4KYHXs/7xlVMDNl2KMRgsAaByRnOPdY1 HH/frKQWfGBWURFnbILrxBQvNuC2RqHHDHNVaiTltHUf3vtYrryR7K4pxFRJyV6F YKHtPfhq1dmNZwbIrJLNTWBoIcaby9YWnjUxvVNd/boe+CFaMBkvjfXk1bU4VnOl 6PZHHq+vcBgW2s0OYtuF9/KmRAOPRTSP8X2rnjGNO3mrK4DwIQfqQOVLRqpHoi9s d97vpUibggXJvJNnx/h/PnGR/Ri9Uf3+aLqGwiQpMOnbsjXRY3I6zQVi9OkTqkI= =ekoT -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 debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4dbc7dc8$0$14999$426a7...@news.free.fr
