Il 05/03/2011 05:18, Kristis Makris ha scritto: >> My main problem is the following: >> - with consolidate_cvs_messages=1 comments are (usually) correctly >> merged, but some modified files are missing (and this is misleading for >> developers) > > If you can track the case where comments are lost, then this could be > fixed.
Unfortunately, I wasn't able to understand what the discriminant factors are. For instance, yesterday I did a commit with the following characeteristics: - files in 4 different branches were involed - these files were spread in 8 different folders In a schematic way, the changeset was the following: (Bx is a branch, bxpy is a path in a branch, fz is a file) Branch B1: - files: b1p1/f1, b1p1/f2, b1p1/f3 Branch B2: - files: b2p1/f1 Branch B3: - files: b3p1/f1, b3p1/f2, b3p2/f1, b3p3/f1, Branch B4: - files: b4p1/f1, b4p1/f2, b4p1/f3, b4p1/f4, b4p1/f5, b4p2/f1 b4p3/f1, b4p3/f2 All the files were changed files, except for b4p2/f1 that was an added file. The result was this: - 2 (instead of 4) different messages added to Bugzilla, with just 2 of the 4 branches mentioned (B4 and B2) - in the first message (which mentions B4), only one changed file is displayed: b4p2/f1 - in the second message (which mentions B2), the following changed files are displayed: b1p1/f1, b1p1/f2, b1p1/f3 (that is, all the files in branch B1, not B2!) and b2p1/f1 (that is, the only file in B2) Branches B3 and B1 seem to be "lost" by Scmbug, although changes in B1 are logged as if they were in B2. Moreover, all the changes in B3 are lost and most changes in B4 are lost too (except for one file). I don't know in which order the changes were committed, but since I'm using an IDE that lists the changes in alphabetical order, I would expect that changes were submitted in the same order I used to name branches, paths and files. Moreover, it might be that changes in B1 and B2 were sent with an only cvs client invocation, while changes in B3 and B4 with another one. >> - with consolidate_cvs_messages=0 all the modified files are present, >> but many comments are generated (and this causes too much "noise" in the >> bug tracker) > > There was no noise at all without Scmbug :) Don't misinterpret my words: Scmbug is very precious (we have been searching for such a functionality for years...) but the overhead produced by many amost identical comments in Bugzilla that gets generated on commit while working with very large projects is overwhelming. >> Right now, I don't know what is the lesser evil. If at least I could > > The lesser evil is consolidate_cvs_messages = 0. But doing so, in the example above I would have had 8 (!!!) new comments in Bugzilla, all sharing the same content (the comment log) except for the changed file list. Eight messages is too much: our Bugzilla installation is used not only by developers, but also by testers, quality assurance supervisors, product strategy members, and so on. Comments must be telling something useful to all the persons involed and having the same message repeated for 8 times is not acceptable from a non-developer point of view. By the way, as soon as I understand it, now things go in the following way: - the glue performs the consolidation process, using temporary files to buffer the information as they come from the CVS client - the problem for the glue is that it's not easy to identify an "atomic" changeset, because CVS doesn't have this information; so, che CVS sends the glue different notifications for each different folder - then, the glue must implement some way to group notifications that are relative to the same change set - each glue execution is "one shot", whenever a CVS notification is produced So, my question is: why don't changing the approach and do the consolidation on the daemon side? I mean, whenever a notification from the glue is received by the daemon, it could do the following: - identify the changeset; a changeset is identified by the committer, the bug#, the commit comment log and (maybe) the branch (and maybe the glue id/address?) - instead of adding the corresponding comment in Bugzilla immediately, wait for a specified amount of seconds (for instance, 5 seconds) to see if other changes for the same changeset (i.e.: with the same committer, bug#, comment log and so on) arrive - while waiting, if something new for the same changeset arrives, keep track of the additions and reset the timer - if nothing new arrives within the timeout period, actually add a single comment in Bugzilla with the whole collected information for the changeset and clear the the changeset information This approach may be used for repositories other than CVS too: it could make sense to have this approach even to group together two different SVN changesets sharing the same comment log/bug#/committer, if the second one is issued soon after the first one (maybe the committer forgot to commit one file together with the previous changeset?). What do you think about this? -- Mauro Molinari Software Designer & Developer E-mail: [email protected] _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
