Launchpad Entry: https://launchpad.net/products/bzr/+spec/versioned-properties
Created: 2006-02-11 16:17:51 by JanHudec
Bazaar currently has per-revision properties, but not per-file-per-revision properties.
Generic internal API providing base implementation for versioned properties should be implemented. This should support all properties that can be expressed as sets of values and for which set weave merge is appropriate.
This interface should support at least NewIgnoreRulesSpec, LineEndings, KeywordExpansion and tracking executable flag could be ported to it, though that is already implemented in the inventory. It should be also possible, though not necessary, to support independently versioned properties like BzrTagging.
It should be possible to define properties from plugins, if they don't need to touch the core.
There are various versioned properties proposed or can be expected someone will propose them. Some of them will be domain-specific and it should be possible to implement them with a plugin.
There shall be two kinds of properties, sets and scalars. It should be possible to attach them to inventory as a whole and to individual inventory entries.
Scalar and Set properties
Scalar property has one string value per inventory/inventory entry. When merging if different changes are done to it in the merged revisions, it is a conflict. Conflict can be recorded in the working tree and UI will be provided for resolving it.
Set properties have an unordered set of string values per inventory/inventory entry. Since changes are either adding or removing a value, these never conflict. Values removed (compared to base) in either branch are not in the result and values added in either branch are. Since each value either is or is not present in the base, it's not possible to add it in one branch and remove in the other.
Inventory and Inventory entry properties
The properties will be handled in the same way both in both cases. The only difference will be whether it would be possible to set the property either globally or for an entry.
This change should simplify implementation of the abovementioned proposals and other possible things plugins may want to do, like more precise permission tracking.
Properties will be stored as part of the inventory XML. Each inventory entry will get a list of children representing the properties. Additionally the inventory itself will get a proplist element containing it's properties.
Since the properties will be represented as sets, each property tag will contain a list of v tags with the values.
The change itself does not change UI. However most properties will need commands to manipulate them. Since properties are basically sets, the commands will be quite similar. So a base class for reuse by such commands will be implemented. In fact two such base-classes -- one for global properties and one for per-entry ones.
Properties will be represented with classes, that will take care of all manipulation with that property. This includes setting and reading the property value to/from a working file.
Inventory and InventoryEntry will get proplist attributes, that will hold the properties. Serializer will be taught to use and set them.
Inventory will need a format bump. This requires new serializer and a new WorkingTree and I-am-not-sure-yet-whether-repository-or-branch format to use that serializer.
Needs format update to work. The upgrade mostly is straightforward reading old inventory and writing it out in the new format. Some properties need to be initialized with appropriate default values at the right moments.
This section should house the larger issues that need discussing; you can sprinkle XXXs around the page if you want to keep the smaller open issues in context.
- Diff format
- We need a diff format that will look good when added to unified diff, but will be ignored by standard diff. I am not yet sure how that format should look.