This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
After performing a single CVS checkin (in this case, initial version 1.1 of {i18n,jarpackager,properties}/jars.cfg), the commitlogger sent a single message to cvs@properties.netbeans.org. It should have sent three separate messages, one for each module. Note that the title of the commit message was correct (only listing the properties/jars.cfg) but the contents included all three new files, and was only sent to the one mailing list.
Was this ever actually fixed? It is currently broken (and I think it has been broken for some time). E.g.: http://core.netbeans.org/core-cvs/msg00435.html In this case api/doc is in openide project, as is src/org/openide/..., but src/org/netbeans/core/... is in core project. I checked in all the mentioned files with one CVS commit.
Still broken, BTW.
Is anyone looking at this? It is quite annoying IMHO. I like to commit a batch of files at once, since it is safer and makes build changelogs etc. much nicer. But because of this bug, the poor module owner for the web module (e.g.) is getting dozens of enormous commit messages affecting the whole IDE (and only marginally touching the web module), while huge blocks of changes which are important are not being seen by people subscribed to e.g. cvs@core.netbeans.org. In the case of cvs@openide.netbeans.org, we rely on this list to review potential API changes and ensure that they are properly documented and sensible and that compatibility is preserved, but if changes silently slip in without being sent to this list they could be missed entirely. So I am increasing the severity of this bug.
Can't you use CVS log to track these changes? I think that if you have many files that are changed in the same way (like the license is changed one word or something), then people wouldn't want to see all the different cvs msgs.
Re. use of cvs log: no, it is much more work. We rely on the commit messages to let us know when people are working on sections of code that need to be kept stable. Extracting this information from cvs log is (1) pull not push--it requires an explicit effort to get it, whereas you should be notified as soon as something happens and have to decide to ignore it; (2) difficult--log does not really present the information in a usable way, you would have to use diff, which then does not present committer or log message, so basically several CVS commands have to be run and the output painstakingly collated. Re. many files changed the same way--this happens rather rarely, and I am not sure it is even undesirable in this case for the separate messages to be sent. As a module owner I want to know why my files are changing. If it is only because of some trivial thing, I want to know that too. By the way I can even see in Helm sources where the problem lies. Look in cvspatches/root/log_accum.in line 476: $mlist = &mlist_map($files[0]); Here the destination for the log message is computed based on the first file. Clearly it should be checking for all destinations from all files and uniquifying, and collating the files into different log messages.
change needs to be implemented. Jody must decide where it lives. Reassigning to jody for decision. I'll keep it assigned to me for the moment, but I need to log it on pcn, too and add jody to nb.org too.
jody must decide where this lives.
Jody, please check sources for log_accum.in per my previous message; it seems pretty clear where the bug lies, I doubt fixing it would be that much work.
Internal collabnet issue CN4279.
Internal Collabnet issues PCN4279, SC24.
Accepting issues for support.
This has been moved internally to SC18 (duplicate) and PCN3955 (duplicate).
Setting internal Target Milestone of 2.0.
This has been entered as a request on the SC2.0 roadmap.
Note that this bug no longer exists, I think--now the checkin correctly sends one message, with all diffs, to all relevant lists (so people subscribed to >1 get only 1 copy, nice). (As I noted in another more recent bug, the summary lines are bogus. But I think that is not related.)
Reopening all RESOLVED REMIND Issues and marking them P5.
re-resolving this fixed.
It is. My previous comment was wrong however: if you are subscribed to more than one affected cvs@ list, you get that many copies of the same message. I doubt this is easy to fix though since it involves communication with the mail system (subscriber list). Not sure if it is filed elsewhere or not.
Updating WB.
closing..
We recently moved out from Collabnet's infrastructure