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)