Forum Programmation.autre Cherche moyen d'identifier l'auteur des lignes d'un code source dans un dépot SVN

Posté par  .
Étiquettes : aucune
0
25
sept.
2007
Je recherche un moyen d'identifier l'auteur d'une/plusieurs ligne(s) de code source dans un dépot SVN (que je contrôle).

Quelqu'un connaîtrait-il un moyen d'y arriver ?

Mon but est de connaître, à un instant T, la proportion du code source issue de chaque contributeur.
Il y a un outil dans TortoiseSVN qui permet d'afficher les statistiques sur (combien de commit par auteur) et/ou (graphe du nombre de commit par auteur), mais rien sur l'identification de la ligne de code et/ou du nombre de ligne de code par auteur.

Je sais qu'un auteur peut très bien ajouter un espace après chaque "if" dans un code existant et ainsi voir son nombre de lignes attribuées augmenter, mais malgré tout ce serait un bon début.

Merci

  • # Tadaaaa !

    Posté par  . Évalué à 3.

    svn blame <nomdufichier>
    Ou la commande blame dans Tortoise

    De rien.

    • [^] # Re: Tadaaaa !

      Posté par  . Évalué à 1.

      Merci bcp.

      Je vais pousser le bouchon, mais pour en faire des statistiques ?
      Genre, faire un blame "general" sur tous les fichiers, puis compter le nombre de ligne de code non vide par utilisateur ?

      C'est probablement possible de faire ça avec un script python, mais si la fonction existe déjà, je suis preneur.

      • [^] # Re: Tadaaaa !

        Posté par  . Évalué à 1.

        find mon_rep/ -type f | while read f ; do svn blame $f | awk '{print $2}' ; done | sort | uniq -c

  • # productivité != nombre de lignes

    Posté par  . Évalué à 1.

    J'espère que tu es conscient que le "nombre de lignes" n'est pas une métrique particulièrement pertinente... entre le programmeur qui fait des dizaines de copier-coller inutiles, et celui qui factorise efficacement du code, elle est même à l'envers.

    • [^] # Re: productivité != nombre de lignes

      Posté par  . Évalué à 1.

      Par exemple:

      #define/**/F/***/for/*A*/
      #define/***/H()f=*E<<4|*E,f=~(f|f<<1|E[3]|E[1]|E[1]<<4|E[2]|E[(2)]<<(1));
      #define/***/I(x,d)F(;s;C()){s=s^(b=s&s-1^s);F(N[4]=q=0;q<4;q++)N[q]=E[q];N[5]=E-B;N[d]^=+b^(b)x;}
      #define/**/o(p,t,i,m,a,l)u=(f&p)i(m) ;s=u&E[3];I(t(m),3)s=(u)a &E[l];I(t(m),l)u=u>>5-m &u;s=u&E[3-l];I(t(m),3-l) s=(u)a&*E;I(t(m),(0));
      char*A=0,*_,*R,*Q, D[9999],*r,l[9999],T=42, M,V=32;long*E,k[9999],B[1 <<+21],*N=B+1234567,q=0, h=3,j=2,O,b,f,u,s,c,a,t,e ,d;C(){F(h=N[3];(B[h]&&+ memcmp(N,B+B[h],16));h=B[ h]+4);B[h]||(B[h]=N-B,N= N+6);}main(char*U,int*w[] ){
      F(_=A=D+6666,A[fread (A,1,3333,fopen(__FILE__, "r"))]=0;*++_;h||(*_=V)) *_-59|_[1]-* _||(h&&(*_=+ 35),h---2||(_[9]=V));
      F(_=A;*_;_++)10 -*_&&*_-V&&( *_-92)&&(k[q]=isalnum(l[q]=*_),q++);M =47;*(E=N-6) =64;E[1]=289;E[2]=270336;F(E[3]=32782 ;E<N;E=E+6){ H()o(1048560,<<,>>,4,>>4,1)o(+489335, >>,<<,1,,2)o (978670,<<,>>,1,>>1,2)o(+65535,>>,<<, 4,,1)
      if(8192 &*E){F(N=B;E>B;E=B+E[5])*N++=E-B;F(;N >B;){h=*(E=B +*--N);H()s=~(E[1]|h|h<<1);u=~(E[2]|h |h<<4);r=l;_ =D;d=1;a=2;O=8;F(q=74;q;q--){F(b=0;b< 72;b++){h=+1 <<(q-1)/14*4+(b-1)/18;j=b?(!(b%18)&&u &h)|h&f|(!(q%14)&&s&h)?1:0:2;
      if(O<3)O ?j?j-1&&(O-2 &&d--,*R=34,O=2):(*_++=O-2?l[d]?l[d++ ]:(d=t,O=e=3 ,34):(O=1,34)):j||(*_++=d<t?l[d++]:(O =1,d=0,34)); else{if(O<6)if(j){j-2|e||(_=R,O-4?d-- :M-_[-1]||(_ [-1]=l[d++],O=3));c=0;
      if(k[d]&k[d-1]) F(;k[d-1];++ c)d--;!d||((h=l[d])^l[d-1])+k[d]||!(+ 40-(h&62)&&h -125)||(c=1,d--);c-1||(c=2,d--);c&&(_ [-c]=M,_[1-c ]=T,O=4);j-2|e||(*_++=+92);}
      else{h=*_ ++=O-4?O-5?l [d++]:(O=3,M):(O=5,T),(_[-1]&&(35-h|| !(a=+1)))||( O=7,*(R=Q=_-(1))=M);}else{j?O-7||(O=6,_[-1]=59):( *_++=a-2?O-6 ?O-7?126&*++ r:(O=8,T):(O=7,M):(a=0,l [d]-100?(e=1 ,O=0):(e=0,O =3,35)));
      if(e==1){F(r=A= l+d;35-*A;++ A)*A-M&&*A-T ||U-1&&(*A=V);d=d+A-r;if (U-1){*A=0;F (j=2;13499>j &&(sprintf(l,r+1,j,j,O=j +75,w[1]),j= O,!system(l) ););exit(j<+13499);}t=d+ 9;_[-1]=l[++ d];}a-1|+j-2
      ||(R-Q<3?(*(Q<R?R-1:R)=* Q=*R=59):(*R =M,R[-1]=T), a=2);}}j?(*_++=j-2?V:10, R):(R=_-1);} }R[-1]=T;*R= M;*_++=10;F(R=D;putchar( *R)&&_>++R;) ;}}};O-b-f-u -s-c-a-t-e;}

      C'est super bien factorisé (13 lignes), et donc si on suit la logique, ce code sera très facilement comprehensible (facile, c'est un jeux d'échec).

      Je suis d'accord que le nombre de ligne n'est pas la métrique idéale.
      C'est pour cela que la plupart des logiciels de statistique de code compte le nombre de ligne de code, le nombre de ligne de commentaire, la présence d'une ligne de commentaire corrélée avec du code, etc...

      Comme je le disais dans la première question, un dév qui ajouterait un espace à chaque ligne deviendrait "le propriétaire" de la ligne, et donc fausserait les stats.
      Je pense simplement que sur un (vrai) projet, où les patchs sont analysés avant d'être committed, ce genre de cas n'arrive pas (comme le cas du dev qui ecrit toutes ses lignes sur une largeur de colonne de 20).

      La solution idéale, c'est que quelqu'un se cogne la lecture du code, comptabilise chaque ligne avec une note (suivant si elle est logique, commentée, testée, etc...). Malheureusement, je crois pas qu'il soit possible d'en arriver là.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.