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

[John Arbash Meinel]

James Henstridge wrote:
> On 05/09/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>> James Henstridge wrote:
>> > 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.
> 
> The branch nick name is currently an unversioned branch property, with
> the branch-nick revprop being a snapshot of its value at the time of
> the commit.  I hadn't thought about managing them as persistent
> revision properties.  I'm not sure revprops are a good fit for them.
> 
>> 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.
> 
> 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.
> 

I think this might work, but you also have the issue that marking a
bugfix may not be correct. I think it is very easy to create something
which you believe fixes a bug, commit it. And then realize later that it
either broke something else, or didn't completely fix the bug. And
because revision properties are write once, and never change, there
isn't anything you can do about something like this.

It still might be reasonable in the short term. But it would probably be
better if Bazaar could handle this better.

It is another thing that might work well in a 'meta-knit' file.
Something that talked about the revisions, rather than being committed
as part of the revisions. (Tags would also work well in this area).
However, we've discussed tags enough, and the latest spec from Martin
puts them in their own file, but subservient to commits. Though I
suppose we can always update that later. Far better to just get tags in
the core, so people can start creating them.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060905/6b577f63/attachment.pgp