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
If you have ever
been searching for some code and noticed something wrong with a
different bit of code, then forgot you noticed, this plugin is
definitely for you!

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
.
Also not shown is how, upon committing, BEurtle will scan your
commit message for the word "fixed". If that word is present, it
will scan it for any BE format issue id 'hex/hex'. It then checks to
see if that issue exists and is open - if so, it will offer to close
the issue for you. If you have enabled auto-issue commenting with
fix revision, it will do that and mark the issue closed. Lastly,
also not shown is that you can now do 'be gui' from the command line
and BEurtle will launch.

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.

Changelog:

v1.50 alpha 3 (13th April 2015):

Bugs fixed:

Rich text editor had stopped working with a "System.IO.FileNotFoundException: Interop.MSHTML not found"
error (reported as
issue #6). This was due to a Microsoft update. Rebuilt the program
and resigned with a new code signing cert.

v1.50 alpha 2 (17th February 2013):

Bugs fixed:

Opening a new issue, then pressing new comment, then closing the window no
longer produces an error.

No longer possible to add an issue with an empty summary by pressing add
comment and then closing the window.

Features added:

Finally fixed the lack of clipboard handling in the rich text editor, so now
one can copy, cut and paste etc. as one should.

Now can add hyperlinks to comments, and clicking on a hyperlink opens it in
an external web browser.

v1.50 alpha 1 (18th July 2012):

Bugs fixed:

Fixed lack of unicode support by hacking BE to behave on
Windows.

Fixed missing severity change feature on context menu.

Went through the code and trapped every possible disc i/o error
I could find, now doing something sensible instead of erroring out.