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"
_______________________________________________
cvsnt mailing list
[email protected]
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
Upgrade to CVS Suite for more features and support: http://march-hare.com/cvsnt/
