[PATCH] bzrlib API to add pending revision properties to a working tree

[James Henstridge]

On 05/09/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> James Henstridge wrote:
> > Tracking bug fixes is one of the uses of revision properties I had in
> > mind.  Having the annotation attached to the revision where you assert
> > the bug is fixed as opposed to a cumulative property has a number of
> > benefits, including:
> > 1. no need to worry about merging the revprop value on merges.
> > 2. If the revision with the bug fix annotation appears in the
> > ancestry of another branch, I know fix has been merged.
>
> The major disadvangage is that it's more expensive to run a query as to
> *whether* the bug has been fixed.  Perhaps bzrlib could support that
> kind of query better, and dig the data directly out of the knit.  The
> problem is that a line like
>   <property name="bug-fixed" value="#3657" />
> will not appear in the annotation, unless you happen to be annotating
> the revision that fixed the bug.  Subsequent revisions will delete that
> line, and deleted lines aren't shown in our annotation.
>
> I've found it occasionally useful to track down deleted lines, so
> perhaps a form of annotate that tracks deletions should be introduced.
> That could be used for this.
>
> This is an area I have more than passing interest in, as I've written my
> own bug tracker (Bugs Everywhere) which interoperates with Bazaar, and,
> like Bazaar, stores all its data in a hidden directory in the source
> tree.  Its mode of operation is to accumulate bug data, rather than
> setting it in particular revisions.  Bugs Everywhere could (but
> currently doesn't) determine which revision introduced a fix, by running
> 'bzr annotate' on the bug data file.

We've been considering these issues, and the implementation plan we're
looking at for Launchpad does not rely solely on the annotations, but
also changes people make through the web interface.

Furthermore the close-bug-on-merge feature requires a few more
infrastructure changes on our side before we can look at implementing
it.


> > In Python 2.3, the buffering was moved inside the file object and type
> > was updated to implement the iterator protocol directly, to get rid of
> > this class of errors.  It also means that the iterator protocol uses
> > the same buffering as the rest of the file object methods.
>
> So this is bogus documentation, then?  It's funny, because the
> documentation was clearly updated for 2.3.  It says "combining next()
> with other file methods (like readline()) does not work right", so they
> seem to be talking about next as a file method, not a method of
> xreadlines.  Perhaps the documentation author was misinformed?

I was pretty sure the above was correct, but it appears that doing
read() or readline() after using iterator protocol does cause problems
still.  Using readline/read followed by iterator protocol is fine
though (both pre-2.3 and now).  The iterator finalization problem is
not an issue now, so I assumed that they'd made the buffering fully
coherrent.

I'll leave the new code using .next() if you want.


> >> > Lastly, do you have any thoughts on what should be considered valid
> >> > revision property names?
> >>
> >> I guess non-whitespace ascii would be a good start, and we could loosen
> >> the restrictions if/when interoperability demands it.
> >
> >
> > Okay.  I suppose Revision._check_properties() should be updated to
> > ensure this.  I'll make that change in my branch.
>
> It might also be good to reserve names ending in colon, which we're
> already intending to do with revision ids.
>
> > So non-whitespace
> > ASCII property names should be fine for representing SVN property
> > names (even if we can't represent binary property values).
>
> Right.  They don't actually say "ASCII letter", but they would probably
> say unicode if they intended "unicode letter".

The footnote on the paragraph I quoted described Subversion's
constraints as "pretty much the ASCII subset of the syntax for XML
'Name'.":

http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#ftn.id357681

So, yes their properties are constrained to ASCII.

James.