>>> "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'
Tsuna <tsuna(a)warszawa.lrde.epita.fr> writes:
> On 2006-11-03, Roland Levillain <roland(a)lrde.epita.fr> wrote:
>> Roland Levillain <roland(a)lrde.epita.fr> writes:
>> BTW, is there an option to disable this behavior in Vcs? If not, I
>> suggest adding an option like `--show-space-change' (i.e., the
>> opposite from diff's --ignore-space-change).
>>
>
> Or simply when the diff is empty, diff it again without removing
> white spaces and stuff.
This is not a good workaround for Python sources, though.
(Sinon, lrde.proj est sûrement plus adapté, Tsuna ;-))
--
/!\ My mail address changed, please update your files accordingly.
| À quoi bon user des douzes pieds de Michaël `Micha' Cadilhac |
| l'alexandrin si ces dames s'épuisent cadilh_m - Epita 2007 - CSI |
| au premier pied qu'elles prennent ? JID: micha(a)amessage.be |
`-- - - -- Jacques_Beauheurt - - --'