thanks for directing me in the right direction Andy. On the issue of
preventing developers from commiting directly to trunk are you suggesting I
try to enforce this via policy only or is there a mechanism within svn that
can programmatically prevent a select list of users from committing to trunk
directly. We're currently accessing the repository via the svn:// protocol -
are you suggesting a programmatic mechanism like is supported via the
http:// protocol?
Regards
- Garry
On 4/20/06, Andy Levy <andy.levy@gmail.com> wrote:
>
> On 4/20/06, Garry Cronin <garry.cronin@gmail.com> wrote:
> >
> > I'm a newbie to Subversion so perhaps there are cleaner ways to
> accomplish
> > what I'm asking otherthan writing custom scripts but here goes...
> >
> > Our development team (i.e. approx. 40 developers) have recently switched
> > over from using CVS to Subversion - because we are working on multiple
> > projects simultaneously we have set up the repository in the following
> > structure:
> >
> > project1
> > trunk
> > branches
> > tags
> >
> > project2
> > trunk
> > branches
> > tags
> >
> > etc.
> >
> > Now I'm interested in getting the following types of statistics on a per
> > project basis:
> >
> > How many project team members have committed to the repository in the
> last x
> > number of days?
> > How many commits has each team member made in the last x number of days?
> > On average, what is the average number of commits made each week.
>
> All 3 can be calculated from analyzing the output of svn log, but
> that's both the "lazy" way and the "long" way.
>
> Probably the better way to record such stats would be to run a
> post-commit hook that logs to some external location the fact that a
> commit has happened, who did it, where they committed to
> (highest-level directory maybe?), and when they did it. Then run your
> analysis against that data.
>
> > Really, this is just for my own use so that I can investigate why
> certain
> > individuals may not be using the repository. Following on from this, I
> have
> > written up a Branching & Tagging Policy document that our developers
> should
> > consistently follow. One of the rules is to avoid committing changes
> > directly to trunk. Instead all changes should be made on provate
> branches
> > and merged into trunk after testing & code review. How can I write a
> script
> > to determine whether such a policy is being followed?
>
> Do you need a script, or can you simply disallow developers access to
> write to trunk, and delegate that to a "release manager" so that the
> release manager does the merge to trunk after (s)he is satisfied that
> the requirements have been met?
>
> > Another group within our organisation is maintaining the repository so I
> do
> > not have local access to the repository, so ideally I'd like a way to
> gather
> > these statistics without having to require local access to the
> repository.
> > If local access to the repository is required then I can always get the
> > group maintaining the repository to run these scripts on my behalf and
> send
> > me the results.
>
> svn log doesn't require local access. The post-commit hook only
> requires "local" access in so far as you need to place the script in a
> directory in the repository - kind of a fire & forget, once it's
> there, it'll get executed every time. This assumes that the people
> maintaining the repository are agreeable to installing your script for
> you.
>
Received on Fri Apr 21 00:08:25 2006