What are the SCCS directories in my repository all about?
That's where all the metadata for the revision control is stored.
Do not remove any piece of the SCCS directories.
People have been known to remove part or all of the contents of
the SCCS directories which has serious consequences for BitKeeper.
If you do remove some or all of the SCCS files these repositories
can probably be restored.
Does BitKeeper have support for versioning directories?
Bitkeeper does not version directories directly, it version
Another way to say it is that BitKeeper version controls file
The objects have several attributes including contents,
permissions, and pathnames.
When instantiating any version of the repository, all directories
needed in order to place an object (file) where it wants to be are
The only limitation is that BitKeeper currently has no way to
version control an empty directory.
I'd like to be able to create, move and delete files and have that versioned along with the rest of the files. Does that capability exist?
BitKeeper tracks all attributes associated with a file;
path names are one of those attributes.
All attributes are tracked in every delta, not just a tagged
This means when you rollback or undo a change set, renamed files
will be automatically move back to their previous locations.
See also bk helptool mv.
How can I turn off keyword expansion, that is: [ Documentation expansion ] ?
bk admin -FSCCS foo.c
bk -r admin -FSCCS
# Does it on every file
If you want to understand more about this,
bk helptool keywords
will explain which keywords get expanded when, and
bk helptool admin
tells you how to shut off SCCS keyword expansion.
Is there any way (other than putting something in the triggers) to tell a particular repository that it should always try to do the equivalent of 'newgrp bk' every time? (I have the repository owned by group bk)
If you like to set the sgid bit on directories, you need to
specify the symbolic mode.
This is a safety enhancement of chmod.
find . -type d | xargs chmod u=rwx,g=rwx+s,o=rx
should do the trick.
I am in the EST timezone with daylight savings time and dates are showing up wrong in the revtool. The changesets reflect the time accurately but the tool is displaying the dates as if they were UTC. What's up with the timezones?
Yes, the times in revtool are in UTC.
The reason for this is that when projects have members in
different timezones, the dates at the bottom start becoming out of
sequence when members to the east do commits before you do.
For example, if we display dates in local time and someone in a
timezone where it is the next day does a commit before you, then
you will see the something like:
1/16 1/15 1/17
2001 2001 2001
One of our customers found the out-of-sequence dates irritating
and asked that we display the dates in UTC.