Re: versioning system (VCS)
On Sat, 30 Apr 2011 19:25:50 +0200, Basile Starynkevitch
<basile@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.
Reply to: