On Wed, 2008-08-27 at 14:38 +0000, Jacques, Olivier (PD&E IT Test) > [Olivier] I don't know if we can make such assumptions. What we need is
I believe we can. > both to have an easy to use system for the developer who commits code, and > a flexible system for specific cases. I do not have enough knowledge on all > SCM systems (front-ends as you call them in scmbug), but in Subversion, > you can have "properties" at the level of the SVN repository or each folder, > that could be read and indicate the defect back-end repository or product name > that scmbug should use to identify the defect to work with. I'd rather not rely on SVN 'properties'. Because SVN properties don't exist in other SCM systems. And what they define really is *static* data, which could also be defined in glue.conf and would be a general solution. A "specialization" of reading specific agreed-upon SVN 'properties' as input for that static data should come later; not now. Now we need the general solution that works for all SCM systems. > The idea would be to have a semi-static repository and product (using > mechanics > available on SCM front-ends, like SVN properties), that a developer could > always overide in order to cover some corner cases (like check-in code that > fixes > bugs in multiple front-end repositories). I see where you are going with this idea, and I believe that product suggestion in bug 1169 can cover that. It would need the *additional* feature of issuing multiple activity_commit activities out of a single activity_commit to handle the case you suggest for checking in code that fixes bugs in multiple products in the bug-tracker.
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
