views:

501

answers:

6

We have the following tools in place:

  • Subversion (Version 1.5.9)
  • Polarion (version 3.2.2)

Polarion is based on Subversion, so on every action that changes anything (which is often the case), Polarion will use a Subversion commit to change anything. All things are currently stored in one and only one repository, so every commit of every user (some 100-200 on the same repository) will trigger the pre-commit hook.

So what is the best strategy to provide pre-commit hooks that will

  • trigger only for some, but not all projects
  • run as fast as possible, because every pre-commit hook will block all other commits.

We have tried to implement pre-commit hooks with Java (using SVNKit), but this will start on every commit a Java VM. So any ideas how to implement that nicely?

+1  A: 

The best thing you can do is stop using one repository for everything.

In addition to better performance, this will give you fine-grained control over your repos, allowing you to have separate access control, separate hooks per repo (project), etc.

RedFilter
We would of course like to do that, but with the current version of Polarion, we loose the possibility to auto-link work items in Polarion with the revisions that are working on it. This might be possible with the next version coming in 2010, but not at the moment.
mliebelt
You could add a pre-commit hook to ensure the work item is referenced in the commit comment.
RedFilter
We do that currently, but to do it in a save way, we have to use the API of Polarion (which is provided in Java) to check that a work item is open and may be worked on. So I try to find a way to use that API without using Java. But thank you, this is of course part of the solution.
mliebelt
And when you stop using one repository for related projects you also lose the possibility of moving files between projects while keeping history, performing atomic commits over multiple projects, a global revision to use as lightweight tag. I wouldn't recommend this step just to get a better hook performance but define what advantages and disadvantages splitting a repository has.
Bert Huijben
@Bert: those are interesting points. I have to admit, I have never needed any of those features, but I can imagine that some people would, so your point is well-taken. Personally, I can't think of a use case for the first point. Re: the 2nd and 3rd points, if you require atomic commits and a global revision #, then I would argue that, for all intents and purposes, they are one project, so should go in one repo.
RedFilter
+1  A: 

Hook scripts based on Java are slow and impact response time of Subversion in general, esp. if you work on heavy loaded servers. Best performance will be achieved to implement audits and metrics to improve quality. By tracking traceability in audits project team can follow its progress gaining better and better levels.

robertneher
Thank's a lot for the hint. We need the pre-commit hooks to allow projects to decline that a commit goes through. So we need a way not to use Java, but to use the API of Polarion.
mliebelt
+2  A: 

Hello,

I've used Python recently to implement a post-commit hook that scans for different projects in the same repository and then acts accordingly. I'm new to Python so there may be some inefficiencies in the following script (or even outright errors), but it does work for our purposes:

#!/usr/bin/env python

import commands
from subprocess import *
import os
import sys

# This is a post-commit hook.  The arguments passed to the hook
# are different than a pre-commit hook, and the syntax/use for
# svnlook will probably be different too.

def check_repo_and_do_stuff(repos, rev):

    dirs_changed_cmd =
    p1 = Popen('%s dirs-changed %s -r %s' % (SVNLOOK, repos, rev)
    dirs_changed = p1.communicate[0]

    for line in dirs_changed:

        if line.find('/part-of-path-for/project1') >= 0:
            do_stuff_for_project1()

        if line.find('/part-of-path-for/project2') >= 0:
            do_stuff_for_project2()

def do_stuff_for_project1()...

def do_stuff_for_project2()...

SVNLOOK='/usr/bin/svnlook'

# Take the arguments that svnserve passes on the command-line
repos = sys.argv[1]
rev = sys.argv[2]

check_repo_and_do_stuff(repos, rev)

I hope this can help.

-Zachary

Zachary Young
Hi Zachary, this gives us the idea how to differentiate between projects (and will be of course part of the solution). I found out that there is a python binding to Subversion (see http://pysvn.tigris.org/) that may be used to do the real work then.
mliebelt
A: 

Please elaborate the same format for windows:-

Thanks WSBokhari

Waseem Bokhari
+2  A: 

If Java is slowing things down, but Java is only used a small percentage of the time, then I'd write the hook in something lightweight. i.e. on Windows, use a .bat file. Then, for the projects (or files or users) that require it, call the more expensive Java hook from the lightweight hook. That way, you'll only slow down the Commit when it's needed.

Chris Thornton
Hi Chris, we came to the same solution. We currently run a bash shell script to decide if the java script has to be run. However, when it is run, the impact could be measured in seconds :-)
mliebelt
+1  A: 

In many cases heavy tasks are better handled by a continous integration server that monitors the repository for changes. This makes sure that the scripts never slow down the repository and these tools usually have better error reporting for build, verification and update tasks.

The disadvantage is that they can't deny a commit from happening... Those tasks must be handled as a hook, but in practice you can delay most work to some post commit processing.

Bert Huijben