Salut à tous,
Bon je vais reprendre du service sur Ranch. Comprendre que je vais
tenté de le finir avant la nouvelle année.
Alors, tout d'abord un petit rappel sur ce qu'est Ranch (Regression
Benchmark). Il a pour but de stocker tous les résultats des bench d'un
projet pour chaque révision dans une BD en vue d'en tirer des graphes.
Il se compose de 3 éléments:
- une bibliothèque de bench (language dependent) pour le C++ seulement
pour le moment. Elle fournit quelque routine pour faire les benchs de
base et sortir les résultats dans le format de Ranch. Elle est fini
depuis l'année dernière, il ne reste plus qu'à rajouté un système pour
bencher l'utilisation de la mémoire de façon non intrusive.
- une BD SQL dont le format des tables et à peu près figé.
- une appli web pour visualiser les graphes.
Ce qui va changer:
- plus d'appli web. C'est la principal raison du retard pris par ce
projet car même si c'est sexy d'avoir une appli web, c'est plus long à
développer Donc j'abandonne cette voie et à la place il y aura un
programme en ligne de commande pour tracer les courbes. En plus vu,
qu'il y a une build farm maintenue au labo, ça s'intégrera plus
facilement et ça évitera de faire double emploie.
- Pour le moment les résultats sont craché soit en YAML soit en XML,
je pense que je vais garder que le XML parce que ça sert à rien d'en
avoir deux.
Une fois ranch terminé, il faudra:
- faire une page dans la build farm qui en appellant le script de
tracé de graphe affiche les courbes relatives à un projet.
- écrire des benchs qui dans les projets du labo en s'appuyant sur la
bibliothèque fournit par ranch.
Je m'occupe de tout ce qui est ranch, mais je réclame un peu d'aide
pour l'intégration dans la build farm et l'écriture des benchs pour
les différents projets car je ne suis pas le plus qualifié pour le
faire vite et bien.
Voilà, des remarques ?
--
Nicolas Desprès
>>> "Nicolas" == Nicolas Pouillard <nicolas.pouillard(a)gmail.com> writes:
> On 12/13/05, Akim Demaille <akim(a)lrde.epita.fr> wrote:
>>
>> vcs-svn diff, à la différence de svn diff, liste les changements dans
>> les svn:externals. C'est une chose à corriger, mais je crois que ça a
>> déjà été rapporté.
>>
> Oui c'est déja noté
>> Je propose qu'à l'instar des fichiers qui traînent, les ci (sans
>> argument) soient bloquants s'il y a des svn:externals qui sont changés.
> Pourquoi pas en effet
Je propose ceci à nouveau. Pour l'instant ni svn-wrapper ni vcs ne
sont gênés lorsque les externals ont changé. Ils ne devraient pas
l'accepter.
On 2006-11-07, Roland Levillain <roland(a)lrde.epita.fr> wrote:
> https://svn.lrde.epita.fr/svn/lrde-tools/trunk/build-farm
>
> This script could be *much* better, an produce more significant
> results; for instance:
> - the total number of source lines of code of a given target, for the
> HEAD revision, and for previous revisions (graph).
> - likewise for a given committer and a given project;
> - the average patch size per committer, per project;
> - etc.
>
> BTW, the script could avoid re-scanning the whole revisions of the
> inspected projects, and cache the results somewhere.
>
> And we could use sloccount, too.
>
>
> Suggestions, ideas and help welcome!
>
>
Yeah that's a good idea. Knowing the number of lines per commit etc would
require a diff for each revision which sounds rather costly (especially if
we're operating on remote repository such as https://svn.lrde.epita.fr/
instead of say file:///some/path/to/svn/repos). This would *certainly*
require a caching mechanism.
Another interesting idea would be to use svn blame on every file in the repos
in order to know who "owns" how many lines of code in a given
project/version.
--
SIGOURE Benoit aka Tsuna (SUSv3 compliant)
_____ "On a long enough timeline, the survival rate
/EPITA\ Promo 2008.CSI/ACU for everyone drops to zero" -- Jack.
Je souhaite que svn-wrapper et vcs supportent mv/cp FILES DIR.
Je suppose que svn ne le fait pas, car un comportement transactionnel
ici ne serait pas très simple à implémenter. Mais dans la pratique,
je préfère avec la fonctionnalité avec le risque, que de devoir tjs
faire une boucle ou un zmv (qui reviennent au même côté risque).
Bonus: cp/mv -W comme dans zmv, de façon à pouvoir faire
svn mv '(*).cpp' '(*).cc'