Re: Comment on weak refs

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 4962 bytes --]

On Sun, Jun 10, 2007 at 03:25:32AM +0200, Johan Herland wrote:
> On Sunday 10 June 2007, Junio C Hamano wrote:
> > It gets worse when you actually start using softrefs.  I do not
> > think you would have a limited set of softrefs, such as
> > "reverse-tag-lookup-softref", "bug-tracker-softref".  For
> > example, a typical bug tracking sheet may look like this:
> > 
> >       - Hey I found a bug, you can reproduce like so... I am
> >         testing commit _A_.
> >       - It appears that commit _B_ introduced it; it does not
> >         reproduce with anything older.
> >       -	Here is a patch to fix it; please try.
> >       - Oh, it seems to fix.  Committed as _C_.
> >       - No, it does not work for me, and the approach to fix is
> >         wrong; reopening the bug.
> >       - Ok, take 2 with different approach.  Committed as _D_.
> >  	please try.
> >       - Thanks, it finally fixes it.  Closing the bug.
> > 
> > The bug will be associated with commits A, B, C and D.  The
> > questions maintainers would want to ask are:
> > 
> >  - What caused this bug?
> >  - Which versions (or earlier) have this bug?
> >  - Which versions (or later) have proper fix?
> >  - What alternate approaches were taken to fix this bug?
> >  - In this upcoming release, which bugs have been fixed?
> >  - What bugs are still open after this release?
> > 
> > Depending on what you want to find out, you would need to ask
> > which commits are related to this bug tracking sheet object, and
> > the answer has to be different.  Some "softref" relation should
> > extend to its ancestry (when "this fixes" is attached to a
> > commit, its children ought to inherit that property), some
> > shouldn't ("this is what broke it" should not propagate to its
> > parent nor child).
> 
> We're getting a little ahead of ourselves, aren't we? IMHO, it would be up 
> to the bug system to determine which (and how many) connections to make 
> between the bug reports and the commits (or even if softrefs would be the 
> correct mechanism for these connections at all). We shouldn't necessarily 
> base the softrefs design on how we imagine a hypothetical bug system to 
> work. But Pierre might have something to say on how he would want to use 
> softrefs, and his system is hopefully _less_ hypothetical. :)

  To be fair, I'm still struggling with the storage backend yet, trying
to make things fast enough (My current import rate of mails is 10 per
second, wich is not that brilliant I guess), and also to design some
simple things like "answering" to a bug.

  For now, my design is the following, I've a 'bts' branch where the
bugs reports (plain mailboxes) go. Grit is able to manage as many branch
the user wants, bts is just the default name for it. Then, for a bts
branch, you have $GIT_DIR/grit/<branch>.index and
$GIT_DIR/grit/<branch>/. The former is the index of the tip of the bts
branch, and the latter contains some bits of the tip of the branch
checkouted (can be seen as some kind of cache, useful to run mutt -f on
a mbox e.g.).

  Bugs have the sha id of the hash of the first imported mail, and are
put in sha[:2]/sha[2:] files, à la .git/objects/. I also should have a
second file with annotations about the bug, format not really clear for
now, as "one file per bug" could be quite inefficient. OTOH if I mix too
many bugs in the same file, the merge risk is bigger (but I suppose I
could use a specific merge strategy on this).

  Here is the sole non hypothetical thing yet. My plans then was to use
"links" (softlinks or not, I'm speaking generically, I hope softrefs
will match my needs, I don't know yet) between specific commits, and
bugs. Links would somehow carry information on wether this is an
"opening" tag (like: this bug is present starting at that commit), an
informationnal tag (like: this commit helps fixing that bug, but is not
enough), or a closing/fixing tag (like: this commit fixes it). A fourth
kind may be also used aka a not-found tag (like: well this commit does
not fixes the bug, but for sure it's not there anymore at that commit).

  Though, softlinks do not need to "carry" the information for real,
they just need to be linked somehow to the bug, bug that would have the
annotations for those softlinks in them.

  What is somehow flawed for me, is that when someone "answers" to the
bug or changes a bit of information about it, it generate a "new"
commit, and I would need to move the softlinks to the new commit object
it generated to shorten the path and go directly to the last version of
the bug status file.

  So to be of use for me, yes, I guess I would really like the
versionning of softlinks. If I use them at all, I don't know yet.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]