In the current -stable tree we support binary sfile’s using the binfile config variable. The config is checked whenever a sfile is going to be written: if binfile is true then a binary sfile is written. As a result file formats can move back and forth. For example two users can be working in the same repository with different values of binfile in their environment and files will move back and forth. This works currently but becomes a problem with the more complicated transformations like a binary cset weave or blobs.

I would propose we make the repository format fixed and only allow it to change on clone. We will not support an in-place format change even if it is trivial in the code. By requiring the user to clone to change the format we also require them to create a backup.

This is similar to how remap is handled currently. Right now to change remap the user has to clone with --sccs-compat or --hide-sccs-dirs.

But we don’t want to just keep adding options to clone: --[no-]hide-sccs-dirs --[no-]bweave --[no-]binfile --[no-]blob …​etc…​

Our users don’t want to think about all that nor do we want to try to explain it.

So here is my proposal:


Notes for nested:

In nested, components ALWAYS use the exact same format as the product and so a populate may end up using the doing a partial upgrade or downgrade in the clone to make them match. So we will still need to support doing partial changes. Like for instance binfile without blob.

As a result of this I am really thinking we should get rid of the in-place attach. New components should either be created in-place with bk setup or cloned with bk attach URL comp. This would simplify some corner cases I have hit with several RTIs lately and make it harder to violate the goals for this proposal.


The existing bSFILEv1 feature flag stored in BitKeeper/log/features is being renamed to BKFILE. Just because bSFILEv1 can sometimes be exposed to users in error messages and the user is going to somehow be confused that bSFILEv1 implies something.

The new bk will know about the bSFILEv1 feature, but will totally ignore it. When reading from the BitKeeper/log/features file the bSFILEv1 feature will be deleted if present and never sent over the wire. If a new bk or bkd receives a bSFILEv1 over the wire from an older bk, it will allow it but do nothing. In this way the new bk will assume repositories with bSFIOv1 should be stored in the SCCS file format and will act like it is using SCCS files over the wire. The check will automatically downgrade any repository back to SCCS files. This can cause errors if pushing to an old bkd with one of our internal bk-stable repositories because the features bits won’t prevent the push, but this is harmless and only impacts us and not customers.

The above should totally fix our environment and doesn’t impact customers.