Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Arthur, >> - is the difference concerning the bugid between commit and edit "as >> designed" and if so what is the reason for this? > It's a change set. A person would typically edit file hello.cpp, > hello.h and hello.rc as bug 123, and maybe common.h as bug 234, then > when the boss tells them to 'return all work for project 234' they just > commit 234 and only common.h is committed. Alternatively the person > find that project.rc needs a small change and they just do a quite cvs > ci -B 999 -m "" project.rc. Ok, so they can be used both; maybe it should be mentioned in the manual that the commit bug-id (-B) will overwrite the edit bug-id (-b). >> - what is the best solution for checking the bugid before the commit >> actually is performed. (in an old message (Xref: news.cvsnt.org support.cvsnt:25296) it was mentioned: "Loginfo can get the bugid for each file, and can fail the commit." But as far as I know loginfo is after the commit) > Use the C++ triggers or COM triggers. The CVS Suite (paid version of > CVSNT) uses this for the defect trackign integration with > mantis/bugilla/jira and it does a whote range of pre-commit checks > including checking if the bug exists, checking if it is assigned to the > current person committing etc. Where can I find more information on C++ triggers or better examples of C++ triggers? Bart PS: while testing the trigger-files regarding the bugid I found out that the use of the premodule and postmodule file/triggers will throw an errormessage if you don't define any expansion options and the default expansion options are used: "Unrecognised expansion 'p' in line 0 of CVSROOT/premodule"