[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion Reporting

From: Benjamin Smith-Mannschott <bsmith.occs_at_gmail.com>
Date: Tue, 29 Jul 2008 11:35:16 +0200

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.