On Fri, 2007-07-06 at 07:35 -0700, Robert Hudson wrote: > I'll try and answer all your questions, let me know if I forget any, > sorry if the answers are a bit brash, they are not intended that way :-)
Don't worry about it. You're always pointing out things I missed :) > > I don't understand. If the bug is locked, shouldn't activity_verify > > fail ? And if activity_verify succeeds, shouldn't it also acquire the > > lock so that activity_commit won't fail (and will release the lock) ? > > > > activity_verify just reads data from Test Director, so it doesn't matter > if a use has it locked, as locked items can be read but not written to. > (For obvious reasons such as running reports shouldn't fail just because > a user is updating a Bugs details). This is why an explicit check is > required to see if it is locked. > > The second point you raise is about making activity_verify acquire a > lock, and activity_commit release the lock. This will leave a big hole > where bugs can remain and get stuck in a locked state. > > The Scenario: If a user commits some changes, the activity_verify locks > the bug and gives the go-ahead. Subversion then starts doing the commit > and fails the commit due to a file clash that needs updating. In this > scenario the post-commit hook will not be called so the Bug will never > be unlocked. I understand. That wouldn't be desireable. I also understand your clarification from: http://bugzilla.mkgnu.net/show_bug.cgi?id=1015#c3 We originally added integration_bug_in_active_state to check if its "acceptable" to commit against the bug. The name we gave it no longer suits its function. We could certainly rename it (e.g. integration_bug_in_commitable_state) and have that function do more work in Test Director. But it would probably confuse things. Go ahead and add the extra integration_bug_unlocked function. > I agree in an ideal world this would link into a Utilities file within > Scmbug. I originally wrote it over 6 months ago and just wanted to get > something up and running to demo to people here. Maybe at a later date > when David has had a chance to integrate what is there (I believe he has > just started looking into doing so re-integration of patches) we will be > able to just swap it over. OK, sounds good. I'd be glad to repackage or move around what's needed to provide an interface you won't have to maintain. > I am actually hoping that we can use that tool when it is up and running > :-) > My only thing at the moment is allowing users to run it on remote > machines rather than the machine running Scmbug, but I'm sure I could > wrap it up in a simple web page to do it for them :-) The VDD Generator requires local access, too: http://bugzilla.mkgnu.net/show_bug.cgi?id=590 That's certainly a bigger problem we need to handle in the long run.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
