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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James Henstridge wrote:
>> Your API sets the revprops, right?  So say your current revision, revno
>> 2, has {"permitted_colors": "red"} and you decide you no longer want to
>> permit "red".  You set a working tree revprop for {"permitted_colors":
>> ""}.  Then you update to revno 3, where the revprop is set to
>> {"permitted_colors": "red blue"}.  What should the working tree
>> "permitted_colors" setting be?  I don't think we have enough information
>> to answer this.  So there's a 50/50 chance it's wrong to
>> permitted_colors to "" when we commit revno 4.  I think this should be
>> considered a conflict.  Which makes me wonder: should merge be setting
>> the revision properties for working trees?
> 
> The revision properties on the working tree would be for the revision
> that is going to be committed.  It is not related to revision
> properties set on any previous revision.

Some revision properties, like the branch nick, are long-lived.  For
those properties, setting them for a revision is an alteration of their
previous value.

Perhaps that's a bad example, and most revision properties wouldn't be
continuous.  But it might be nice to have a list of bugs fixed in a
branch as a revision property.  A list of recently-fixed bugs would be
cheaper to use than a revision property that listed only the bugs fixed
in the current revision.

But you're right that the current model is that properties must be set
in each revision, so I'm probably attacking a strawman.

>> I don't think the code would be much simpler using readlines:

> Well, it could be written as:
>    if hashfile.readline() != MERGE_MODIFIED_HEADER_1 + '\n':
>        raise MergeModifiedFormatError()
>    for s in RioReader(hashfile):

Because the next method on file objects uses an internal buffer, the
docs specifically recommend against mixing next and readline:
http://docs.python.org/lib/bltin-file-objects.html

I suspect in this case it would work.  But in general, I consider it bad
form.

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

It's worth noting that Subversion's properties may have binary values,
which we don't support.  A quick glance doesn't tell me whether their
names are unicode.

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

iD8DBQFE/WbM0F+nu1YWqI0RAqVrAJ4iQmznbWe9TGZQShbyEImmTAwsjgCcDsOu
v5v7M2lchGNWr7LfUK/YMss=
=CtWC
-----END PGP SIGNATURE-----