Hi Robert, Overall I think you are giving Scmbug the necessary push it needed to address some long-standing issues.
Max, we have a VCI question for you at the end. On Mon, 2008-03-03 at 07:16 -0800, Robert Hudson wrote: > The current reporting tool (bug_report.pl) only supports Subversion due > to the way that I have constructed the method get_commit_comments() > [Although I deliberately kept it so that it only contained the source > control interface] > > What is your view of me re-structuring it so that it is a little bit > more like we have with bugtracker.pm where each source control system > will inherit from it? Thanks for raising this point. The goal was to build a general interface for handling SCM activities. This is implemented in SCM_Functions.pm.in. In practise, this involves calling these three functions, as shown in VDD_Generator.pm.in as an example: SCM_Functions::checkout_repository() SCM_Functions::glue_configuration_file() SCM_Functions::release_repository() The reason we expect "checkout" and "release" is to handle the limitation of CVS which stores hooks inside the repository. So, to answer your question, I'd like to see the get_commit_comments() logic moved to SCM_Functions.pm. Two things to note about this are: - You are touching on a very important current limitation of Scmbug in respect to Subversion. Access to the Subversion repository is required, since the glue.conf cannot be checked-out of Subversion: http://bugzilla.mkgnu.net/show_bug.cgi?id=876 It may time we develop this. We could add the capability to store glue.conf inside the Subversion repository -- I'm not sure what this might do in terms of performance, meaning Subversion hooks would need to extract glue.conf from inside the repository during each commit/verify etc. Or, as a workaround, one could imitate the Subversion repository structure locally, and copy the glue.conf. e.g. make a directory on the Webserver like /my/subversion_rep/hooks/etc/scmbug/ and store glue.conf in there. This certainly isn't a long-term solution -- just something that could be used while developing (while e.g. we are still working on bug 876). Another solution could be to ... force CVS to pick up glue.conf from outside the repository, like Subversion does already. e.g. glue.conf is in /my/cvs_rep/glue.conf, while there is a /my/cvs_rep/cvsroot/CVSROOT Or perhaps have a: /etc/scmbug/my_rep1.glue.conf /etc/scmbug/my_rep2.glue.conf ... and so forth ? How about permissions management ? Any thoughts about all this ? The current design certainly isn't set in stone -- it was quite evolutionary. The general decision has to account for all other future SCM systems, (e.g. Git, Bazaar-NG, etc.) that the glue would like to support, and how glue configuration could be implemented. - More importantly, about a generic SCM interface, Max Kanat-Alexander from the Bugzilla team announced this a while back: http://search.cpan.org/dist/VCI/ http://bugzilla.mkgnu.net/show_bug.cgi?id=1034 This effort is very much necessary, especially for Scmbug. It may be time we switch to it, or at a minimum look at its guts and see what he came up with. Max, does VCI support this notion of "reading repository configuration files" ? If so, how does it handle storing configuration information inside vs outside a repository ? Any thoughts ?
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
