As part of the nested tag work we are going to reintroduce the attributes file with extra per-cset metadata in a KV file

Basically before any commit bk will write a BitKeeper/etc/attr file with data like this:

@HERE
default
@VERSION
bk-5.0-beta10

Then if the data in that file is changed, the attributes file will be delta’ed at the new key will be included in the new cset. So the overhead in the actual ChangeSet file is nothing in the table and one additional line per-cset in the weave. (when the data changes)

If we ever allow user generated attributes we need to figure out a way to not collide on the keys. So our keys are all upper case, user keys are either lower or mixed case.

XXX How do you auto-merge user attributes?

The HERE key will only be included in product csets.

The normal converge code will be used to handle conflicts and renames in this file, but content merges in takepatch will just use the new data and ignore the previous tips.

The code to update this file can be setup to automatically rotate this file when it grows beyond a certain size to keep access time reasonable.

XXX NYI

It’s not a problem for lookups because the way a lookup works is to get scan the ChangeSet weave for the cset that was specified looking for a delta key with a path of |BitKeeper/etc/attr| - then grab the rootkey for that delta key and keyinit.

Originally Larry and I discussed storing the attributes like this: BitKeeper/attributes/current

and then when we rotate we rename current to BitKeeper/attributes/DATE, but if two repos rotate in parallel then the converge code will put some data in deleted anyway so it didn’t seem as useful in retrospect. (Unless I add more special cases to converge.c)

Next the alias.c code will be changed so that an alias on the command line of @<rev> will be expanded to the HERE key from the attributes file as of that product rev. Something like:

bk get -p -r@rev BitKeeper/etc/attr | bk _getkv - HERE
(only more efficient)

This will allow the following:

bk clone -rREV -s@REV URL local

to recreate a previous cset with the same components populated.

On the HERE key I may want to introduce a level of indirection to reduce the thrashing in the weave. Something like this:

Add a new file BitKeeper/etc/here_configs
Then store the MD5KEY for a delta in that file under the HERE key in
the attributes file.
When updating the attributes file we look to see if the current HERE file
is already stored in here_configs and if so we reuse that delta, otherwise
we add a new delta to the top. The :DSUM: field can be used to quickly
pick a delta to test for a match.

(This indirection might be overkill and just rotating the attributes file is enough to keep performance reasonable.)