1# This is the BitKeeper configuration for this package. 2# 3# Please fill in the "description:" and "email:" fields, BK/Web needs those. 4# For the rest of the fields you may use the defaults. 5# 6 7# 8# Automatically populate missing components as needed to perform a safe 9# pull. Unless you have very large components and slow networks this 10# should be set to on. 11# 12# Default: off 13# 14auto_populate: off 15 16# 17# Default is to enable the Binary Asset Manager. 18# If you want to use the older uuencoded binaries, set this to "no". 19# 20BAM: on 21 22# 23# BitKeeper supports the following check out modes (which defines what 24# permissions/state versioned files are in after a clone/delta/commit): 25# 26# edit - check out files locked such that they are writable 27# get - check out files in read-only mode (can be higher 28# performance in large repos; also supports keywords) 29# last - preserve the previous state of the file 30# none - do not check out any files 31# 32# Most users are least surprised by checkout:edit, it is what they expect. 33# 34# If this is a repository full of big binary files then checkout:none or 35# checkout:last is better, especially when combined with BAM. 36# 37# Default: none 38# 39checkout: edit 40 41# 42# The clock skew field controls how recent a file has to be before 43# BitKeeper will not trust the timestamp database. It defaults to 44# a week and that default was chosen to overcome clock drift problems 45# on network file systems. If you know your clocks are 100% accurate 46# and your workflow is such that many of your files change all the 47# time, then setting the clock skew down to a day or two (172800) 48# will improve performance. For most people, the default is fine. 49# 50# Default: on 51# 52clock_skew: on 53 54# 55# When cloning a product, limit the components cloned to the alias 56# specified. 57# 58# Default: ALL 59# 60clone_default: ALL 61 62# 63# Name of the project, such as "BitKeeper source management system", 64# "Linux kernel" or "MySQL database system". Used when listing 65# repositories. 66# 67# Default: empty 68# 69# description: 70 71# 72# Email address of the person or alias that should get administrative 73# questions about this project. Currently only used by BK/Web. 74# 75# Default: empty 76# 77# email: 78 79# 80# When checking out text files in operating systems with different 81# conventions, which End-Of-Line marker to use. The options are: 82# 83# native - Use \n on Unix systems and \r\n on Windows 84# windows - Always use \r\n 85# unix - Always use \n 86# 87# Default: native 88# 89eoln: native 90 91# 92# Controls whether BitKeeper will expands keywords embedded in new 93# files. The values are 'sccs' or 'rcs', with an optional ', expand1' 94# (i.e., 'sccs, expand1' or 'rcs, expand1'). 95# 96# The 'expand1' says "expand only the first line found containing keywords" 97# and is supported because sometimes the keyword string is a legitimate 98# part of the source and shouldn't be expanded. 99# 100# Note that this is a property of the file at the time of creation. The 101# setting is persistent and can be changed using 'bk admin'. 102# 103# Keywords are only expanded in 'checkout:get' mode. 104# 105# Default: none 106# 107keyword: none 108 109# 110# Old BK computed checksums using a set based method and new bk 111# computes using a graph based system. Checksum can look back 112# and see that they compute the same thing. In some rare cases, 113# involving an exclude of a merge cset, the two sums might not match. 114# 115# This option skips running the graph based checksum test on old or 116# all depending on how it is set. 117# 118# 0 (or off) - run graph verify test on all (the default) 119# 1 (or on) - skip running the verify on all 120# Other number - interpret as a time_t and only run verify on newer csets 121# 122# Default: off 123# 124no_graphverify: off 125 126# 127# BitKeeper can automatically run multiple processes to take advantage 128# of the multi-core architectures of today. The parallel variable 129# can be set to 0 to prevent this, to a number greater than zero to use 130# that number of parallel processes, or to the value 'on' to let 131# BitKeeper determine what the best value is. 132# 133# Default: on 134# 135parallel: on 136 137# 138# With partial_check set to on, repositories are checked no more than once 139# every check_frequency days. This is a performance win for large 140# repositories. 141# 142# Customers who have reason to believe that their data may be corrupted 143# by hardware or software problems (bad memory, bad disks, bugs in the 144# file system, etc.) should set this field to "off". 145# 146# Default: on 147# 148partial_check: on 149 150# 151# If stats_after_pull is set to 'on', BitKeeper will print diffstat 152# output after a pull. 153# 154# Default: off 155# 156stats_after_pull: off 157 158# 159# If sync is set to 'on', BitKeeper will call fsync() after writing 160# data to the filesystem. On some Linux systems fsync() has significant 161# performance problems (google it). 162# 163# Default: off 164# 165sync: off 166 167# 168# Where to look for triggers. Different paths are separated by the '|' 169# character. Besides path names (such as /etc/bktriggers), the following 170# special values are supported: 171# 172# $NONE - Do not run any triggers 173# $PRODUCT - Run the triggers in the product's BitKeeper/triggers 174# directory (ignored in a non-nested collection) 175# $BK_DOTBK - Run the triggers in the user's 176# ~/.bk/BitKeeper/triggers directory. 177# $BK_BIN - Run the triggers in `bk bin`/BitKeeper/triggers 178# . - Run the triggers in `bk root -S`/BitKeeper/triggers 179# 180# Default: $PRODUCT|. 181# 182triggers: $PRODUCT|. 183