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.