Martin Waitz wrote:
hoi :)
On Sun, Jun 03, 2007 at 10:16:32PM +0200, Pierre Habouzit wrote:
Well I went that way, but we loose the quite cool "if I branch my
repository I branch the bugs coming with them too"-feature. And I'd be
sad to give that up. But maybe it's an error to want to use git to
encode that relation.
Just store the commit which introduced the bug (or where the bug
was first found) and you will get that, too. You only have to check
if this commit is reachable by a given branch to see if it is affected.
When you fix the bug you store the commit id that fixed it and then
you can check every branch if it points into bad..good.
You can also do this for released versions.
If you have the bug database inside the repository you can't report
any bugs for a released version, because it is, well already released.
Ok, that seems reasonable.
Now, how do you store updates to a bug? i.e. followup questions and answers?
As suggested in another message, I think that the bug id would have to
be the hash of the initial report (incl whatever metadata is considered
interesting).
I think that the individual reports might be stored by their id, perhaps
via a fan out dir, like the .git/objects directory. Attachments can be
stored by their hash in a separate directory structure. Modifications to
a report would simply be appended to the original report. Simultaneous
modifications could be dealt with by merging the two files, probably
using a custom merge driver.
Obviously the format of a bug report and follow up message would need to
be quite strictly defined and adhered to, for the merge driver to be
able to do its work with the minimum/zero user interaction.
Closed bugs would be deleted from the filesystem, but would obviously be
available via the history.
Indexes or categories could be implemented by means of symlinks/symrefs
in a different set of "index directories". e.g.
/categories/drivers/deadbeef -> ../../bugs/de/adbeef
/assignedto/joe@xxxxxxxxxxx/deadbeef -> ../../bugs/de/adbeef
or similar. These might not be strictly necessary, since all that
information will be in the report anyway. Perhaps the indexes would be
stored simply as cached data, and rebuilt if out of date.
The porcelain would then take care of presenting the bugs to the user in
the preferred format, much like we have gitk, gitweb, qgit, tig, etc.
Does any of this make sense?
Rogan
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
