54
The initial implementation will feature the following set of possible
55
settings for feature "necessity". Any format necessity that can't
54
The initial implementation will feature the following two possible
55
settings for feature ``necessity``. Any format necessity that can't
56
56
be understood should be interpreted as "required", and an appropriate
63
63
- required: read and write access is only possible if the feature
64
64
is supported. Useful for things like nested trees.
65
- write-required: read access is possible if the feature is not supported,
66
In the future, we might add more values for necessity. Older
67
versions of bzr treat unknown necessities as "required". Some likely
68
candidates for new necessities that might be added in the future:
70
- read-optional: read access is possible if the feature is not supported,
66
71
but write access requires it
72
- client-read-optional: directly writing to the object requires
73
the feature, but reading or writing through an intermediary (such as
74
a HPSS server) doesn't.
97
Class methods will be added to ``BzrDirComponentFormat`` to allow registering
98
and deregistering the presence of particular features. This class is inherited
99
by ``BzrBranchFormat``, ``VersionedFileRepositoryFormat`` and
100
``InventoryWorkingTreeFormat``.
102
* BzrDirComponentFormat.register_feature(name)
103
* BzrDirComponentFormat.unregister_feature(name)
105
Upon opening, BzrDirComponentFormat will be responsible for checking that the
105
Class methods will be added to ``BzrFormat`` to allow registering
106
and unregistering the presence of particular features.
108
* BzrFormat.register_feature(name)
109
* BzrFormat.unregister_feature(name)
111
The namespace for features is global. It is assumed
112
that the plugin that provides the feature X provides that feature
113
in all objects that it is relevant for. For example, if a plugin
114
provides the ``nested-trees`` feature, it is assumed to support
115
that in both working trees and repositories. If this is not the case,
116
it should use a different feature name for the working tree support
117
and the repository support.
119
BzrFormat is inherited by ``BranchFormatMetaDir``, ``BzrDirFormat``,
120
``RepositoryFormatMetaDir`` and ``WorkingTreeFormatMetaDir``.
122
Upon opening, BzrFormat will be responsible for checking that the
106
123
required features are present. lock_write will raise an exception
107
when there is an un unsupported mandatory feature required for write access.
124
when there is an unsupported mandatory feature required for write access.
109
Methods will also be added to BzrDirComponentFormat to allow plugins, etc,
126
Methods will also be added to BzrFormat to allow plugins, etc,
110
127
to check whether a feature is present and adding new features:
112
* BzrDirComponentFormat.set_feature(name, necessity)
113
* BzrDirComponentFormat.get_feature(name) -> necessity
129
* BzrFormat.features.set(name, necessity)
130
* BzrFormat.features.get(name) -> necessity
135
Features are enabled through the ``update_feature_flags`` method on
136
``Repository``, ``Branch``, ``WorkingTree`` and ``BzrDir``.
138
These methods are called by whatever needs to enable features.
139
When they do that is up to them - e.g. bzr-search would enable its
140
feature when ``bzr index`` is first run.
added
removed
doc/developers/feature-flags.txt
