Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Summary

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.

Rationale

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.

Further Details

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.

Use Cases

This change should simplify implementation of the abovementioned proposals and other possible things plugins may want to do, like more precise permission tracking.

Implementation

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.

UI Changes

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.

Code Changes

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.

InventoryEntry.executable and InventoryEntry.symlink_target will be converted to properties. Deprecated forwarders will be provided.

Schema Changes

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.

Data Migration

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.

Discussion

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.

Unresolved Issues

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.

Questions and Answers

CategorySpecification