|
Kristis, I do not have a SCMBUG environment setup at the moment. So, I am doing this somewhat blind. Your are right about (2). There should be a guard around the "if" block at line 221 in CVS.pm to only allow execution of the block when "$self->consolidate_cvs_messages() == 1". (I guess no "consolidation" actions should apply anywhere if this flag is not set :-) For (1) it would be possible to "consciously" call a CVSConsolidatedActivities "clean" function to do file removal (and any other clean up activity). The time to do this would be after the Daemon writes to Bugzilla (wherever that happens). I took the "DESTROY" approach to avoid "coupling". Using an instance destructor for clean up allows CVSConsolidatedActivities to be completely private to the CVS "Activity". But an approach where a "close" function was added to "Activity" and where the "CVS" class's "close" function calls CVSConsolidatedActivities (now a class variable) "clean" function could work also. Then when the infrastructure (Process?) is through with an activity it calls its ''close'' function. I might be able to look at this over the next week or so... But is this more related to a generic "session" handling issue? For the couple of months I used SCMBUG with this feature it worked well in my Linux environment. But session handling has enough holes in it to drive a truck through! In principle it depends on every concurrent session having a unique user name (I do not think that using the parent pid has any mitigating effect on session). So any use case where this is not the case will suffer concurrency issues. For example an environment where people "share" a CVS user (a daemon user for instance) could have concurrency issues. Although I do not know enough to say for certain that CVS cannot provide a better means for identifying sessions, I believe this to be the case. I think the best that could be done would require adding some "heuristic" clean up on every invocation (probably some time stamping guessing game). Kristis Makris wrote: Hey Doug thanks for the help. Please forward all communication to the mailing list.There are 2 problems: 1) The .scmbug_consolidated_cvs_activities_files are not deleted. 2) If consolidate_cvs_activities is set to 0, all CVS commits whatsoever do not issue a commit activity. That's because they exit, at line 222. So, it seems that when consolidate_cvs_activities is set to 1, "things work for most people" -- I am still not sure what's the case with Manjit. But I'm more interested in debugging (2) first. Let's worry about (1) a little later. I wish this work can become more readable. Meaning remove DESTROY, and instead issue precisely the function calls needed, precisely where they are need.From: Doug McNeil <[EMAIL PROTECTED]> I do not think the exit(0) on line 222 of CVS.pm is the problem. The logic is: Reference count "activities" on "commits" - the "add" at line 202 Dereference count "activities" on "loginfos" - the "replace" at line 221 if (reference count = 0) consolidate() else exit(0)I think this might be the error. You say exit(0), but I tried to conditionally execute this code if the policy is enabled, and this exit is executed when the policy is disabled, too. This may be it. Can you have a look at the code as is in the repository right now ? Should the if statement in line 225 include line 221 in its scope ? -- Doug McNeil Tel: (613) 599-2087 Ext. 242, Cell: (613) 867-6249 Advanced Software Concepts Fax: (613) 599-5311 235 Terence Matthews Crescent Web: http://www.ascnet.com Kanata, ON K2M 2B3 Email: [EMAIL PROTECTED] This document contains valuable proprietary and confidential information of Advanced Software Concepts. This document shall not be copied, reproduced, archived, transmitted or disclosed in any manner or provided to third parties without the prior written permission of Advanced Software Concepts. © copyright 2008 Advanced Software Concepts. All Rights Reserved. |
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
