Hi Kristis, 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 :-)
> > This is a known issue, and apparrently the Subversion team likes it that > way. I don't agree, but ... > > http://bugzilla.mkgnu.net/show_bug.cgi?id=385 I have a feeling that will never change! > > 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. > There are two issues here: > > - In the Testdirector backend there's an incomplete implementation of > this locking business. > I'm not sure what other way I can close this whole other than what I have suggested, ideas are very welcome. > - In Scmbug, there's no mechanism of reporting errors on > activity_commit. I have tried to think of different ways to solve this, but the thing I keep coming back to is sending the E-mail. > I understand that you are providing a patch for the second one. That had > to happen at some point. But I'd rather the first issue was resolved > too. And it sounds like it could be resolved with no implementation and > maintenance of an additional integration_* function (e.g. > integration_check_bug_lock) I hope I've done a reasonable job above of explaining the problem, I didn't want to hijack any of the other interfaces for this as it will end up giving rubbish error codes back which will not really explain the problem to the user. > [SNIP CODESTRIKER] > I don't like the idea of a ScmbugUtils.pm. That's what scmbug-common was > created for. If we need to shift code around so that you don't maintain > a ScmbugUtils.pm I'd rather we did that. > 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. > > Also we use this information for merges as we do a reasonable amount > > of changes on branches and do specific bug fixes for customers that > > need merging into the latest product line. (Although the merges are > > pretty much by hand at the moment) > > You should have a look at the Merger tool. It's close to being finished: > all the necessary information are retrieved from a bug-tracker. We just > need to issue the appropriate svn commands to merge. 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 :-) Hope this helps Thanks Rob _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
