bk check(7.3ce) BitKeeper User's Manual bk check(7.3ce)
NAME
bk check - check repository for consistency
SYNOPSIS
bk -r check [-acdefgpRvw]
DESCRIPTION
Check is used to make sure that a repository is in a consistent state.
A repository contains files, each of which may have multiple versions.
Groups of versions are called changesets (csets). Each cset is
recorded in the ChangeSet file. The ChangeSet file points at the set
of deltas in the set of files. There are no back pointers, but the
files do record the point at which each cset occurs (there can be mul-
tiple deltas in a file all of which belong to one cset; the marker
records the cset boundary).
Since csets propagate between repositories, it is important that the
ChangeSet file is correct. bk check is used to make sure that nothing
has gone wrong (and if it has, it gives you a rough idea of how to fix
it).
Currently, the following are checked:
=> for each file specified, make sure that deltas marked as recorded
in the ChangeSet file are recorded in the ChangeSet file.
=> for each file specified and for each delta of that file which is
recorded in the ChangeSet file, make sure that the delta exists in
the file.
=> for each file specified, make sure that the file has no unresolved
branches.
=> make sure that every delta recorded in ChangeSet file is in the
repository (only with -a).
While you can specify a list of files instead of using "bk -r" to get
all of them, this is not recommended.
OPTIONS
-a Ensures that the ChangeSet file and the repository agree on what
files are in the repository; also ensures that the ChangeSet and
other files agree on where they are in the repository history
timeline.
-c Check file and the per delta checksums. Note that only the most
recent delta's checksum is checked, see bk checksum to check all
of the checksums.
-d Provide more details about what is wrong. Mainly for debugging.
-e Check for end of line (eoln) inconsistencies in text files. Typi-
cally used with the "-a" option. This will check to make sure
that:
=> the state of the EOLN_NATIVE flag in each sfile is consistent
with what is set in the BitKeeper/etc/config file (see bk
admin).
=> a bk file on a win32 operating system that has the EOLN_NATIVE
flag set has the expected line termination: \r\n
=> a file on a UNIX operating system has the expected line termi-
nation: \n
=> a file that does not have the EOLN_NATIVE flag is has the
expected line termination: \n
-f Fix any fixable errors. This option will renumber incorrectly
numbered revisions, put incorrectly located files where they
belong, reconstruct corrupted xflags metadata, and add missing
changeset backpointers. This option is on by default if the
auto_fix config option is set.
-ff Fix any fixable errors which have destructive fixes. This option
will remove any old line-of-development (LOD) information except
the 1.x LOD.
-g List each missing file as the file's identifier (root key), but do
not produce any other output. Typically used as input to the bk
gone command.
-gg List each missing delta key, but do not produce any other output.
Typically used as input to the bk gone command.
-ggg List both missing files and missing deltas. Typically used as
input to the bk gone command.
-p List deltas which are in more than one changeset.
-R Only do checks which make sense in the RESYNC dir.
-v Be more verbose. Each "-v" adds additional verbosity. With just
one, bk check will display a progress bar. With two, bk check
will list each file which is OK. More than two is for debugging
only. Without the "-v" option, there is no output if the reposi-
tory is OK; there is only output if things are broken.
-w List files which are writable but not locked.
SEE ALSO
bk admin
bk checksum
bk config-etc
bk gone
bk log
bk xflags
CATEGORY
Repository
BitKeeper Inc 1E1 bk check(7.3ce)