Visual Studio integration

[Klaus Hartke]

Klaus Hartke wrote:
> Aaron Bentley wrote:
> > Klaus Hartke wrote:
> > > [integrated issue tracking in Visual Studio]
> > 
> > One approach is the one Bugs Everywhere takes: storing the bug
> > records as part of the source tree.  I'm the main author of Bugs
> > Everywhere, and I use Bugs Everywhere to manage bugs for BzrTools.

I just came across DITrack ( http://www.ditrack.org/ ) which seems to
have similar goals. It's using svn as underlying version control system.
This got me thinking about how to add new issues in Bazaar's "decentral-
ised with shared mainline" workflow model.

Centralised/svn-like is pretty easy:

   bzr checkout sftp://centralserver/somebranch
   ...modify/add some files...
   be new "A bogus bug"
   bzr commit .be -m "Added bug b37"
   ...modify/add some more files...
   bzr commit

However, in the decentralised model you've got a problem:

   bzr branch sftp://mainlineserver/somebranch/
   ...modify/add some files...
   bzr commit -m "Implemented crazy new feature"
   ...modify/add some more files...
   bzr commit -m "Added tests"
   bzr merge sftp://mainlineserver/somebranch/
   bzr commit -m "Merged mainline"
   bzr bundle-revisions sftp://mainlineserver/somebranch/

How do you add new issues here? While it's really useful to include "bug
fixed" status changed into the bundle, you of course don't want to do
this with new, unrelated issues (except maybe if your bundle introduces
a new bug).

So you need to have at least two branches, right? One for writing code
and marking bugs as fixed, and one to add new issues... From the point
of view of integrated issue tracking in Visual Studio this would mean to
have two instances of the IDE running :(


Two other questions I'm curious about:

> How do handle merge conflicts? I guess you don't let the user have cd
> into .be/bugs/b3726fa9-a1c5-42ee-8596-a08eb66f26e0, open values and do
> the merge manually (for example, if two users change the status to
> different values at the same time)?
> 
[...]
> 
> I'm a bit concerned about performance at the moment, since if you have a
> large set of work items (= plain text files) running queries may take
> quite a long time. Maybe a solution would be to import all bugs into a
> local non-versioned relational database?

Regards,
Klaus