Hi Rob, On Fri, 2007-07-06 at 02:58 -0700, Robert Hudson wrote: > I thought I’d give you an update of where I have got to with trying to > close the holes in the Test Director side of ScmBug with regard of > failing to update a given Bug. (I believe the second is a more global > issue for Subversion users)
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 > Our core ScmBug (Based on RELEASE_0-19-17) currently has a patch for: > > http://bugzilla.mkgnu.net/show_bug.cgi?id=1015 > > We then inherit from ScmBug to add some company specific features, and > at this level I have added the fix that I have detailed in: > > http://bugzilla.mkgnu.net/show_bug.cgi?id=1014 > > > > Between these two changes I believe I’ve managed to warn the user if > something is going to fail (due to locked or inaccessible bugs) and > then caught any failure on doing a post commit update bug operation. 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) ? There are two issues here: - In the Testdirector backend there's an incomplete implementation of this locking business. - In Scmbug, there's no mechanism of reporting errors on activity_commit. 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) > Both of these fixes are very important for us (which is why I have now > put them on our live system in patch form) as we rely heavily on being > able to track exactly what has been changed under a given Bug. We use > the information as follows: > > > > Auto generate Code Reviews for a given Bug using a set of updates that > I have done to codestriker which I have reported here: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1643356&group_id=41136&atid=429862 This is great! > (Other users of ScmBug may find this useful, I have added support for > Subversion and either Bugzilla or Test Director as the tracker, adding > updates for other source control systems shouldn’t be too hard if > people wanted to add them) 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. > 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 hope this helps you understand the changes that I’ve made and why I > have made them. You are probably among the few that are looking for long-term integration solutions and rely on them on a daily basis. Keep the feedback coming. Cheers! Kristis
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
