English
Chinese
French
German
Japanese
Portuguese
Russian
Spanish
This page has been accessed 1,250 times since the 1st August 2011.
| View this page in: |
English |
Any language: |
Chinese |
French |
German |
Japanese |
Portuguese |
Russian |
Spanish |
Translation to non-English languages provided by Google Language
You are connecting to the IPv4 version of this website from the IP address 38.107.179.231. You can try the IPv6-only version if you want.
|
|
It's
been a long time since I released a Windows program to open
source - so long, in fact, that when I last did so in 2002 or
thereabouts, .NET wasn't called .NET yet and C# was still being called
"Cool" (I kid you not!). Back then,
I hadn't even written my TnFOX portability
layer either yet, so who knows how I'd have gone about writing this here
plugin. Do you know something interesting? Despite having been away from native Windows programming for nearly a decade, I found that in the past ten years very little has actually changed in native programming for Windows, and that surprised me. Sure, .NET is comprehensive, though probably not that much more so than Java, and the toolset is very mature, though really I only care strongly about its debugger which works just as well with C++. C# is even okay to program in, unlike VB6 which is too idiosyncratic to be much other than an exercise of fighting the language. But to be honest, the same old 90's ugly design of COM and the VB6 runtime is omnipresent in spades throughout .NET. Like its type system, which is frankly braindead. Or the annoying grafting of programming idioms onto .NET from other languages which don't fit properly in .NET, and never will. Or the dreadful support for native C calls which they still haven't fixed (and forget about native C++), and indeed it remains actually easier to call into C from VB. NET than C#. Or the way you still have to write umpteen lines of code for basic boilerplate tasks like connecting variables with their UI elements, and manually writing out disabling/hiding/manipulating UI logic. Sure, you can connect to data sources, but its data driven UI has been dreadfully badly designed such that it's still less work to do it by hand for small projects. In short, what a wasted opportunity. I certainly can see why IronPython is so popular, though it still can't save you from dealing with .NET all the time sadly. Anyway, rather than blather on about about .NET being ugly and crude, please find below 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 issue tracking. What is embedded 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 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 its master version control repository, so with Git, Mercurial and Bazaar it's distributed whereas with SVN 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 Bugs Everywhere itself.
As you can see, it does handle displaying threaded comments correctly, but makes no attempt to pretty print them. Patches improving this are welcome! Where do I get it from?The file Readme.txt in the source zip contains installation instructions and a detailed description of specific features.
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.01 beta 1 (3rd August 2011):
v1.00 beta 1 (31st July 2011):
blog comments powered by Disqus
|
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!
