Re: versioning system (VCS)
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 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: 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} ***
Reply to: