Hi Kristis, > It seems that this capability could be implemented on > activity_commit as an additional policy. E.g. add in > glue.conf a policy configuration variable that stores the > commands that should be executed on the server after a > successful commit.
The thing is that this repository does not need a Bug ID in order to change any of the files as they are all documents which we don't track with bug IDs. Hence I didn't want to link it into any of the bug ID handling code. > I had a look over your text document. It seems that you want > to execute the tool describe (that issued the activity) every > time you commit. This is because you assume all your > documents are PDF files. Perhaps this could be further > generalized to provide regular expressions that given a match > will execute a program on the daemon server (which in your > case would be '.*pdf'. It's not quite the case. We store all sorts of different doc types in our document repository. I then have a set of code plugged into a post commit hook that checks several things to do with the file (one of which is if it is of a supported conversion type) and if it needs converting it will be copied out of subversion and then the command line message called on the Daemon to convert the file. After that the newly generated pdf file is copied to a location viewable on our intranet. (Don't want sales and support guys messing about with Subversion). As you can imagine I have put a lot of logic into my hook script that would not be applicable to any-one else, so I wanted to keep the interface very generic so that it could be re-used by anyone just to run a generic command (Removing any business logic from Scmbug for this custom code). > The first question that comes to mind is do we need to supply > arguments to that script ? What does your script do right > now, precisely ? It isn't actually a script that is being called based on this call to the Daemon, it is actually a PDF generation program that has a set of arguments passed to it. Hope this helps explain why I proposed to keep the Scmbug Daemon interface very generic. Thanks, Rob _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
