Protocol level features: lkey:1 use leasekey #1 to sign lease requests BAMv2 support BAM operations (4.1.1 and later) SAMv3 nested support mSFIO will accept modes with sfio. pull-r pull -r is parsed correctly pSFIO send whole sfiles in SFIO attached to patches fastpatch support fastpatch mode
Repository level features: in prod/BitKeeper/log/features and currently enabled list passed in BK_FEATURES_REQUIRED & BKD_FEATURES_REQUIRED.
remap remapped tree (also BK_REMAP & BKD_REMAP) sortkey(*) needs sortkey metadata in sfiles bSFILEv1 old name for BKFILE BKFILE repo uses BK format sfiles POLY(*) at least one comp cset was ported in twice (polyDB exists)
*) these features require bk-filerev5 in sfiles
See bk-features.h for a complete list of interfaces
All supported features are passed in BK_FEATURES & BKD_FEATURES. The BitKeeper/log/features list will be verified - when we get a lease - when we get a repo lock - in sane() - right before we parse an sfile
If FEATURES_REQUIRED & FEATURES don’t match the connection will automatically be rejected with an upgrade required message. (features.c:features_bkdCheck())
In a nested tree, currently only the product’s BitKeeper/log/features file is used to determine if the bk understands how to talk with this repository. Also for some features like BKFILE the presence of the feature changes bk’s behavior.
In the bk-5.x timeframe the BitKeeper/log/features from each component was used and so the current code always maintains each component with a copy of the product’s features file.
Future extensions:
Nested component-only features
Some features that change bk’s behavior may want to be enabled only for certain components or only in the product. Currently this is not supported since a nested tree has the same features everywhere. The extension we have in mind is to allow a new class of features with an enable per-component. These will be tested an enabled with some API like the following:
int proj_featuresTestActive(project *p, int feature); int proj_featuresSetActive(project *p, int feature, int on);
And in the BitKeeper/log/features file the feature will be listed everywhere, but preceded with a # in all files where the feature is not enabled. For example:
prod/BitKeeper/log/features: SAMv1 #FOO
prod/comp_withoutFOO/BitKeeper/log/features: SAMv1 #FOO
prod/src/comp_withBAM/BitKeeper/log/features: SAMv1 FOO
This is still compatible with existing versions of bk since both FOO and #FOO will be won’t be valid and will cause an upgrade required error.