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

[Aaron Bentley]

-----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.

> 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?

> Given this, the readline use seems fairly sensible.

Yes, given that, I'd agree.  I'm still a bit concerned about it, though.

>> > 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".

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFE/X/Z0F+nu1YWqI0RAkoXAJ463MXn89DP/SP0F7aGE4fYswbdWACeKHZ7
oe0pjD5SGsK4HMud1RgksqE=
=/YnI
-----END PGP SIGNATURE-----