~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/feature-flags.txt

  • Committer: Jelmer Vernooij
  • Date: 2011-12-24 10:10:59 UTC
  • mfrom: (6405 +trunk)
  • mto: This revision was merged to the branch mainline in revision 6407.
  • Revision ID: jelmer@samba.org-20111224101059-epghsc5y61hsgbl2
Merge bzr.dev.

Show diffs side-by-side

added added

removed removed

Lines of Context:
51
51
Feature necessity
52
52
-----------------
53
53
 
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
57
57
warning printed.
58
58
 
62
62
      annotate cache)
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,
 
65
 
 
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:
 
69
 
 
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.
67
75
 
68
76
Format changes
69
77
--------------
94
102
API Changes
95
103
-----------
96
104
 
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``.
101
 
 
102
 
 * BzrDirComponentFormat.register_feature(name)
103
 
 * BzrDirComponentFormat.unregister_feature(name)
104
 
 
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.
 
107
 
 
108
 * BzrFormat.register_feature(name)
 
109
 * BzrFormat.unregister_feature(name)
 
110
 
 
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.
 
118
 
 
119
BzrFormat is inherited by ``BranchFormatMetaDir``, ``BzrDirFormat``,
 
120
``RepositoryFormatMetaDir`` and ``WorkingTreeFormatMetaDir``.
 
121
 
 
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.
108
125
 
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:
111
128
 
112
 
 * BzrDirComponentFormat.set_feature(name, necessity)
113
 
 * BzrDirComponentFormat.get_feature(name) -> necessity
 
129
 * BzrFormat.features.set(name, necessity)
 
130
 * BzrFormat.features.get(name) -> necessity
114
131
 
115
132
See also
116
133
--------