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