by Niall Douglas. Last updated . This page has been accessed 5,512 times since the 1st August 2011.
| View this page in: |
|
Any language: |
|
|
|
|
|
|
|
Translation to non-English languages provided by Google Language
You are connecting to the IPv4 version of this website from the IP address 50.16.17.90. You can try the IPv6-only version if you want.
|
|
This is a TortoiseXXX plugin for the Bugs Everywhere distributed issue tracker. The plugin integrates with TortoiseSVN, TortoiseGIT, TortoiseHG, TortoiseBZR etc. etc. to provide a pretty GUI interface for embedded, personal issue tracking. What is embedded personal issue tracking?This is when you keep an issue tracker - the same thing most centralised source code websites like sourceforge or github have - stored locally within your project's source code. Obviously it's much more lightweight than a web based tracker because you're the only person that's going to be using it. However, it starts to become much more useful when it is used as part of your code writing workflow, particularly as an aid to memory and especially to collective memory. For example, if you're in a coding shop where all commits must be peer reviewed before being allowed into the origin repo, you're probably using an internal Redmine or an equivalent for logging things to be fixed back to the original author. That's fine until you have to log something from outside the office, or log a problem on a specific branch of code which isn't a problem in other branches. An embedded issue tracker solves these problems because issues with the code are literally part of the code. The issues move with the code. If I log a problem with file X line Y in branch Z, that issue NEVER gets lost or detached from the code. When you merge branches, you also merge their issues. This, even in a single person shop, is surprisingly useful,
especially when you're getting older like me and can't remember
what's wrong with your code anymore
What is Bugs Everywhere?Bugs Everywhere is a reasonably mature embedded issue tracker written in Python. It isn't actually distributed on its own - it is as distributed as the master version control repository housing your source code, so with Git, Mercurial and Bazaar it's distributed whereas with Subversion it's not. That said, it does mean it's completely version control system agnostic which can be useful when working with mixed source libraries as everyone seems to have their own VCS nowadays. In short, you can use BE with what you feel like. Much as distributed source control has revolutionised productivity for many people, distributed issue tracking promises to add another chunk of productivity. One tracks the issues alongside the branches of code being worked upon, and issues can be merged, uploaded, tagged and branched just like code. Here are some screen shots of BEurtle in action showing the bugs lists for BEurtle itself running via TortoiseGIT (yes, we do eat our own dog food):
![]() As you can see, it exposes the majority of what you can do with
Bugs Everywhere. This is nicely integrated into the TortoiseXXX
family of source control extensions to Windows Explorer. Not shown
above is how you can drag and drop emails into the BEurtle UI which
auto-adds it (depending on context) as a bug, a diff patch,
screenshots, a binary attachment etc. This is extremely convenient
when you frequently receive source code patchsets by email
Current features in BE not supported include bug dependencies, setting due dates, subscribing or targeting. You'll still have to use the command line for those. I see the v1.50 release is currently in alpha stage? Is it stable enough for daily usage?I use this release myself pretty much daily on a Windows 7 x64 workstation with TortoiseGIT. On that combination, I'd have to say it's plenty stable - as I find bugs/irritations I log them with BEurtle and they get fixed! There are about ten bugs outstanding at present, with two of them particularly annoying, but nothing which will cause data loss. I also have an Atom netbook running Windows XP x86 also with TortoiseGIT. On that underpowered laptop BEurtle is fairly painfully slow as several invocations of BE have to often be made per BEurtle operation, and things can take a few seconds to happen. Next release of BEurtle will use BEXML, a very fast, lazy, RESTful web service exposing Bugs Everywhere and other issue trackers. Once BEurtle is using BEXML, all operations will be nearly instant, even on an Atom netbook. What's coming next for BEurtle?BEXML is slowly gaining the ability to wrap a Redmine issue tracker in a BEXML interface, and not long after that it will also be able to wrap a Github issue tracker too. That will enable BEurtle to access Redmine/Github/any supported backend issue trackers and therefore to automagically copy/move/merge bugs and issues between your Bugs Everywhere tracker and any supported external tracker. I need this facility personally, so you have a very strong chance of seeing it completed soon as it would save me a great deal of time personally. Where do I get it from?
You can download a zip archive of the source code for this release from github, or pull a full GIT clone from: How do I report bugs, suggest enhancements or get support?Please report bugs or enhancements to the github issue tracker. You can get non-commercial support from the email address at the bottom of this page, or you can get commercial support from my company ned Productions Consulting Ltd. Changelog:v1.50 alpha 2 (17th February 2013):Bugs fixed:
Features added:
v1.50 alpha 1 (18th July 2012):Bugs fixed:
Features added:
v1.01 beta 1 (3rd August 2011):
v1.00 beta 1 (31st July 2011):
blog comments powered by Disqus
|