On Jul 29, 2008, at 08:17, prakash tiwary wrote:
> Hi,
> I agree commits per developer is a bad metric, but it is useful
> in extreme cases. If you use it over the long span, Its gives you an
> indication to over all performance.
> Think a case, where the average commit of a developer is very less
> than others members, say for example 3 times in a month or two
> months, where as the others have around 20 . This is an indication
> that work is not proportionally distributed as per role or some
> thing wrong happenings. This metric will be used to identify where
> you want to ask questions. This metric is proven to be useful in
> offshore
> development.
>
> Regards,
> Prakash
Or it could just mean *nothing at all*. It could just as easily be an
indication of how fine-grained a developer's commits are.
I've played with SvnStat and, have recently seen my commits-per-day
shoot through the roof. Why? Well, I've taken to preparing features
in feature branches instead of working directly on trunk. This allows
me to make many small commits on the branch without cluttering up the
history (of trunk). When I'm done I group the commits on the branch
into one or a few large logical chunks and merge them to trunk.
I'm not implementing more functionality than I would have if I'd
hacked it directly into trunk, but it sure looks more impressive. The
advantage I can see is that I'm not keeping so much state suspended in
my local working copies between comits. I'm also not likely to trip up
others with half-implemented features comitted to trunk.
// Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-29 11:35:49 CEST