help://All
help://All.sum
help://topics
help://topic
help://command
help://commands

All(sum)             BitKeeper User's Manual             All(sum)

NAME
  All - summary of all commands and topics

COMMANDS
  bk Basics-Overview - BitKeeper basics to help get a new user started
  bk Howto - BitKeeper HOWTO guides
  bk Howto-bkd - howto: configuring the BitKeeper daemon
  bk Howto-developer - howto: working with BitKeeper reposi- tories
  bk Howto-setup - howto: setting up a BitKeeper repository
  bk abort - abort a failed pull or push
  bk admin - administer BitKeeper files (tags, checksums, validation)
  bk annotate - provide annotated listing of source files
  bk backups - guide to doing backups of BitKeeper reposito- ries
  bk base64 - RFC 1341 base64 encoding and decoding
  bk bin - show binary installation directory
  bk bk - BitKeeper source management system front end
  bk bkcl - display commercial use BitKeeper license
  bk bkd - the BitKeeper daemon
  bk bkl - display free use BitKeeper license
  bk bkscc - BitKeeper and SCC API
  bk c2r - convert changeset revision to file revision
  bk cat - concatenate and display file contents
  bk changes - show changeset history
  bk check - check repository for consistency
  bk checksum - check and/or fix BitKeeper checksums
  bk chmod - change the mode of a file and save it
  bk ci - checks in modified files
  bk citool - BitKeeper graphical check-in tool
  bk clean - removes unmodified files
  bk clone - create a new copy of a package
  bk cmdlog - show the log of commands executed in this repository
  bk co - check out files
  bk comments - change checkin comments
  bk commit - commit deltas to a changeset
  bk compatibility - Commands compatible between other SCM tools and BitKeeper
  bk config - show repository configuration information
  bk config-etc - configuring BitKeeper per repository
  bk config-gui - configuration for BitKeeper graphical tools
  bk cp - create a copy of a file preserving its revision history
  bk crypto - Cryptography services
  bk cset - creates and manipulates changesets
  bk csetprune - shrink a repository by removing files
  bk csets - run csettool on last set of imported changes
  bk csettool - BitKeeper graphical changeset browser
  bk delta - check in modified files
  bk diffs - show differences in revision controlled files
  bk difftool - BitKeeper Graphical Diff Tool
  bk edit - check out a file for editing (writable)
  bk editor - automatically check out BitKeeper files when using $EDITOR
  bk emacs - info on how to use emacs' vc-mode
  bk export - checks out clear-text version of all BitKeeper files
  bk extras - list extra files not under revision control
  bk files - summary of BitKeeper file types
  bk findkey - look for keys in files
  bk fix - re-edit a checked in (but uncommitted) delta
  bk flags - show a listing of files and their BitKeeper flags
  bk fmtool - BitKeeper side-by-side merge tool
  bk gca - show the greatest common ancestor
  bk get - check out BitKeeper files
  bk gethost - display machine name
  bk getuser - display user name
  bk gnupatch - generate traditional patches
  bk gone - mark a file (key) as gone
  bk grep - search some/all revisions for a pattern
  bk help - get help for BitKeeper commands
  bk helptool - graphical front-end to the BitKeeper help system
  bk history - guide to viewing changes over time of files and repositories
  bk id - display the identity of a package or repository
  bk ignore - ignore shell glob patterns
  bk import - import files or changes into a BitKeeper pack- age
  bk info - show the state of BitKeeper files
  bk initscripts - sample script for starting the BitKeeper daemon
  bk isascii - check that a file is ascii
  bk key2rev - convert BitKeeper keys to revisions
  bk keywords - list of RCS and SCCS keywords
  bk level - set or show the level of the repository
  bk licensing - BitKeeper Licensing Overview
  bk links - make links to the BitKeeper binary installation directory
  bk lock - lock a repository or show lockers
  bk lod - line of development
  bk log - Log changesets
  bk makepatch - creates BitKeeper patches
  bk merge - three-way text based file merge
  bk merge-binaries - help on merging binary conflicts
  bk merging - help on merging conflicts
  bk multiuser - convert a single-user repository to a multi-user repository
  bk mv - rename file[s]
  bk mvdir - rename a BitKeeper directory
  bk names - put BitKeeper files where they should be
  bk new - add a file to the repository
  bk newroot - change the identity of a repository
  bk obscure - obscure BitKeeper file comments and contents
  bk openlogging - Open Logging explanation
  bk parent - show or set the parent repository
  bk path - show the path that BK uses for all subprocesses
  bk pending - list deltas which need to be in a changeset
  bk prompt - prompt a user with a message
  bk prs - print revision summary
  bk pull - updates the repository from its parent
  bk push - send local changes to the parent repository
  bk r2c - convert file revision to ChangeSet revision
  bk range - demo program to show ranges & dates
  bk rcs2sccs - converts a CVS or RCS repository to a BitKeeper repository
  bk rcsparse - test RCS parser
  bk receive - receive a BitKeeper patch
  bk relink - recreate broken hardlinks
  bk renames -list file renames contained in a changeset or range of changesets
  bk renametool - graphical tool for finding renames
  bk renumber - regenerate the revision history numbers
  bk resolve - merge and/or apply new work after a push or a pull
  bk revtool - BitKeeper graphical history browser
  bk rm - remove BitKeeper file[s]
  bk rmdel - remove a delta from a file
  bk rmdir - remove a BitKeeper directory
  bk rmgone - remove files having keys in the gone file
  bk root - print the path name to the root of the reposi- tory
  bk rset - generate a ``release set''
  bk sane - check for various BitKeeper requirements
  bk sccslog - list deltas sorted by date across all files
  bk send - send a BitKeeper patch
  bk sendbug - file a bug report
  bk set - set operations
  bk setup - create a new BitKeeper package repository
  bk setuptool - graphical front-end to the BitKeeper setup command
  bk sfiles - generates lists of revision control files
  bk sfio - BitKeeper file archiver
  bk smerge - smart text-based 3-way file merge
  bk status - show repository status
  bk stripdel - strip deltas out of an s.file
  bk superset - check to see if the parent is ahead of the current repository
  bk tag - tag the BitKeeper repository with a symbolic name
  bk takepatch - apply a BitKeeper patch
  bk terms - definitions of BitKeeper terms
  bk treediff - compare two directory trees
  bk triggers - using BitKeeper event triggers
  bk undo - Undo a changeset or set of changesets
  bk undos - convert DOS files to UNIX files
  bk unedit - destroy any unchecked in changes to specified files
  bk unlock - remove BitKeeper file locks
  bk unpull - remove changesets added by bk pull
  bk unrm - resurrect a removed BitKeeper file
  bk unwrap - unwrap patches
  bk url - methods of accessing BitKeeper repositories
  bk users - list users of a repository
  bk version - print BitKeeper version
  bk what - look for SCCS what strings
  bk wrap - using BitKeeper wrappers
  bk xflags - check or fix BitKeeper flags
  bk zone - print BitKeeper's view of the timezone
  diff - find differences between two files
  gpl - GNU GENERAL PUBLIC LICENSE Version 2, June 1991
  patch - apply a diff file to an original

BitMover, Inc                                                   1
$
help://Overview
help://Overview.sum

Overview(sum)        BitKeeper User's Manual        Overview(sum)

NAME
  Overview - summary of the Overview category

COMMANDS
  bk Basics-Overview - BitKeeper basics to help get a new user started
  bk Howto - BitKeeper HOWTO guides
  bk Howto-bkd - howto: configuring the BitKeeper daemon
  bk Howto-developer - howto: working with BitKeeper reposi- tories
  bk Howto-setup - howto: setting up a BitKeeper repository
  bk backups - guide to doing backups of BitKeeper reposito- ries
  bk config-etc - configuring BitKeeper per repository
  bk config-gui - configuration for BitKeeper graphical tools
  bk files - summary of BitKeeper file types
  bk history - guide to viewing changes over time of files and repositories
  bk initscripts - sample script for starting the BitKeeper daemon
  bk keywords - list of RCS and SCCS keywords
  bk licensing - BitKeeper Licensing Overview
  bk merge-binaries - help on merging binary conflicts
  bk merging - help on merging conflicts
  bk range - demo program to show ranges & dates
  bk terms - definitions of BitKeeper terms
  bk url - methods of accessing BitKeeper repositories

BitMover, Inc                                                   1
$
help://Common
help://Common.sum

Common(sum)          BitKeeper User's Manual          Common(sum)

NAME
  Common - summary of the Common category

COMMANDS
  bk ci - checks in modified files
  bk citool - BitKeeper graphical check-in tool
  bk clean - removes unmodified files
  bk clone - create a new copy of a package
  bk co - check out files
  bk diffs - show differences in revision controlled files
  bk difftool - BitKeeper Graphical Diff Tool
  bk help - get help for BitKeeper commands
  bk new - add a file to the repository
  bk prs - print revision summary
  bk pull - updates the repository from its parent
  bk push - send local changes to the parent repository
  bk revtool - BitKeeper graphical history browser
  bk version - print BitKeeper version

BitMover, Inc                                                   1
$
help://Repository
help://Repository.sum

Repository(sum)      BitKeeper User's Manual      Repository(sum)

NAME
  Repository - summary of the Repository category

COMMANDS
  bk abort - abort a failed pull or push
  bk backups - guide to doing backups of BitKeeper reposito- ries
  bk bk - BitKeeper source management system front end
  bk bkd - the BitKeeper daemon
  bk changes - show changeset history
  bk check - check repository for consistency
  bk citool - BitKeeper graphical check-in tool
  bk clone - create a new copy of a package
  bk cmdlog - show the log of commands executed in this repository
  bk commit - commit deltas to a changeset
  bk cset - creates and manipulates changesets
  bk csets - run csettool on last set of imported changes
  bk csettool - BitKeeper graphical changeset browser
  bk history - guide to viewing changes over time of files and repositories
  bk id - display the identity of a package or repository
  bk import - import files or changes into a BitKeeper pack- age
  bk level - set or show the level of the repository
  bk lock - lock a repository or show lockers
  bk makepatch - creates BitKeeper patches
  bk merge - three-way text based file merge
  bk merge-binaries - help on merging binary conflicts
  bk merging - help on merging conflicts
  bk multiuser - convert a single-user repository to a multi-user repository
  bk newroot - change the identity of a repository
  bk parent - show or set the parent repository
  bk pending - list deltas which need to be in a changeset
  bk pull - updates the repository from its parent
  bk push - send local changes to the parent repository
  bk relink - recreate broken hardlinks
  bk resolve - merge and/or apply new work after a push or a pull
  bk revtool - BitKeeper graphical history browser
  bk rmgone - remove files having keys in the gone file
  bk setup - create a new BitKeeper package repository
  bk sfio - BitKeeper file archiver
  bk status - show repository status
  bk superset - check to see if the parent is ahead of the current repository
  bk tag - tag the BitKeeper repository with a symbolic name
  bk takepatch - apply a BitKeeper patch
  bk treediff - compare two directory trees
  bk triggers - using BitKeeper event triggers
  bk undo - Undo a changeset or set of changesets
  bk unlock - remove BitKeeper file locks
  bk unpull - remove changesets added by bk pull
  bk url - methods of accessing BitKeeper repositories

BitMover, Inc                                                   1
$
help://GUI-tools
help://GUI-tools.sum

GUI-tools(sum)       BitKeeper User's Manual       GUI-tools(sum)

NAME
  GUI-tools - summary of the GUI-tools category

COMMANDS
  bk bkscc - BitKeeper and SCC API
  bk citool - BitKeeper graphical check-in tool
  bk config-gui - configuration for BitKeeper graphical tools
  bk csettool - BitKeeper graphical changeset browser
  bk difftool - BitKeeper Graphical Diff Tool
  bk fmtool - BitKeeper side-by-side merge tool
  bk helptool - graphical front-end to the BitKeeper help system
  bk renametool - graphical tool for finding renames
  bk revtool - BitKeeper graphical history browser

BitMover, Inc                                                   1
$
help://File
help://File.sum

File(sum)            BitKeeper User's Manual            File(sum)

NAME
  File - summary of the File category

COMMANDS
  bk annotate - provide annotated listing of source files
  bk cat - concatenate and display file contents
  bk chmod - change the mode of a file and save it
  bk ci - checks in modified files
  bk clean - removes unmodified files
  bk co - check out files
  bk comments - change checkin comments
  bk cp - create a copy of a file preserving its revision history
  bk delta - check in modified files
  bk diffs - show differences in revision controlled files
  bk difftool - BitKeeper Graphical Diff Tool
  bk edit - check out a file for editing (writable)
  bk extras - list extra files not under revision control
  bk files - summary of BitKeeper file types
  bk findkey - look for keys in files
  bk fix - re-edit a checked in (but uncommitted) delta
  bk flags - show a listing of files and their BitKeeper flags
  bk fmtool - BitKeeper side-by-side merge tool
  bk get - check out BitKeeper files
  bk grep - search some/all revisions for a pattern
  bk info - show the state of BitKeeper files
  bk merge - three-way text based file merge
  bk mv - rename file[s]
  bk mvdir - rename a BitKeeper directory
  bk new - add a file to the repository
  bk prompt - prompt a user with a message
  bk prs - print revision summary
  bk range - demo program to show ranges & dates
  bk receive - receive a BitKeeper patch
  bk renames -list file renames contained in a changeset or range of changesets
  bk renametool - graphical tool for finding renames
  bk revtool - BitKeeper graphical history browser
  bk rm - remove BitKeeper file[s]
  bk rmdir - remove a BitKeeper directory
  bk sccslog - list deltas sorted by date across all files
  bk send - send a BitKeeper patch
  bk sfiles - generates lists of revision control files
  bk stripdel - strip deltas out of an s.file
  bk unedit - destroy any unchecked in changes to specified files
  bk unlock - remove BitKeeper file locks
  bk unrm - resurrect a removed BitKeeper file
  bk unwrap - unwrap patches
  bk what - look for SCCS what strings
  bk wrap - using BitKeeper wrappers
  bk xflags - check or fix BitKeeper flags

BitMover, Inc                                                   1
$
help://Admin
help://Admin.sum

Admin(sum)           BitKeeper User's Manual           Admin(sum)

NAME
  Admin - summary of the Admin category

COMMANDS
  bk admin - administer BitKeeper files (tags, checksums, validation)
  bk bkd - the BitKeeper daemon
  bk checksum - check and/or fix BitKeeper checksums
  bk config - show repository configuration information
  bk config-etc - configuring BitKeeper per repository
  bk config-gui - configuration for BitKeeper graphical tools
  bk csetprune - shrink a repository by removing files
  bk gone - mark a file (key) as gone
  bk id - display the identity of a package or repository
  bk ignore - ignore shell glob patterns
  bk initscripts - sample script for starting the BitKeeper daemon
  bk log - Log changesets
  bk multiuser - convert a single-user repository to a multi-user repository
  bk newroot - change the identity of a repository
  bk obscure - obscure BitKeeper file comments and contents
  bk root - print the path name to the root of the reposi- tory
  bk sane - check for various BitKeeper requirements
  bk sendbug - file a bug report
  bk users - list users of a repository
  bk version - print BitKeeper version

BitMover, Inc                                                   1
$
help://Licensing
help://Licensing.sum

Licensing(sum)       BitKeeper User's Manual       Licensing(sum)

NAME
  Licensing - summary of the Licensing category

COMMANDS
  bk bkcl - display commercial use BitKeeper license
  bk bkl - display free use BitKeeper license
  bk licensing - BitKeeper Licensing Overview
  bk openlogging - Open Logging explanation
  gpl - GNU GENERAL PUBLIC LICENSE Version 2, June 1991

BitMover, Inc                                                   1
$
help://Compat
help://Compat.sum

Compat(sum)          BitKeeper User's Manual          Compat(sum)

NAME
  Compat - summary of the Compat category

COMMANDS
  bk compatibility - Commands compatible between other SCM tools and BitKeeper
  bk emacs - info on how to use emacs' vc-mode
  bk export - checks out clear-text version of all BitKeeper files
  bk rcs2sccs - converts a CVS or RCS repository to a BitKeeper repository
  bk rcsparse - test RCS parser
  bk rmdel - remove a delta from a file

BitMover, Inc                                                   1
$
help://Utility
help://Utility.sum

Utility(sum)         BitKeeper User's Manual         Utility(sum)

NAME
  Utility - summary of the Utility category

COMMANDS
  bk base64 - RFC 1341 base64 encoding and decoding
  bk bin - show binary installation directory
  bk c2r - convert changeset revision to file revision
  bk crypto - Cryptography services
  bk gca - show the greatest common ancestor
  bk gethost - display machine name
  bk getuser - display user name
  bk gnupatch - generate traditional patches
  bk isascii - check that a file is ascii
  bk key2rev - convert BitKeeper keys to revisions
  bk links - make links to the BitKeeper binary installation directory
  bk names - put BitKeeper files where they should be
  bk path - show the path that BK uses for all subprocesses
  bk r2c - convert file revision to ChangeSet revision
  bk renumber - regenerate the revision history numbers
  bk rset - generate a ``release set''
  bk set - set operations
  bk smerge - smart text-based 3-way file merge
  bk undos - convert DOS files to UNIX files
  bk zone - print BitKeeper's view of the timezone

BitMover, Inc                                                   1
$
help://Basics-Overview
help://Basics-Overview.1
help://bk-Basics-Overview
help://bk-Basics-Overview.1

bk Basics-Overview(1)BitKeeper User's Manualbk Basics-Overview(1)

NAME
       bk  Basics-Overview  -  BitKeeper basics to help get a new
       user started

DESCRIPTION
       This section explains how to make changes to  files  under
       revision control.  If you have not created a package, then
       see the bk help setup section.

       Note that BitKeeper supports  both  the  traditional  SCCS
       commands  for checking in/out files (admin -i, delta, get)
       as well as the RCS  commands  (ci,  co).   Typically,  use
       ci/co  as  a shorthand way of doing simple operations, but
       use delta/get in automated scripts  and  when  doing  more
       complicated operations.

       As an example, go to the directory where you would like to
       make changes:

           $ cd ~/mypackage/src

       If you are starting a new package, then create  new  files
       with  any  editor and check them in.  The initial check in
       for a file that already exists will look like this:

           $ bk new coolStuff.c

       If you want to modify an existing file, you can do this:

           $ bk edit coolStuff.c

       Or, if you have multiple files in the directory,  you  can
       do  the  following  to  place all files into a state where
       they can be modified:

           $ bk edit

       If you want to lock the entire tree, including subdirecto-
       ries, try this:

           $ bk -r edit

       Locking  the  entire  directory  is  useful  when applying
       patches that will access many files in a tree.

       Once you are finished making changes  to  files,  you  can
       check in the files as follows:

           $ bk ci file1 file2 file3

       However,  we  recommend  using  the graphical checkin tool
       which is invoked with the following command:

           $ bk citool

       bk citool will help you check in both new,  modified,  and
       pending files.

DOCUMENTATION
       Each  command in BitKeeper has command-specific help.  You
       can access individual help topics by typing:

           $ bk help <command>      # e.g., "bk help co"

       There are also a number of other topics that describe var-
       ious  areas  in  detail. Try bk help for a listing of help
       topics.

SEE ALSO
       bk help ci
       bk help edit
       bk help get
       bk help new
       bk help citool

CATEGORY
       Overview

BitMover, Inc               2002/09/17                          1
$
help://Howto
help://Howto.1
help://bk-Howto
help://bk-Howto.1
help://General/Quickstart
help://quickstart

bk HOWTO(1)          BitKeeper User's Manual          bk HOWTO(1)

NAME
       bk Howto - BitKeeper HOWTO guides

DESCRIPTION
       Howto  guides  are  recipes for accomplishing common tasks
       with BitKeeper.  The guides contain little or no  explana-
       tions.   Each  command has detailed help which you can see
       by running bk help <command>.

       Project leads should read the bk help Howto-setup  and  bk
       help  Howto-bkd sections.  Developers who just want to use
       an existing package only need to read
       bk help Howto-developer.

SEE ALSO
       bk help Howto-bkd
       bk help Howto-developer
       bk help Howto-setup

CATEGORY
       Overview

BitMover, Inc               2002/09/17                          1
$
help://Howto-bkd
help://Howto-bkd.1
help://bk-Howto-bkd
help://bk-Howto-bkd.1
help://qs_admin

bk HOWTO-bkd(1)      BitKeeper User's Manual      bk HOWTO-bkd(1)

NAME
       bk Howto-bkd - howto: configuring the BitKeeper daemon

DESCRIPTION
       Here  are examples how to configure the bk daemon for both
       read-only and read-write modes.  We show how to export all
       repositories  on a system in both read-write and read-only
       mode and we show how to export only a specific  repository
       in read-write and read-only mode.

           # Configure BitKeeper daemon for read-only
           # access for all repositories
           bk bkd -d -xpush

           # Configure BitKeeper daemon for read-write
           # access for all repositories
           bk bkd -d

           # Access a specific repository when multiple
           # ones are being exported
           bk clone bk://host.domain/some/dir/master ~/my_tree

           # Configure a specific BitKeeper repository
           # for read-write access
           cd /master/repository
           bk bkd -d -p6666 -xcd

           # Configure a specific BitKeeper repository
           # for read-only access
           cd /master/repository
           bk bkd -d -p4444 -xcd -xpush

           # Access a repository bound to a specific port
           bk clone bk://host.domain:6666 ~/my_tree

SEE ALSO
       bk help bkd
       bk help Howto

CATEGORY
       Overview

BitMover, Inc               2002/09/17                          1
$
help://Howto-developer
help://Howto-developer.1
help://bk-Howto-developer
help://bk-Howto-developer.1
help://qs_developer
help://qs_dev

bk HOWTO-developer(1)BitKeeper User's Manualbk HOWTO-developer(1)

NAME
       bk Howto-developer - howto: working with BitKeeper reposi-
       tories

DESCRIPTION
       Here is an example sequence of commands used to  create  a
       new package, import files into the package, create a clone
       of the package for modifications,  do  some  work  in  the
       clone, pull new work from the master tree down, merge, and
       then push the work back up.

           # Create a clone on your development machine.
           # The destination directory should not exist.
           bk clone bk://host.domain:6666/project ~/myproject

           # Do some work.
           cd ~/myproject
           bk vi index.cgi

           # Check it in and create a changeset.
           bk citool

           # Pull any new work down from the work tree.
           # This example assumes that someone else also changed
           # "index.cgi" and their changes overlapped the local changes.
           # The pull command will say that there are
           # overlapping changes and will not apply the new work.
           bk pull

           # Resolve the conflicts.  This step is only necessary if pull
           # said there were conflicts which could not be automerged.
           bk resolve

           # push the merge and the local changes back up.
           bk push

SEE ALSO
       bk help Howto

CATEGORY
       Overview

BitMover, Inc               2002/09/17                          1
$
help://Howto-setup
help://Howto-setup.1
help://bk-Howto-setup
help://bk-Howto-setup.1
help://qs_setup

bk HOWTO-setup(1)    BitKeeper User's Manual    bk HOWTO-setup(1)

NAME
       bk Howto-setup - howto: setting up a BitKeeper repository

DESCRIPTION
       Here  are examples on how to setup the initial repository,
       import from plain files, a CVS repository, and/or  an  RCS
       repository.

       In order to do an import, the destination repository needs
       to exist.  bk  setup  is  used  when  creating  the  first
       instance of a repository.

           # Setup initial repository
           cd ~/projects
           bk setup test_package

           # Import of plain files from a tar archive.
           # In order to do an import, the destination
           # repository needs to exist.  Notice that we put the
           # package in subdirectory, this is useful.
           mkdir /tmp/gcc
           cd /tmp/gcc
           tar zxf /tmp/gcc-2.95.2.tgz
           bk import -tplain /tmp/gcc ~/projects/test_package

           # Import of a CVS tree which resides in /tmp/mycvsproject.
           bk import -tCVS /tmp/mycvsproject ~/projects/test_package

           # Import of a RCS tree which resides in /tmp/myrcsproject.
           bk import -tRCS /tmp/myrcsproject ~/projects/test_package

SEE ALSO
       bk help Howto

CATEGORY
       Overview

BitMover, Inc               2002/09/17                          1
$
help://abort
help://abort.1
help://bk-abort
help://bk-abort.1

bk abort(1)          BitKeeper User's Manual          bk abort(1)

NAME
       bk abort - abort a failed pull or push

SYNOPSIS
       bk abort [-f] [<repository_root>]

DESCRIPTION
       The  abort command can be used to clean up a failed update
       of a repository so that you  can  try  the  update  again.
       Updates  sometimes  fail,  leaving  the PENDING and RESYNC
       directories behind.  Since the  existence  of  the  RESYNC
       directory  acts  as a global repository lock, you probably
       don't want to leave it there for  an  extended  period  of
       time.

       If  the  update  (i.e.,  a  bk pull or bk push) failed and
       there has been no manual resolve work done yet,  there  is
       no  harm  in aborting and trying again.  If manual resolu-
       tion has been done, it may be worth the effort  to  figure
       out what went wrong and try to fix it.

OPTIONS
       -f     Do not prompt for confirmation, just do it.

BUGS
       Abort  should go look to see if you have done any work and
       refuse to abort without -f if you have.

SEE ALSO
       bk help pull
       bk help push

CATEGORY
       Repository

BitMover, Inc               2003/06/04                          1
$
help://admin
help://admin.1
help://bk-admin
help://bk-admin.1

bk admin(1)          BitKeeper User's Manual          bk admin(1)

NAME
       bk  admin  -  administer BitKeeper files (tags, checksums,
       validation)

SYNOPSIS
       bk admin options [<file> ... | -]

DESCRIPTION
       The admin command is used to create and/or administer Bit-
       Keeper files.

OPTIONS
       -0              add  a  1.0  delta  if  there  is  not one
                       already.
       -C[<csetfile>]  set or remove the changeset  file  pointer
                       in  the  1.0  delta (very rarely used, not
                       recommended).
       -D              remove the  delta  changeset  marks  (very
                       rarely used, not recommended).
       -E<enc>         force file to be encoded with <enc>, which
                       may be:
           text        regular text file (typical)
           ascii       same as <text>
           binary      force binary file (data will be uuencoded in s.file).

       -f<flag>        set <flag> which can be any of:
           BITKEEPER   mark the file as a BitKeeper file (very rarely  used,
                       not recommended)
           DEFAULT=<r> set the default branch or revision used by the bk get
                       command.
           EXPAND1     expand keywords in first line that contains  keywords
                       only  (printf  conflicts)  EXPAND1 must be explicitly
                       set or set in the BitKeeper/etc/config file.  See  bk
                       help config-etc.
           EOLN_NATIVE use  the operating system's native end-of-line termi-
                       nation.  EOLN_NATIVE is set to "on" by  default.   To
                       make the default have EOLN_NATIVE be set to "off" put
                       eoln:unix in the BitKeeper/etc/config  file  (see  bk
                       help config-etc).
           MONOTONIC   mark  the  file  as  a monotonically increasing file.
                       Monotonic files do not roll backwards with  the  rest
                       of  the  repository  as  a  result of a bk undo or bk
                       clone -r.  Suggested for the BitKeeper/etc/* files.
           NOMERGE     do not attempt to automerge this file, treat it as if
                       it  were  a  binary  file and force a choose local or
                       choose remote style merge.
           RCS         expand RCS keywords, i.e., $keyword$ etc.   RCS  must
                       be  explicitly set or set in the BitKeeper/etc/config
                       file.  See bk help config-etc.
           SCCS        expand SCCS keywords, i.e., %K% etc.   SCCS  must  be
                       explicitly  set  or  set  in the BitKeeper/etc/config
                       file.  See bk help config-etc.
           YEAR4       display dates as 4 digit years
           EOLN_NATIVE use the operating system's native end-of-line  termi-
                       nation.   EOLN_NATIVE  is set to "on" by default.  To
                       make the default have EOLN_NATIVE be set to "off" put
                       eoln:unix  in  the  BitKeeper/etc/config file (see bk
                       help config-etc).
           NOMERGE     do not attempt to automerge this file, treat it as if
                       it  were  a  binary  file and force a choose local or
                       choose remote style merge.
           DEFAULT=<rev>
                       set the default branch or revision used by the bk get
                       command.

       -F<f>  delete flag <f>, reverting to default behavior
       -h     check  s.file  structure  in  general, but limited to ATT SCCS
              features.
       -hh    as above, but also check BitKeeper structure.
       -hhh   as above, but also check time stamps.
       -H     same as -h, plus check that file contents are ASCII.
       -i[<file>]
              read initial text from <file> (default stdin).
       -M<merge>
              Mark branch specified  by  revision  <merge>  as  merged  into
              <rev>, if specified, or top of trunk.
       -p[<path>]
              set  path  of  the  most recent delta to <path>, if <path> was
              specified, otherwise use the current file location.  Note: not
              a timesafe operation, typically used only by bk import.
       -q     run quietly.
       -r<rev>
              may  be  used  with -M to specify a revision other than top of
              trunk, and, when not in a BitKeeper  repository,  with  -i  to
              specify the initial revision.
       -S<sym>=<rev>
              associate symbolic name (tag) <sym> with revision <rev>.
       -t<file>
              read  description  text  from  <file>  and replace the current
              descriptive text, if any.
       -T     clear description text.
       -u     force all timestamps to be increasing  (very  dangerous,  this
              changes the keys).
       -y<comment>
              make  <comment> be the checkin comment for the initial checkin
              (only valid with -i and -n).
       -z     recalculate file checksum.
       -Z<alg>
              compress stored s.file with <alg> which may be:
              gzip   like gzip(1)
              none   no compression

BUGS
       This command does way too much and is likely to  be  split
       apart.  Do not depend on these options for scripts.

SEE ALSO
       bk help chmod
       bk help delta
       bk help get
       bk help prs
       bk help tag
       bk help keywords
       bk help config-etc

CATEGORY
       Admin

BitMover, Inc               2003/08/08                          1
$
help://annotate
help://annotate.1
help://bk-annotate
help://bk-annotate.1
help://sccscat
help://bk-sccscat
help://sccscat.1
help://bk-sccscat.1

bk annotate(1)       BitKeeper User's Manual       bk annotate(1)

NAME
       bk annotate - provide annotated listing of source files

SYNOPSIS
       bk annotate [-adkmNnu] [-c<dt>] [-r<rev>] [<file> ... | -]
       bk sccscat [-dmnNu] [-c<dates>] [-r<rev>] [<file> ... | -]

DESCRIPTION
       Annotated  listings are useful for deeper understanding of
       your source base, i.e., when you are tracking  down  bugs.
       The  annotations  add  an extra level of information which
       can be useful.

       BitKeeper has two kinds of annotations:  annotations of  a
       specific  version,  and  annotations of all (or some) ver-
       sions (the second form is unique to BitKeeper).

ANNOTATE
       The annotate command will display a specific version of  a
       file  with  annotations.   The default annotations are the
       revision in which the change was made  and  the  user  who
       made that change.  Specifying any options overrides all of
       the default options.

SCCSCAT
       By default, bk sccscat will display all lines in all  ver-
       sions  of  a  file,  with  each  version of a line grouped
       closely with other versions of that line.  This is  useful
       for determining when a particular feature was added.

       bk  sccscat  can  restrict  the  set of lines displayed to
       those lines added in a specified revision or  date  range.
       In  that  case,  the whole file is not displayed, instead,
       only the lines which were added in that range  of  changes
       are  displayed.  This form is usually a result of specify-
       ing a range to bk grep.

OPTIONS
       -a        Align prefix output in a  human  readable  form.
                 Used  with one of the following options [mNnud].
       -c<date>  bk annotate: annotate the latest version  before
                 <date>.  See bk range for date specs;
                 bk  sccscat: annotate the set of versions match-
                 ing the range <date>.  See  bk  range  for  date
                 specs.
       -d        Prefix each line with the date of last modifica-
                 tion.
       -k        bk annotate: do not expand RCS or SCCS keywords.
                 bk sccscat never expands keywords.
       -m        Prefix each line with the revision of last modi-
                 fication.
       -N        Prefix each line with its line number.
       -n        Prefix each line with the filename.
       -r<rev>   bk annotate: annotate this revision;
                 bk sccscat: annotate the  lines  added  by  this
                 revision.
       -u        Prefix each line with the user who last modified
                 it.

SEE ALSO
       bk help get
       bk help grep
       bk help range
       bk help revtool

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://backups
help://backups.1
help://bk-backups
help://bk-backups.1
help://backup

bk backups(1)        BitKeeper User's Manual        bk backups(1)

NAME
       bk backups - guide to doing backups of BitKeeper reposito-
       ries

DESCRIPTION
       BitKeeper repositories with no pending files can be safely
       backed  up with any backup tool, such as tar or dump, etc.
       To see if there are any pending files, run

           bk pending

       No output indicates no pending files.

WARNING
       If the repository  has  pending  files  (files  which  are
       checked  in  but  not  yet committed to a changeset), then
       saving and restoring the repository should be  done  care-
       fully.   Problems  can arise if the repository is restored
       multiple times and the same pending deltas  are  committed
       to  different  changesets.   In other words, the following
       will cause problems:

           cd REPO
           bk edit foo.c
           echo "I am a pending delta not yet committed" >> foo.c
           bk delta -yPENDING foo.c
           cd ..
           cp -r REPO COPY
           cd REPO
           bk commit
           cd ../COPY
           bk commit

       Why is it a problem?  Because the two commits both created
       a changeset, and the changesets are different.  This means
       that the same delta to foo.c now belongs to two  different
       changesets.  It is not fatal when this happens, but it may
       make it difficult to roll backwards to this point.

SUGGESTION
       If what you want is a copy of the repository, use bk clone
       to  copy it, not tar, cp, or some other file by file copy.

SEE ALSO
       bk help pending
       bk help sfiles
       bk help status

CATEGORY
       Overview
       Repository

BitMover, Inc               2002/09/17                          1
$
help://base64
help://base64.1
help://bk-base64
help://bk-base64.1

bk base64 1 2002/09/03 (BitMoverb,k)base64 1 2002/09/03 (BitMover,)

NAME
       bk base64 - RFC 1341 base64 encoding and decoding

SYNOPSIS
       bk base64 [-d]

DESCRIPTION
       The  base64  command  is  a filter that encodes arbritrary
       data from stdin to a ASCII format that only uses the char-
       acters  A-Z,a-z,0-9,/,+,=  and newline to encode the data.
       This data can easily be emailed without being mangled.  If
       the  -d  option is passed then the encoding is unpacked to
       the orignal data.

OPTIONS
       -d        Decode base64 data to the orignal byte stream.

SEE ALSO
       bk help crypto

CATEGORY
       Utility

BitKeeper User's Manual        Inc"                             1
$
help://bin
help://bin.1
help://bk-bin
help://bk-bin.1

bk bin(1)            BitKeeper User's Manual            bk bin(1)

NAME
       bk bin - show binary installation directory

SYNOPSIS
       bk bin

DESCRIPTION
       Returns  the  full path to the directory containing the bk
       installation.

       To read man page documentation in a single file do:

           vi `bk bin`/bkhelp.txt

CATEGORY
       Utility

BitMover, Inc               2002/03/11                          1
$
help://bk
help://bk.1
help://bk-bk
help://bk-bk.1

bk(1)                BitKeeper User's Manual                bk(1)

NAME
       bk bk - BitKeeper source management system front end

SYNOPSIS
       bk <command> [<options>]
       bk -R <command> [<options>]
       bk [-r[<dir>]] <command> [<options> ]
       bk [-sfiles_opts] -r[<dir>]

DESCRIPTION
       bk  is  the front end to all BitKeeper commands.  All Bit-
       Keeper commands are prefixed with bk  in  order  to  avoid
       ambiguity with non-BitKeeper commands that might be on the
       system such as get and ci.

OPTIONS
       -R        Change directories to the root of the repository
                 before running the command.
       -r[<dir>] Starting  at  <dir>,  or  the repository root if
                 <dir>  was  not  specified,  apply  the  command
                 recursively  to  <dir>  and  all subdirectories.
                 This works by generating a list  of  sfiles  and
                 passing them to the command.
       -sfiles_opts
                 Used  as  a  shortcut for sfiles.  The following
                 sfiles options may be passed:

                 -a     examine all files, even if listed in Bit-
                        Keeper/etc/ignore.
                 -c     List changed files (locked and modified).
                 -d     List directories under BitKeeper  control
                        (SCCS subdir exists).
                 -D     List  directories with no (or empty) SCCS
                        subdirs.
                 -e     shorthand for -jluvx
                 -E     shorthand for -cjluvxp
                 -g     List the gfile name, not the sfile  name.
                 -i     shorthand for -cjlvxp aka the interesting
                        state.
                 -j     List junk files, i.e., files in SCCS sub-
                        directories which are not metadata.
                 -l     List locked files (p.file and/or z.file).
                 -n     list s.files that are not in the  correct
                        location.   (Must  be run from repository
                        root, bk -r sfiles -n.)
                 -p[<A|C>]
                        list files with pending deltas.   If  -pC
                        then  list  leaves  which  are  not  in a
                        changeset  as  file|1.3  If   -pA,   that
                        implies -pC, and lists all revisions, not
                        just the tip.
                 -S     produce a summary listing only, typically
                        combined with -E.
                 -u     List unlocked files.
                 -U     list  user files only, skipping all files
                        in the BitKeeper/ subdirectory as well as
                        the ChangeSet file.
                 -v     Prefix  the output with information about
                        the state of the s.file.  The information
                        is  in a 4 character field, followed by a
                        space, then  followed  by  the  filename.
                        Each of the columns are described below:
                        l???   the file is locked
                        u???   the file is unlocked
                        jjjj   the file is junk
                        xxxx   the file is an extra
                        ?c??   the file is modified (changed)
                        ??p?   the file has pending deltas
                 -x     List files which have no revision control
                        files.

NOTE
       The following commands are equivalent:
           bk -r get
           bk -R sfiles | bk -R get -
           cd `bk root`; bk sfiles | bk get -

SEE ALSO
       bk help sfiles

CATEGORY
       Repository

BitMover, Inc               2003/02/21                          1
$
help://bkcl
help://bkcl.1
help://bk-bkcl
help://bk-bkcl.1

bk bkcl(1)           BitKeeper User's Manual           bk bkcl(1)

NAME
       bk bkcl - display commercial use BitKeeper license

LICENSE

                     BITKEEPER SOFTWARE LICENSE AGREEMENT

       BITMOVER,  INC  ("BitMover")  IS WILLING TO LICENSE THE SOFTWARE
       ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF  THE  TERMS  CON-
       TAINED  IN  THIS LICENSE AGREEMENT.  PLEASE READ THE TERMS CARE-
       FULLY.  BY CLICKING ON "ACCEPT" AND/OR INSTALLING THE  SOFTWARE,
       YOU WILL INDICATE YOUR AGREEMENT WITH THEM.  IF YOU DO NOT AGREE
       WITH THESE TERMS, THEN BITMOVER  IS  UNWILLING  TO  LICENSE  THE
       SOFTWARE  TO  YOU,  IN  WHICH  EVENT YOU SHOULD NOT PROCEED WITH
       INSTALLING OR USING THE SOFTWARE.

       1.  Software.

       The parties are entering into this  Agreement  to  establish  an
       arrangement  whereby  Licensee  may temporarily evaluate and, at
       its option, obtain an Operating License for certain  application
       software programs, as described more fully in the attached Prod-
       uct Schedule and accompanying Documentation (the "Software")  on
       terms and subject to the conditions set forth herein.

       2.  Scope of Use.

       BitMover  expressly  reserves  all  rights  in  the Software not
       specifically granted to Licensee.

       (a)  Evaluation License.   The Licensee is granted an evaluation
            license  authorizing  it  to install, store, load, execute,
            display and evaluate internally (collectively,  "Evaluate")
            the  Software  on  the same terms and conditions applicable
            under Section 2(b) ("Operating License") for  a  period  of
            thirty (30) calendar days after execution of this Agreement
            (the "Evaluation Period").  In the event the Licensee  con-
            tinues  use of the Software after completion of the Evalua-
            tion Period, the Licensee shall be deemed to have  accepted
            an  Operating  License to Use the Software under Subsection
            (b) ("Operating License")  in  accordance  with  the  other
            terms  and  conditions  of  this Agreement; otherwise, this
            Agreement shall be deemed  terminated  and  Licensee  shall
            destroy  all  copies  of  the Software in its possession or
            control.

       (b)  Operating License.  Licensee is granted a world-wide nonex-
            clusive  license to install, store and load the Software on
            appropriately configured equipment and to allow its  autho-
            rized  users for whom the applicable fees have been paid or
            will be paid upon receipt of invoice to use,  execute,  and
            display ("Use") the Software for its ordinary and customary
            business purposes on behalf of itself and its affiliates.

       (c)  Transfer of License.  Except as specifically authorized  in
            another provision of this Agreement and/or the attached Fee
            Schedule, neither this Agreement, nor any rights or obliga-
            tions  hereunder,  may be transferred, assigned, delegated,
            sub-licensed, relocated or  moved  to  another  person,  in
            whole  or in part, without BitMover's prior written consent
            and any attempt to the contrary shall be  void  and  of  no
            legal effect.

       3.  Term.

       Perpetual  and/or  Leased  Licenses  shall  be  indicated in the
       attached Licenses Schedule.   3(a)  ("Leased  Licenses")  and/or
       3(b)  ("Perpetual  Licenses")  shall apply only if corresponding
       Licenses are indicated in the attached Licenses Schedule.

       (a)  Leased Licenses: This Agreement shall commence on  the  1st
            of  the  month  closest  to  the date of acceptance of this
            agreement, such acceptance indicated by  clicking  "ACCEPT"
            below,  and  shall  continue in full force and effect for a
            period of three (3) months, six (6) months, or one (1) year
            ("Initial  Term")  as  indicated  in the Licenses Schedule,
            unless terminated earlier in  accordance  with  Section  14
            ("Termination").  The  Term  shall automatically be renewed
            for successive like periods (each, a "Renewal Term") unless
            Licensee  notifies BitMover at least thirty (30) days prior
            to the expiration of the Initial Term (or Renewal Term,  as
            the  case  may be) that the Agreement shall not be renewed.
            The Initial Term and  any  Renewal  Term  are  collectively
            referred  to  herein as the "Term".  Upon renewal, Licensee
            shall pay any applicable License Fee with respect  to  such
            Software.  Renewal  of  the Term shall not operate to renew
            any warranty obligations under Section 11 ("Warranties  and
            Indemnification").  Renewal procedures are described in the
            Fee Schedule, and unless such procedures are strictly  sat-
            isfied,  including  payment  of any required license and/or
            support fees, Licensee's use of the Software for  any  pur-
            pose  after  the  expiration of the term is not authorized.
            Upon expiration of the Term the Software may  automatically
            disable itself.

       (b)  Perpetual  Licenses:  This  Agreement shall commence on the
            1st of the month closest to the date of acceptance of  this
            agreement,  such  acceptance indicated by clicking "ACCEPT"
            below, and shall continue in full force and effect in  per-
            petuity,  unless terminated earlier in accordance with Sec-
            tion 14 ("Termination").  The annual support  option  shall
            automatically be renewed for successive like periods unless
            Licensee notifies BitMover at least thirty (30) days  prior
            to  the  expiration  of  the annual support option that the
            annual support option shall not be renewed.  Upon  renewal,
            Licensee  shall pay any applicable Support Fee.  Renewal of
            the annual support option shall not operate  to  renew  any
            warranty  obligations  under  Section  11  ("Warranties and
            Indemnification").  Renewal procedures are described in the
            Fee  Schedule, and unless such procedures are strictly sat-
            isfied, including payment of any  required  license  and/or
            support  fees,  Licensee's use of the Software for any pur-
            pose after the expiration of the term is not authorized.

       4.  Restrictions.

       You may not: (i) modify or translate the Software; (ii)  reverse
       engineer,  decompile, or disassemble the Software, except to the
       extent this restriction is expressly  prohibited  by  applicable
       law;  (iii) rent, lease, loan, resell or create derivative works
       based on the Software (iv) merge the Software with another prod-
       uct;  (v)  separate  the Software into its component parts; (vi)
       copy the Software, except as expressly provided herein,  and  as
       reasonably necessary for back up and recovery purposes; or (vii)
       remove or obscure any proprietary rights notices, labels,  copy-
       rights, trademarks, and/or servicemarks on the Software.

       5.  Program Code & Documentation.

       (a)  Program  Code.   The Software shall be provided to Licensee
            and Used strictly in machine-readable object  code  format.
            No   source   code  or  technical-level  documentation  are
            licensed under this Agreement.

       (b)  Program Documentation.  The Licensee shall be provided with
            online  documentation, included with the Software, describ-
            ing in reasonable detail understandable by a user  of  gen-
            eral proficiency the use and operation of the Software. The
            Documentation shall be supplied in magnetic form and may be
            reproduced by Licensee for purposes authorized herein.

       6.  Acceptance.

       The  Software  shall  be  deemed  accepted  by  Licensee  unless
       Licensee notifies BitMover in writing of a  material  defect  in
       the  Software  within  ten (10) business days after delivery and
       commencement of the Operating License.

       7.  Support Services.

       If Lease is indicated in the attached Licenses Schedule,  for  a
       period  of five (5) years after expiration of any warranty under
       Section 11  ("Warranties  and  Indemnification"),  the  Licensee
       shall  have the option (exercised by payment of the Annual Lease
       Fee set forth in the then current Fee Schedule) to  receive  the
       Software support services set forth below.

       If Perpetual is indicated in the attached Licenses Schedule, for
       a period of five (5) years  after  expiration  of  any  warranty
       under   Section   11  ("Warranties  and  Indemnification"),  the
       Licensee shall have the option  (exercised  by  payment  of  the
       Annual  Support  Fee set forth in the then current Fee Schedule)
       to receive the Software support services set forth below.

       (a)  Hotline  Service.   Assistance  for  error  correction  and
            advice  on the use and operation of the all maintained ver-
            sions of the Software, Monday  through  Friday,  from  9:00
            a.m.  to 5:00 p.m., BitMover's local time. Service requests
            transmitted during non-business hours shall  be  considered
            received  by  BitMover  on  the  next business day. Trouble
            Reports shall be communicated by  telephone  or  telecopier
            machine  and shall provide sufficient information to enable
            BitMover to replicate and diagnose  the  reported  problem.
            BitMover  shall  be provided reasonable access to the Soft-
            ware via remote dial-in contact, subject to Licensee's nor-
            mal security requirements. Unless otherwise agreed, out-of-
            scope work or maintenance  work  outside  regular  business
            hours  shall  be subject to a surcharge equal to BitMover's
            current labor rate.

       (b)  Updates. Copies of each revision or "Update" to  the  Soft-
            ware  and associated Documentation which BitMover generally
            distributes. BitMover's designation of an  item  as  a  new
            version  or  an  enhancement rather than an Update shall be
            conclusive unless clearly erroneous.  BitMover  shall  pro-
            vide  maintenance for all versions of the Software released
            within six months of the most recent version of  the  Soft-
            ware.

       (c)  Certain  Conditions.   BitMover  shall  not be obligated to
            provide maintenance service if: (i) the reported error  was
            caused  by  unauthorized  changes  in Software source code,
            program parameters or other user adjustable features;  (ii)
            the  error  results from operator error, errors in data not
            supplied by BitMover or use that is not in accordance  with
            the  Documentation or specifications; (iii) the error is in
            a prior release that was corrected through issuance  of  an
            Update  that Licensee has failed to install, (iv) the Soft-
            ware does not pass the included regression tests  when  run
            on the Licensee's system, or (v) the Licensee has failed to
            pay any required Annual Support  Fee  or  is  otherwise  in
            default of this Agreement.

       (d)  Training.  This Agreement does not provide for any Training
            Services with respect to the use and operation of the Soft-
            ware.  BitMover  shall  be  reasonably available to provide
            Training Services under a signed amendment to  this  Agree-
            ment  and  in  consideration  for  a Training Fee (or other
            pricing arrangement) reasonably acceptable to each party.

       8.  Prices & Payment.

       The prices and fees for Software or  other  technology  provided
       hereunder,  any  Support Services and other deliverables are set
       forth on the Fee Schedule. License Fees  shall  be  invoiced  as
       specified  in  the  Fee Schedule. Invoiced amounts shall be paid
       within thirty (30) days from receipt of  invoice.  Licensee  may
       not  withhold  or  "setoff"  any amounts due hereunder. BitMover
       reserves the right to stop work  and  assert  appropriate  liens
       until  all  amounts due are paid in full. Any late payment shall
       be subject to any  costs  of  collection  (including  reasonable
       legal  fees) and shall bear interest at the rate of one and one-
       half (1.5) percent per month or  fraction  thereof  until  paid.
       Prices  quoted  do not include and Licensee shall pay, indemnify
       and hold BitMover harmless from all sales/use,  gross  receipts,
       value-added,  GST  other  tax  (including interest and penalties
       imposed thereon) on the transaction contemplated herein.

       9.  Ownership.

       Bitmover and its suppliers own the Documentation,  the  Software
       and all intellectual property rights embodied therein, including
       copyrights and valuable trade secrets embodied in the Software's
       design  and  coding  methodology.   The Software is protected by
       United States copyright laws  and  international  treaty  provi-
       sions.   This  Agreement  provides  Licensee  only a limited use
       license, and no ownership of any intellectual property.

       10.  Confidentiality.

       (a)  Acknowledgment. Licensee  hereby  acknowledges  and  agrees
            that  the Software and Documentation constitute and contain
            valuable proprietary products and trade secrets of BitMover
            and/or   its   suppliers,  embodying  substantial  creative
            efforts and confidential information,  ideas,  and  expres-
            sions.    BitMover  hereby  acknowledges  and  agrees  that
            Licensee may provide BitMover with confidential information
            during  the  course  of normal use and support of the Soft-
            ware.  Accordingly, each party agrees to treat confidential
            information in accordance with the confidentiality require-
            ments and conditions set forth below.

       (b)  Exclusions.  Confidential Information does not include: (i)
            information  already  known  or  independently developed by
            either party outside the scope of this relationship by per-
            sonnel  not  having access to any Confidential Information;
            (ii) information in the public domain through  no  wrongful
            act  of  either  party;,  or  (iii) information received by
            either party from a third party who was  free  to  disclose
            it.

       (c)  Maintenance of Confidential Information.  Each party hereby
            agrees during the Term and at all times thereafter to  keep
            confidential  all  confidential information disclosed to it
            by the other party  in  accordance  herewith.   Each  party
            shall  use at least the same degree of care in safeguarding
            the Confidential Information as they  use  in  safeguarding
            their  own  confidential information, but in no event shall
            less than due diligence and care be exercised. Upon  termi-
            nation,  each party shall destroy all Confidential Informa-
            tion in their possession or control and cease  all  further
            use thereof.  Neither the Licensee nor any recipient shall:
            (i) alter or remove from any Software or  associated  Docu-
            mentation  any  proprietary,  copyright, trademark or trade
            secret legend, or (ii) attempt to decompile, disassemble or
            reverse  engineer the Software (and any information derived
            in violation of such covenant shall automatically be deemed
            Confidential  Information owned exclusively by BitMover and
            its suppliers).

       (d)  Disclosures Required by  Law.   If  a  receiving  party  is
            legally compelled to disclose any of the disclosing party's
            Confidential Information, then, prior to  such  disclosure,
            the receiving party will (a) assert the privileged and con-
            fidential nature of the Confidential  Information  and  (a)
            cooperate  fully  with  the  disclosing party in protecting
            against any such disclosure and/or obtaining  a  protective
            order  narrowing the scope of such disclosure and/or use of
            the Confidential Information. In the event such  protection
            is  not  obtained,  the  receiving party shall disclose the
            Confidential Information only to the  extent  necessary  to
            comply with the applicable legal requirements.

       (e)  Injunctive  Relief.   Each party acknowledges that a breach
            or threatened breach of the provisions of this  Section  10
            ("Confidentiality")  would  cause irreparable harm not ade-
            quately compensable by monetary  damages.  In  addition  to
            other  relief, it is agreed that injunctive relief shall be
            available without necessity of posting bond to  prevent  or
            remedy any such breach.

       11.  Warranties and Indemnification.

       (a)  General  Warranties.  BitMover represents and warrants that
            it has the legal right to grant the Licensee the license as
            set out in this Agreement.

       (b)  Non-infringement  Warranty.   BitMover  represents and war-
            rants that the Software, when properly used as contemplated
            herein,  will  not  infringe  or  misappropriate any United
            States copyright, trademark, patent, or  trade  secrets  of
            any  third  persons  and  that  there are no such claims of
            infringement or misappropriation as of the date hereof.

       (c)  Indemnification.  Notwithstanding any  other  provision  of
            this  Agreement,  BitMover shall defend, indemnify and hold
            harmless Licensee and its officers,  directors,  sharehold-
            ers, employees, accountants, attorneys, agents, affiliates,
            subsidiaries, successors and assigns against any  claim  or
            threat  of  claim that the Software infringes on any intel-
            lectual property right of any third party.  BitMover  shall
            pay court costs, legal fees and litigation expenses as they
            are incurred, and any damages finally awarded or settlement
            agreed  upon,  resulting  from  any such claim or threat of
            claim, provided that Licensee (i) promptly  gives  BitMover
            written  notice  of any such claim, (ii) gives BitMover the
            full authority to defend any such claim, and (iii) provides
            BitMover  with  all  information  and  assistance  BitMover
            requests in connection with such defense.  Upon being noti-
            fied  of  such  a  claim, BitMover shall (i) defend through
            litigation or  obtain  through  negotiation  the  right  of
            Licensee  to  continue  using the Software; (ii) rework the
            Software so as to make it non-infringing  while  preserving
            the  original  functionality, or (iii) replace the Software
            with functionally equivalent  software.   If  none  of  the
            foregoing alternatives provide an adequate remedy, Licensee
            may terminate all or any part of this Agreement and recover
            amounts paid for the infringing Software within the Term.

       (d)  Limited Performance Warranty.  BitMover represents and war-
            rants for a period of ninety (90) days ("Warranty  Period")
            that  it  will make a reasonable effort to ensure the Soft-
            ware operates substantially in accordance with the applica-
            ble  Documentation;  provided,  that  (i)  the  Software is
            installed, implemented and operated in accordance with  all
            instructions  supplied  by BitMover; (ii) Licensee notifies
            BitMover of any such defect within ten (10)  calendar  days
            after  the  appearance thereof; (iii) Licensee has properly
            installed all updates made available with  respect  to  the
            Software,  and updates recommended by BitMover with respect
            to any third party software products  (including  operating
            system  software) that materially affect the performance of
            the Software; (iv) Licensee  has  properly  maintained  all
            associated equipment, software and environmental conditions
            in accordance with applicable specifications  and  industry
            standards;  (v) Licensee has not introduced other equipment
            or software creating an adverse  impact  on  the  Software;
            (vi) Licensee has paid all amounts due hereunder and is not
            in default of any provision of this  Agreement;  (vii)  any
            Functional  Design or Specification provided by Licensee is
            an accurate and complete rendering  of  the  relevant  fea-
            tures, applicable interfaces and associated operating envi-
            ronment, and (viii) Licensee has made no changes (nor  per-
            mitted  any  changes  to  be made other than by or with the
            express approval of BitMover) to the Software source  code.

       (e)  No Undocumented Features.  BitMover represents and warrants
            that it will scan the Software with commercially  available
            anti-virus  software  and shall use due diligence to remove
            viruses capable of being detected with such  software.  All
            corrections  shall  be  as  fully warranted as the original
            work through expiration of the original Warranty Period.

       (f)  Warranty Disclaimer.  EXCEPT AS  SPECIFICALLY  PROVIDED  IN
            THIS  SECTION  ("WARRANTIES  AND INDEMNIFICATION") BITMOVER
            HEREBY DISCLAIMS WITH RESPECT  TO  ALL  LICENSED  PRODUCTS,
            SUPPORT  SERVICES OR OTHER DELIVERABLES PROVIDED HEREUNDER,
            ALL EXPRESS AND IMPLIED WARRANTIES, INCLUDING  ANY  IMPLIED
            WARRANTIES OF MERCHANTABILITY, TITLE, ACCURACY, INTEGRATION
            OR FITNESS  FOR  A  PARTICULAR  PURPOSE.  ANY  UNAUTHORIZED
            CHANGES  TO SOURCE CODE TO A LICENSED PRODUCT WILL VOID THE
            WARRANTY PROVIDED UNDER THIS SECTION.

       12.  Limitation of Remedies & Liabilities.

       The parties acknowledge that the following provisions have  been
       negotiated by them and reflect a fair allocation of risk:

       (a)  Remedies.   Except for certain injunctive relief authorized
            under Section 10 ("Confidentiality"), Licensee's  sole  and
            exclusive  remedies  for BitMover's default hereunder shall
            be (i) to obtain the repair, replacement or  correction  of
            the  defective Software or services to the extent warranted
            under Section 11 ("Warranties and Indemnification") or,  if
            BitMover reasonably determines that such remedy is not eco-
            nomically or technically feasible, (ii) to obtain an  equi-
            table  partial  or full refund of amounts paid with respect
            to the defective Software or services.

       (b)  Liabilities.  BITMOVER SHALL NOT BE LIABLE FOR  ANY  AMOUNT
            EXCEEDING  THE TOTAL PORTION OF THE CONTRACT PRICE ACTUALLY
            PAID BY LICENSEE WITHIN THE THEN CURRENT TERM.  IN NO EVENT
            SHALL  EITHER  PARTY  BE  LIABLE, WHETHER IN CONTRACT, TORT
            (INCLUDING NEGLIGENCE)  OR  OTHERWISE,  FOR  ANY  INDIRECT,
            INCIDENTAL  OR  CONSEQUENTIAL  DAMAGES (INCLUDING LOST SAV-
            INGS, LOST PROFIT OR BUSINESS INTERRUPTION EVEN IF NOTIFIED
            IN  ADVANCE OF SUCH POSSIBILITY) ARISING OUT OF OR PERTAIN-
            ING TO THE SUBJECT MATTER OF THIS AGREEMENT.

       13.  Notices.

       Notices sent to either party shall be effective  when  delivered
       in  person or transmitted by telecopier ("fax") machine, one (1)
       day after being sent by overnight courier, or two (2) days after
       being  sent  by first class mail postage prepaid. A facsimile of
       this Agreement and notices generated  in  good  form  by  a  fax
       machine  (as  well  as  a photocopy thereof) shall be treated as
       "original" documents admissible into  evidence  unless  a  docu-
       ment's authenticity is genuinely placed in question.

       14.  Termination.

       Either  party  may,  in addition to other relief, terminate this
       Agreement if the other party  breaches  any  material  provision
       hereof and fails within ten (10) days after receipt of notice of
       default to correct such default or to commence corrective action
       reasonably  acceptable  to  the aggrieved party and proceed with
       due diligence to completion. Either party shall  be  in  default
       hereof if it becomes insolvent, makes an assignment for the ben-
       efit of its creditors, a receiver is appointed or a petition  in
       Bankruptcy  is  filed  with respect to the party and is not dis-
       missed within thirty (30) days. Termination shall have no effect
       on  the  parties' rights or obligations to safeguard and respect
       Confidential Information under Section  10  ("Confidentiality"),
       Section 11 ("Warranties and Indemnification"), Section 12 ("Lim-
       itation of Remedies & Liabilities") or Section  18  ("Compliance
       with  Export  Regulations").  Immediately or termination of this
       License for any reason, Licensee shall destroy all copies of the
       Software.

       In the event that Licensee institutes patent and/or intellectual
       property litigation against BitMover with respect to  the  Soft-
       ware,  then this Agreement and the rights granted hereunder will
       terminate automatically as of the date such litigation is filed.

       15.  Disputes, Choice of Law.

       Except  for  certain  emergency judicial relief authorized under
       Section 10(e) ("Injunctive Relief") which may be brought at  any
       time,  the  parties  agree  that all disputes between them shall
       first be subject to the procedures in Section 14 ("Termination")
       and  then  shall  be  submitted for informal resolution to their
       respective  chief  operating  officers.  Any  remaining  dispute
       involving  less  than  one  hundred  thousand dollars ($100,000)
       shall be resolved by binding arbitration.  The proceedings shall
       be conducted in accordance with the Commercial Arbitration Rules
       of the American Arbitration Association. The award of the  arbi-
       trator  shall  include  a  written  explanation of the decision,
       shall be limited to remedies otherwise available  in  court  and
       shall  be  binding upon the parties and enforceable in any court
       of competent jurisdiction. Disputes involving amounts  exceeding
       the above dollar limit are not subject to arbitration and may be
       taken directly to court by either party. THIS AGREEMENT SHALL BE
       GOVERNED  BY  AND  CONSTRUED  IN ACCORDANCE WITH THE SUBSTANTIVE
       LAWS OF THE UNITED STATES  AND  CALIFORNIA,  WITHOUT  REGARD  TO
       PRINCIPLES  OF  CONFLICTS OF LAW, AND ANY ACTION SHALL BE INITI-
       ATED AND MAINTAINED IN A FORUM OF COMPETENT JURISDICTION IN SUCH
       DESIGNATED STATE.

       16.  Independent Contractor Status.

       Each party and its employees and agents are independent contrac-
       tors in relation to the other party with respect to all  matters
       arising  under this Agreement. Nothing herein shall be deemed to
       establish a partnership, joint venture, association  or  employ-
       ment  relationship  between the parties. Each party shall remain
       responsible, and shall indemnify and  hold  harmless  the  other
       party, for the withholding and payment of all Federal, state and
       local personal income, wage, earnings, occupation, social  secu-
       rity, worker's compensation, unemployment, sickness and disabil-
       ity insurance taxes, payroll levies or employee benefit require-
       ments  (under  ERISA,  state  law  or otherwise) now existing or
       hereafter enacted  and  attributable  to  themselves  and  their
       respective employees and agents.

       17.  Security, No Conflicts.

       Each  party  agrees  to inform the other of any information made
       available to the other party that is  classified  or  restricted
       data, agrees to comply with the security requirements imposed by
       any state or local government, or by the United  States  Govern-
       ment,  and  shall  return  all  such material upon request. Each
       party represents and warrants that  its  participation  in  this
       Agreement  does not conflict with any contractual or other obli-
       gation of the party or create any conflict of  interest  prohib-
       ited  by  the  U.S. Government or any other government and shall
       promptly notify the other party if any such conflict arises dur-
       ing the Term.

       18.  Compliance with Export Regulations.

       Licensee has or shall obtain in a timely manner all necessary or
       appropriate licenses, permits or other  governmental  authoriza-
       tions  or  approvals; shall indemnify and hold BitMover harmless
       from,  and bear all expense of, complying with  all  foreign  or
       domestic  laws,  regulations  or  requirements pertaining to the
       importation, exportation, or use of the technology to be  devel-
       oped  or  provided  herein. Licensee shall not directly or indi-
       rectly export or re-export (including by transmission) the Soft-
       ware to any country to which such activity is restricted by U.S.
       regulation or statute, without the  prior  written  consent,  if
       required,  of  the  Bureau  of Export Administration of the U.S.
       Department of Commerce. This provision and the  assurances  made
       herein shall survive termination of this Agreement.

       19.  U.S. Government Restricted Rights.

       Software  provided  to the U.S. Government pursuant to solicita-
       tions issued on or after December 1, 1995 is provided  with  the
       commercial  rights  and restrictions described elsewhere herein.
       All Software provided to the U.S. Government pursuant to solici-
       tations  issued  prior  to  December  1,  1995  is provided with
       RESTRICTED RIGHTS as provided for in FAR, 48 CFR 52.227-14 (JUNE
       1987) or FAR, 48 CFR 252.227-7013 (OCT 1988), as applicable.

       20.  Miscellaneous.

       This document and the accompanying attachments specifically ref-
       erenced herein constitute the entire agreement between the  par-
       ties with respect to the subject matter hereof and supersede all
       other communications, whether written or  oral.  This  Agreement
       may be modified or amended only by a writing signed by the party
       against whom enforcement is sought. Except as specifically  per-
       mitted  herein, neither this Agreement nor any rights or obliga-
       tions hereunder may be transferred or assigned by Licensee with-
       out BitMover's prior written consent and any attempt to the con-
       trary shall be void. BitMover reserves all rights  not  specifi-
       cally  granted  herein. Neither party shall be liable for delays
       caused by events beyond its reasonable  control.  Any  provision
       hereof found by a tribunal of competent jurisdiction to be ille-
       gal or unenforceable shall be  automatically  conformed  to  the
       minimum  requirements  of  law  and  all  other provisions shall
       remain in full force and effect. Waiver of any provision  hereof
       in one instance shall not preclude enforcement thereof on future
       occasions. Headings are for reference purposes only and have  no
       substantive effect.

CATEGORY
       Licensing

BitMover, Inc               2002/09/22                          1
$
help://bkd
help://bkd.1
help://bk-bkd
help://bk-bkd.1
help://anonymous
help://deamon
help://daemon
help://demon
help://security
help://secure
help://bkweb
help://bk/web

bk bkd(1)            BitKeeper User's Manual            bk bkd(1)

NAME
       bk bkd - the BitKeeper daemon

SYNOPSIS
       bk bkd [-CdDhiR] [more opts]

DESCRIPTION
       The  BitKeeper  daemon,  bkd,  is  used to synchronize and
       query repositories.  It is usually run  in  one  of  three
       ways:

       a)  automatically  started when accessing a remote reposi-
           tory via rsh, ssh, and/or the file system;
       b)  automatically started via ssh as a login shell;
       c)  manually started as a long running stand-alone daemon.

       The  method  used  depends on how the remote repository is
       named.  See bk help url for details on the naming  syntax.

       The  stand-alone daemon method has no security, other than
       the ability to run in read-only mode and/or the ability to
       limit chdir.  If security is a requirement, use ssh to get
       to the daemon.  See below for information  on  configuring
       the daemon as a login shell.

ANONYMOUS ACCESS
       The  most  common  use  of  the  stand-alone daemon is for
       anonymous access to a repository.  To  provide  read-only,
       anonymous access, you can run:

           bk bkd -d -xpush

       This will allow anyone to read (but not write) all reposi-
       tories at or below the directory  in  which  the  bkd  was
       started.

       If  you  want  to  export a single repository, pick a port
       number, and do this:

           cd /u/linux
           bk bkd -d -p5555 -xcd -xpush

       This says to run in daemon mode, bind to  port  5555,  and
       disallow the "cd" and "push" commands.  By disallowing the
       "cd" command, the daemon at  port  5555  is  tied  to  the
       repository  in the current working directory (bkd needs to
       be run at the root of the repository).  By disallowing the
       "push"  command, the repository is protected from updates.

       Clients can get to this repository by using the BK URLs of

           bk://host.domain:5555
           http://host.domain:5555

       i.e.,

           $ bk clone bk://host.domain:5555 my_tree

       Use  the  http  URLs allows access through most firewalls.
       BitKeeper supports  accessing  repositories  through  http
       proxies, including authenticated proxies.

SECURED ACCESS VIA SSH
       Secure  access  is  provided  via  ssh.  There two ways to
       invoke ssh:
       a)  when  the  repository  is  specified  in  this   form:
           [<user>@]<host>:<pathname>,  ssh will be called to run
           bk bkd on the remote host.  When  the  client  command
           completes,  the  ssh  connection is broken and the bkd
           daemon goes away.
       b)  when  the  repository  is  specified  in  this   form:
           bk://user@host[<pathname>],  ssh  will  be  called  to
           remote login to host and will expect  that  the  login
           shell is the BitKeeper daemon.

   BKD LOGIN SHELL
       On Red Hat Linux, the following steps are necessary to add
       a BitKeeper daemon login  shell:  create  a  simple  shell
       script,    call    it   bkd,   put   it   someplace   like
       /usr/libexec/bitkeeper/bkd,  add  the  full  path  to  the
       script  in  /etc/shells,  and add a user with that path as
       their shell.

       An example bkd shell script which works for us is:

           #!/bin/sh
           exec bk bkd -C -xcd

       Note: using the bkd as a login shell  when  accessing  the
       system  using  rsh  is unsupported for two reasons: rsh is
       insecure and there is a bug which prevents correct  opera-
       tion in this configuration.

BK/WEB
       The bkd is a self contained http server which provides the
       optional BK/Web feature of BitKeeper.  In order  for  this
       feature to work, one of two things must be true:

       a)  The  bkd must be run at the root of a repository which
           contains a commercial license  which  has  the  BK/Web
           option enabled;
       b)  The  bkd  must  be  run on a machine which is directly
           connected to the Internet and the clone and pull  com-
           mands cannot be disabled.

WINDOWS BASED BKD
       At  this  time,  bkd  support on win32 is as a stand-alone
       daemon only and is restricted to one bkd service per host.
       To initially start the bkd service:

           open a cmd shell
           bk bkd -p<port>

       Once  the bkd has been started, the service manager can be
       used to stop and start the bkd service.  On Win2K:

           start->control panel->Administrative Tools->services
           right click on the bkd service
           click stop/start button

       On WinNT:

           start->control panel->services
           click the start/stop button

       To remove the bkd service from the service manager:

           open a cmd shell
           bk bkd -R

       Once launched, upon reboot, the bkd service  is  automati-
       cally re-started.  To disable this feature on Win2K:

           right click on BitKeeper service
           select properties
           change "startup type" to disable

       On WinNT:

           go to start->control panel->services->BitKeeper service->startup
           select disable

OPTIONS
       -C        This option provides a slightly more secure mode
                 of operation in that  the  bkd  will  refuse  to
                 change  directories  up  out of the directory in
                 which it was started.
       -d        Run as a daemon.  Implies -C.
       -D        Debug mode, do not fork and  run  in  the  back-
                 ground.
       -h        Make  bkd  print http headers on all outgoing bk
                 push, bk pull, and bk clone messages.  Use  when
                 bkd is called from a cgi script.
       -l<log>   Log  accesses  in  <log>; if <log> is not speci-
                 fied, then log to stderr.
       -P<pfile> Write the pid of daemon process into  this  file
                 at startup.
       -p<port>  Specify  an  alternative port.  The default port
                 is 0x3962 (aka 14690).  This option implies  -d.
       -g<gid>   Attempt  to  run with group id <gid> (POSIX com-
                 patible systems only).
       -u<uid>   Attempt to run with user id <uid> (POSIX compat-
                 ible systems only).
       -x<cmd>   Exclude  <cmd>  from  the  allowed command list.
                 The list of commands which may be excluded  cur-
                 rently   are:  abort,  cd,  check,  clone,  get,
                 httpget, pull, push, pwd, rclone, rootkey,  sta-
                 tus, synckeys, and version.

WINDOWS ONLY OPTIONS
       -R        Shutdown the bkd service.

EXAMPLES
       We  use  the  following  in /var/bitkeeper/repositories to
       provide anonymous  read  only  access  to  some  BitKeeper
       repositories.

           #---------------------- cut here --------------------------
           /bk -C -u99 -g10
           #---------------------- cut here --------------------------

       The init script shown below can be generated with a

           $ bk getmsg bitkeeper.init

       We  use  the  it in /etc/rc.d/init.d/bitkeeper to start up
       BitKeeper on bitkeeper.com (a Red Hat based Linux system):

           #---------------------- cut here --------------------------
           #!/bin/sh
           #
           # chkconfig: 2345 24 84
           # description: BitKeeper server for work

           # Source networking configuration.
           if [ -f /etc/sysconfig/network ]
           then . /etc/sysconfig/network

                # Check that networking is up.
                [ ${NETWORKING} = "no" ] && exit 0
           fi
           [ -x /usr/bin/bk ] || exit 0
           VAR=/var/bitkeeper

           case "$1" in
               start_msg) echo "Start BitKeeper daemons"
                     ;;
               stop_msg)  echo "Stop BitKeeper daemons"
                     ;;
               restart)   $0 stop
                     $0 start
                     ;;
               start)     cd $VAR || exit 1
                     test -f repositories || {
                          echo Nothing advertised
                          exit 0
                     }
                     while read dir opts
                     do   (
                          cd $dir || exit 1
                          F=`basename $dir`
                          CMD="bk bkd -d $opts -l$VAR/log.$F -P$VAR/pid.$F"
                          eval $CMD 2>> $VAR/errors
                          echo Started $CMD in $dir
                          )
                     done < repositories
                     ;;

               stop)
                     cd $VAR || exit 1
                     echo Shutting down BitKeeper daemons
                     for i in pid.*
                     do   kill `cat $i`
                          rm $i
                     done
                     ;;

               status)    cd $VAR || exit 1
                     for i in pid.*
                     do   echo This pid should be running: `cat $i`
                     done
                     ps -axf | grep bkd

                     ;;

               *)         echo "Usage: bitkeeper {start|stop}"
                     exit 1
                     ;;
           esac

           exit 0
           #---------------------- cut here --------------------------

BUGS
       Needs  ssh  to  provide  access  controlled, authenticated
       users.  One could argue that this  is  code  reuse  rather
       than a bug.

       BitMover  does not ship ssh since it is export controlled.

       On Windows the bkd does not work when started from a  net-
       work drive.

       On  Windows  the  bkd  does  not  work when started from a
       subst'ed drive.

SEE ALSO
       bk help parent
       bk help url
       bk help Howto-bkd

CATEGORY
       Repository
       Admin

BitMover, Inc               2003/06/13                          1
$
help://bkl
help://bkl.1
help://bk-bkl
help://bk-bkl.1

bk bkl(1)            BitKeeper User's Manual            bk bkl(1)

NAME
       bk bkl - display free use BitKeeper license

LICENSE
               BitKeeper License version August-12-2003

       1.  DEFINITIONS

       BKL:  This  license in its entirety, also known as the BitKeeper
             License.

       You: The licensee of the BitKeeper Software.

       BitMover: The licensor of the BitKeeper Software.

       BitKeeper Software: The complete set of executable programs  and
             any  accompanying  files,  such as documentation, known as
             the BitKeeper Software.  The set  of  programs  and  files
             must  include  all  files and programs distributed by Bit-
             Mover as part of the BitKeeper Software.

       BitKeeper Package: A set of files managed by the same  BitKeeper
             ChangeSet  file.   There  may be multiple instances of the
             package; each instance is called a repository.

       Single user BitKeeper Package: A BitKeeper Package  wherein  all
             changes  to  all files are made by the same person and the
             total number of files does not exceed 1000.

       Metadata: Information about the data managed  by  the  BitKeeper
             Software in a BitKeeper Package, such as

             + The ChangeSet file;

             + The  messages  which  annotate modifications of the data
               (also known as check  in  comments,  ChangeLog  entries,
               and/or log messages);

             + All  infrastructure  files contained below the top level
               BitKeeper directory in a BitKeeper Package.   User  data
               files,  i.e.,  files  contained in the BitKeeper/deleted
               directories are explicitly excluded.

       Open Logging: The transmission of Metadata about the  data  man-
             aged by the BitKeeper Software, to a functioning Open Log-
             ging server in the openlogging.org domain (or an  alterna-
             tive   domain  as  posted  on  www.bitkeeper.com/logging).
             Examples of such collected  information  may  be  seen  at
             http://www.openlogging.org.

       2.  LICENSE GRANTS

       Licensees  may  install  and  use the BitKeeper Software for its
       intended purpose.

       3.  LICENSEE OBLIGATIONS

       (a)  Maintaining Open Logging Feature: You hereby  warrant  that
            You will not take any action to disable or otherwise inter-
            fere with the Open Logging feature of the  BitKeeper  Soft-
            ware.   You hereby warrant that You will take any necessary
            actions to ensure that the BitKeeper Software  successfully
            transmits  the Metadata to an Open Logging server within 21
            days of the creation of said Metadata.  By transmitting the
            Metadata  to  an Open Logging server, You hereby grant Bit-
            Mover, or any other operator of  an  Open  Logging  server,
            permission  to republish the Metadata sent by the BitKeeper
            Software to the Open Logging server.

       (b)  Accessing Others' BitKeeper Package: You may only  use  the
            BitKeeper Software to access a BitKeeper Package created by
            BitMover or third parties if You comply with the license of
            the  BitKeeper  Package,  which  can  be  found at the Bit-
            Keeper/etc/REPO LICENSE file within the  BitKeeper  Package
            and/or by running bk repo license.

       (c)  Maintaining  Open Source: It is the intent of BitMover that
            Your use of BitKeeper under this license is for the purpose
            of maintaining Open Source.  By accepting this license, You
            agree that You are prepared  to  demonstrate  Your  confor-
            mance, at the request of BitMover, by making your BitKeeper
            repositories publicly available via the BitKeeper  protocol
            within 15 days from the time of such request.  In the event
            that You do not wish to make  BitKeeper  repositories  pub-
            licly  available,  You have 15 days in which to negotiate a
            waiver, convert said repositories to closed use,  or  cease
            use of said repositories.

       (d)  No  free  use  for  competitors:  Notwithstanding any other
            terms in this License, this License is not available to You
            if  You and/or your employer develop, produce, sell, and/or
            resell a product which contains substantially similar capa-
            bilities  of  the BitKeeper Software, or, in the reasonable
            opinion of BitMover, competes with the BitKeeper  Software.

       (e)  No  combination  with  competing products: Inclusion of the
            BitKeeper Software for use with a  system  having  substan-
            tially  similar  capabilities  of  the  BitKeeper  Software
            requires prior written permission from BitMover.

       (f)  Staying current: This license is terminated  in  the  event
            there  is a new release of the BitKeeper Software which has
            associated regression tests and said regression tests would
            not  be  passed  by this version of the BitKeeper Software.
            This license is terminated in the  event  there  is  a  new
            release  of  the  BitKeeper  Software  which  contains  any
            changes to any part of the licensing  functions,  including
            but not limited to Open Logging.

       (g)  No  reverse  engineering:  You may not yourself and may not
            permit or enable anyone to: (i)  modify  or  translate  the
            Software;  (ii) reverse engineer, decompile, or disassemble
            the Software or otherwise reduce the  Software  to  a  form
            understandable   by  humans,  except  to  the  extent  this
            restriction  is  expressly  prohibited  by  applicable  law
            notwithstanding this limitation; or (iii) provide access to
            the metadata created and managed by BitKeeper to any person
            or  entity which is not licensed to use the BitKeeper Soft-
            ware.

       (h)  Public reference: By  using  the  BitKeeper  Software,  You
            agree to the public use of your name and/or your companies'
            name as a user of the BitKeeper Software.

       4.  NON-CONFORMING USE

       4.1.  Single user packages

       For single user BitKeeper Packages, Open Logging is optional.

       4.2.  Closed Use

       Closed use is the use of the BitKeeper Software without partici-
       pating  in  BKL  licensing  restrictions  such  as Open Logging.
       Closed use of the BitKeeper Software requires that You (or  your
       organization)  purchase closed use licenses for all users of the
       BitKeeper Software within your organization.  This license,  the
       BKL,  does  not  convey authority to make closed use of the Bit-
       Keeper Software.

       4.3.  Logging Waivers

       Certain sites which do not wish to participate in Open  Logging,
       such  as  educational or research institutes, may apply for, and
       may be granted, a written  waiver  from  BitMover,  Inc.   After
       applying  for  a written waiver, such an institution may use the
       BitKeeper Software without Open Logging, for up to 90  days,  or
       until  a  response  is  received  from BitMover, Inc., whichever
       comes first.  Should BitMover not grant your waiver request, You
       have  the option of converting to Open Logging, immediately ter-
       minating your use of the BitKeeper Software or  continuing  your
       use after purchasing closed use license[s].

       4.4.  Damages

       Use  and/or  copying of modified versions of the BitKeeper Soft-
       ware is a violation of copyrights held by BitMover on  the  Bit-
       Keeper  Software.   Use  of  the  BitKeeper  Software  without a
       license is a violation of copyrights held  by  BitMover  on  the
       BitKeeper  Software.  Damages for copyright infringement are the
       greater of actual damages or statutory damages, which  are  cur-
       rently up to $150,000 per infringement.

       This  license is not available to You if You and/or your company
       have any unresolved copyright disputes with BitMover.

       5.  DISCLAIMER OF WARRANTY

       COVERED CODE IS PROVIDED UNDER THIS  LICENSE  ON  AN  ``AS  IS''
       BASIS,  WITHOUT  WARRANTY OR INDEMNIFICATION OF ANY KIND, EITHER
       EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION,  WARRANTIES
       OR  INDEMNITIES CONCERNING INTELLECTUAL PROPERTIES (E.G. PATENTS
       OR COPYRIGHTS), WARRANTIES THAT THE  COVERED  CODE  IS  FREE  OF
       DEFECTS,  MERCHANTABLE,  FIT  FOR  A  PARTICULAR PURPOSE OR NON-
       INFRINGING.  SHOULD ANY  PORTION  OF  BITKEEPER  SOFTWARE  PROVE
       DEFECTIVE  IN  ANY RESPECT, YOU ASSUME THE COST OF ANY RESULTING
       DAMAGES, NECESSARY SERVICING, REPAIR OR  CORRECTION.  THIS  DIS-
       CLAIMER  OF  WARRANTY  CONSTITUTES  AN  ESSENTIAL  PART  OF THIS
       LICENSE. NO USE OF BITKEEPER SOFTWARE  IS  AUTHORIZED  HEREUNDER
       EXCEPT SUBJECT TO THIS DISCLAIMER.

       6.  TERMINATION

       + This  License  and the rights granted hereunder will terminate
         automatically if You fail to comply with terms herein.  Provi-
         sions  which,  by their nature, should remain in effect beyond
         the termination of this License shall survive.

       + If any of the licensing requirements, such  as  Open  Logging,
         are found to be unenforceable, then this license automatically
         terminates unless You continue  to  comply  with  all  of  the
         licensing requirements.

       + Should  You  or  your organization choose to institute patent,
         copyright, and/or  intellectual  property  litigation  against
         BitMover,  Inc.  with  respect to the BitKeeper Software, then
         this License and the rights granted hereunder  will  terminate
         automatically as of the date such litigation is filed.

       + If  this License is terminated for any reason, You must delete
         all copies of the BitKeeper Software and cease using the  Bit-
         Keeper Software.

       7.  LIMITATION OF LIABILITY

       TO THE FULL EXTENT ALLOWED BY APPLICABLE LAW, BITMOVER'S LIABIL-
       ITY TO YOU FOR CLAIMS RELATING  TO  THIS  LICENSE,  WHETHER  FOR
       BREACH  OR  IN  TORT,  SHALL  BE  LIMITED TO ONE HUNDRED PERCENT
       (100%) OF THE AMOUNT HAVING THEN ACTUALLY BEEN PAID  BY  YOU  TO
       BITMOVER  FOR  ALL  COPIES  LICENSED HEREUNDER OF THE PARTICULAR
       ITEMS GIVING RISE TO SUCH CLAIM, IF ANY.

       IN NO EVENT WILL BITMOVER BE LIABLE FOR ANY INDIRECT,  PUNITIVE,
       SPECIAL,  INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH
       OR ARISING OUT OF THIS LICENSE (INCLUDING,  WITHOUT  LIMITATION,
       LOSS  OF  PROFITS, USE, DATA, OR OTHER ECONOMIC ADVANTAGE), HOW-
       EVER IT ARISES AND ON ANY THEORY OF  LIABILITY,  WHETHER  IN  AN
       ACTION  FOR CONTRACT, STRICT LIABILITY OR TORT (INCLUDING NEGLI-
       GENCE) OR OTHERWISE, WHETHER OR NOT SUCH PARTY HAS BEEN  ADVISED
       OF  THE POSSIBILITY OF SUCH DAMAGE AND NOTWITHSTANDING THE FAIL-
       URE OF ESSENTIAL PURPOSE OF ANY REMEDY.

       8.  MISCELLANEOUS

       8.1.  Merger

       This License represents the complete agreement between  You  and
       BitMover  regarding  the  BitKeeper  Software  covered  by  this
       License.  BitMover reserves all rights not specifically  granted
       herein.

       8.2.  Assignment

       BitMover may assign this License, and its rights and obligations
       hereunder, at its sole discretion.

       8.3.  Severability

       If any provision of this License is held  to  be  unenforceable,
       such provision shall be reformed only to the extent necessary to
       make it enforceable.  If any provision of this License  is  held
       to  be unenforceable, the enforceability of the remaining provi-
       sions of this License will not be impaired thereby.

       8.4.  Governing Law/Jurisdiction

       This License shall be governed by the laws of  the  US  and  the
       State of California, as applied to contracts entered into and to
       be performed in California between  California  residents.    By
       using this product, You submit to the jurisdiction of the courts
       in the Northern District of California.

       BKL           Copyright (C) 1999-2002 BitMover, Inc.         BKL

CATEGORY
       Licensing

BitMover, Inc               2003/08/13                          1
$
help://bkscc
help://bkscc.1
help://bk-bkscc
help://bk-bkscc.1

bk bkscc(1)          BitKeeper User's Manual          bk bkscc(1)

NAME
       bk bkscc - BitKeeper and SCC API

DESCRIPTION
       The  bkscc.dll is a dynamic library which allows BitKeeper
       to integrate with any IDE which supports the Microsoft SCC
       API  interface. In this document we will assume the IDE is
       Microsoft Visual C++,  since  this  is  the  IDE  we  have
       tested.  After  bkscc.dll  is installed VC++ will discover
       the library automatically by looking it  up  in  the  reg-
       istry.   VC++  will  automatically  add a "source control"
       entry under the "project"  menu.  Most  of  the  BitKeeper
       functions can be accessed via the new menu entry.

       If  you  are  a  BitKeeper user, you will notice there are
       some conflicts between BitKeeper terminology and VC++ ter-
       minology.   What  the SCC API calls a "project" is not the
       same as a BitKeeper Project.  A typical  SCC  API  Project
       usually  contains  one  binary  for  example,  a ".exe" or
       ".dll" file.  A typical BitKeeper project/package can con-
       tain multiple ".exe" and ".dll" files.

       A  VC++  workspace  is  roughly  equivalent to a BitKeeper
       repository.

       A VC++ workspace file is roughly equivalent to  a  typical
       master (or top-level) Makefile.

       A  VC++ project is equivalent to a sub-directory in a Bit-
       Keeper repository.

       A VC++ project file is roughly equivalent to a mini  Make-
       file sitting in a sub-directory of a BitKeeper repository.

       While it is possible to create a different mapping of VC++
       concepts  to  BitKeeper concepts, the above mapping is the
       cleanest and simplest.  Staying within the above model  is
       strongly recommended.

RECOMMENDED USAGE
       As  a  consequence  of the above model, the workspace file
       must be created first.  It must be placed at the BitKeeper
       root  directory and it must be the first file added to the
       repository. A typical usage scenario is as follows:

       1      Start up the VC++ GUI
       2      Left  click on file->new->workspace
       3      After the workspace file is created, right click on
              the  workspace  file icon and select "add to source
              control".  A BitKeeper setup  screen  to  create  a
              Master  repository  will  pop-up.  Fill in the form
              and left  click  the  "create  repository"  button.
              This  automatically creates a BitKeeper root direc-
              tory as the parent directory of the workspace file.
       4      At  this point the BitKeeper repository is created.
              You can start adding project(s) to  the  workspace,
              (Since  the VC++ workspace directory is the same as
              the BitKeeper root directory, we can use  the  term
              BitKeeper root and workspace interchangeably.)
       5      Left click on file->new->project; IMPORTANT: always
              select "add to current workspace", when  this  menu
              is  used.   This  will create a sub-directory under
              the BitKeeper root where all files associated  with
              the project will go.
       6      Follow  the usual VC++ procedure to create the type
              of VC++ project wanted.( e.g a win32 application)
       7      Right click on the project file and select "add  to
              source control"
       8      Edit/compile/debug  source code until ready to cre-
              ate a ChangeSet.  To create a ChangeSet: left click
              on  project->source control->BitKeeper.   This will
              invoke bk citool.  Add checkin  comments  and  push
              the  "commit"  button to create a BitKeeper Change-
              Set.

NOTES
       Some IDEs do not set the current directory correctly, con-
       sequently BitKeeper is unable to find the repository which
       keeps it from functioning properly.  To remedy this, it is
       necessary  to  set  the current directory to the BitKeeper
       root directory explicitly.  The method to set the  current
       directory depends on the IDE used.

       CodeWright

              1. left  click on Tools-> Version Control-> Mainte-
                 nance-> Current Directory and type in  the  root
                 path of the BitKeeper repository

              2. go  to Tools->Version Control->Setup and do Open
                 Project-> Existing

BUGS
       Closing a workspace file and opening a different one with-
       out  restarting  VC++  will  cause a warning message about
       mixing multiple workspaces together. This is because  VC++
       does  not  inform  the  source  code  control  provider of
       workspace switching event.

AVAILABILITY
       The BitKeeper SCC API is  available  for  commercial  cus-
       tomers only.

SEE ALSO
       bk help citool

CATEGORY
       GUI-tools

BitMover, Inc               2002/09/17                          1
$
help://c2r
help://c2r.1
help://bk-c2r
help://bk-c2r.1

bk c2r(1)            BitKeeper User's Manual            bk c2r(1)

NAME
       bk c2r - convert changeset revision to file revision

SYNOPSIS
       bk c2r -r<rev>  <file>

DESCRIPTION
       This command takes a changeset revision and a filename and
       prints the latest revision in the file that in included in
       that changeset.

SEE ALSO
       bk help r2c

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://cat
help://cat.1
help://bk-cat
help://bk-cat.1

bk cat(1)            BitKeeper User's Manual            bk cat(1)

NAME
       bk cat - concatenate and display file contents

SYNOPSIS
       bk cat [<file> ...]

DESCRIPTION
       bk  cat is used to send one or more files to standard out-
       put.  It is used when a file's contents are wanted but the
       caller  does not know if the file is or is not under revi-
       sion control.

       bk cat differs from the standard Unix cat command  in  two
       ways:  a) it does not support any of the Unix cat options,
       and b) if a file is specified which does not exist, but  a
       corresponding  s.file  does exist, the most recent version
       of s.file is sent to standard output.

       The following shell script emulates the bk cat command:

           for i in "$@"
           do       if [ -f $i ]
                    then    cat $i
                    else    # ignore error messages
                            bk get -kp $i 2>/dev/null
                    fi
            done

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://changes
help://changes.1
help://bk-changes
help://bk-changes.1

bk changes(1)        BitKeeper User's Manual        bk changes(1)

NAME
       bk changes - show changeset history

SYNOPSIS
       bk changes [opts] [-r<revs> | - ]
       bk changes [opts] [-r<revs> | - ] repo
       bk changes -L [opts] [<repo>]
       bk changes -R [opts] [<repo>]

DESCRIPTION
       The  changes  command  is  used  to get an overview of the
       changes made to a repository.  There are options to search
       for  particular  changesets,  view only tagged changesets,
       limit the search to a particular user, etc.

       =>  The first form shown above shows changes in the  local
           repository.
       =>  The second form shown above shows changes in the named
           repository.
       =>  The third form shown above lists changes found in  the
           local repository but not in the remote repository.  If
           the remote repository is not specified, the parent  of
           the local repository is used.
       =>  The fourth form shown above lists changes found in the
           remote repository but not in the local repository.  If
           the  remote repository is not specified, the parent of
           the local repository is used.

       In all but the second form, the changes  command  must  be
       run  from  within a repository, and that repository is the
       local repository while the named repository is the  remote
       repository.   All  the other selection options are applied
       to the list of local or remote only changesets.

       The changesets to be listed may be specified  as  a  revi-
       sion,  a  range  of  revisions,  or a list of revisions on
       stdin.  The default is all  revisions.   Specifying  revi-
       sions is incompatible with the -R/-L options.

OPTIONS
       -/<str>/[i]   List  only  those  changesets whose comments
                     contain the string <str>.   If  there  is  a
                     trailing "i" then ignore case in the search.
       -a            List  all  deltas,  including  tag   deltas.
                     Implies  -e.   An  additional  -e after this
                     option will turn  off  the  listing  of  the
                     empty   merge   deltas  (the  -e  option  is
                     inverted from its previous value  each  time
                     the option is seen).
       -c<dates>     Specifies  the  changesets to be listed as a
                     date range, i.e., -c-6W  lists  the  last  6
                     weeks worth of changes.
       -d<dspec>     Override the default dspec, allows for arbi-
                     trary output formats.
       -e            Show empty merge  changesets.   By  default,
                     these are not shown.
       -f            print  the  changes  in  forward  (oldest to
                     newest) order.  The default is backward.
       -h            Produce html as output.  May not be combined
                     with -d.
       -k            Produce  a  list of matching changeset keys,
                     usually   for   scripts.    Equivalent    to
                     -and:KEY:
       -L            List  only those changesets which are unique
                     to the local repository, i.e.,  those  which
                     would be sent back with a bk push.  Requires
                     either a BK url or a valid  repository  par-
                     ent.
       -m            Do  not  show any merge changesets, empty or
                     not.
       -n            add a newline to each printed record  (some-
                     times useful with -d).
       -r<revs>      Specifies the changesets to be listed, i.e.,
                     1.100..
       -R            List only those changesets which are  unique
                     to  the remote repository, i.e., those which
                     would  be  brought  over  with  a  bk  pull.
                     Requires  either a BK url or a valid reposi-
                     tory parent.
       -t            Only list changesets which are tagged.
       -u<user>      Only list changesets created by <user>.
       -U<user>      Only  list  changesets  created  by  someone
                     other than <user>.
       -v            Shows individual file change history as well
                     as changeset history.

EXAMPLES
       Sample output:

           ChangeSet@1.607, 2000-02-21 14:05:25-08:00, awc@host.com
             update citool to use the "bk unedit" interface.

           ChangeSet@1.606, 2000-02-21 13:35:21-08:00, awc@host.com
             This fix allows BitKeeper to be installed in a non-standard directory.
             The install directory is computed from the $PATH variable and
             the bk symlink.

           ChangeSet@1.605, 2000-02-20 01:32:19-08:00, lm@host.com
             Fix a diagnostic in pull.
             An aborted attempt at key compression.

BUGS
       The -u/-U options should take lists of users.

SEE ALSO
       bk help commit
       bk help pending
       bk help prs
       bk help pull
       bk help push
       bk help revtool
       bk help sccslog
       bk help set

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://check
help://check.1
help://bk-check
help://bk-check.1

bk check(1)          BitKeeper User's Manual          bk check(1)

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 con-
       sistent 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  Change-
       Set  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 multiple deltas in a file all of  which  belong  to
       one cset; the marker records the cset boundary).

       Since  csets  propagate between repositories, it is impor-
       tant that the ChangeSet file is correct.  "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.
       -c   Check file and the per delta  checksums.   Note  that
            only the most recent delta's checksum is checked, see
            bk help 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.  Typically 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   Bit-
               Keeper/etc/config file.  (see bk help admin).
            => a bk file on a win32 operating system that has the
               EOLN_NATIVE flag set has the correct line termina-
               tion character, CRLF
            => a  file on a unix operating system has the correct
               line termination character, LF
            => a file that does not have the EOLN_NATIVE flag  is
               not  set  has the correct line termination charac-
               ter, LF
            Warnings will occur if any of the above do not check
            out cleanly.
       -f   Fix any fixable errors.  This  option  will  renumber
            incorrectly   numbered   revisions,  put  incorrectly
            located files where  they  belong,  reconstruct  cor-
            rupted  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  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 This option is not on by default
            if the auto_fix config option is set.  bk  gone  com-
            mand.
       -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.  Typi-
            cally used as input to the bk gone command.
       -p   List deltas which are in more than one cset.
       -R   Only do checks which make sense in the RESYNC dir.
       -v   Be more verbose.  Each -v adds additional  verbosity.
            With  just  one,  check  will display a progress bar.
            With two, 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 repository  is  OK;
            there is only output if things are broken.
       -w   List files which are writable but not locked.

SEE ALSO
       bk help admin
       bk help gone
       bk help prs
       bk help checksum
       bk help config-etc

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://checksum
help://checksum.1
help://bk-checksum
help://bk-checksum.1

bk checksum(1)       BitKeeper User's Manual       bk checksum(1)

NAME
       bk checksum - check and/or fix BitKeeper checksums

SYNOPSIS
       bk checksum [ -s[<offset>]] [-fv][<file> ... | -]

DESCRIPTION
       BitKeeper  has  more integrity checksums than the original
       SCCS had (SCCS had one over the whole s.file).   BitKeeper
       maintains  a  checksum  which  is compatible with SCCS and
       also a set of new checksums, one per delta.  This  command
       is typically used to check and/or regenerate the per delta
       checksums.  Without any options, the default  behavior  is
       to  just check each checksum warn about any checksums that
       are missing or incorrect.  This command may also  be  used
       to print a list of checksums of arbitrary data, see the -s
       option.

WARNING
       The per delta checksums are part of the delta  keys  which
       are  contained in the ChangeSet file.  These keys are part
       of the metadata which BitKeeper uses to group deltas  into
       changesets.   If  the checksums are changed, the checksums
       in the ChangeSet file must be correspondingly changed, and
       the  process  repeated  for  each  copy of the repository.
       Needless to say, we do not encourage the use of this  com-
       mand  with  the  -f option unless you are sure of what you
       are doing.

OPTIONS
       -f        fix any missing or incorrect checksums.
       -s[<off>] generate  and  print  the  SCCS  style  16   bit
                 unsigned  checksum  starting  at offset off.  If
                 off is 8, then this generates the same  checksum
                 as  the per file checksum.  If there are no file
                 arguments, reads data from stdin (note:  differs
                 from  other  options  which obey the normal Bit-
                 Keeper file expansion rules).
       -v        be verbose.

SEE ALSO
       bk help check

CATEGORY
       Admin

BitMover, Inc               2002/09/17                          1
$
help://chmod
help://chmod.1
help://bk-chmod
help://bk-chmod.1

bk chmod(1)          BitKeeper User's Manual          bk chmod(1)

NAME
       bk chmod - change the mode of a file and save it

SYNOPSIS
       bk chmod <[ugoa]+rwxs> <file> [<file> ...]
       bk chmod <[ugoa]-rwxs> <file> [<file> ...]
       bk chmod <[ugoa]=rwxs> <file> [<file> ...]
       bk chmod <octal> <file> [<file> ...]

DESCRIPTION
       The  chmod command changes the stored file modes for files
       in the repository.  File modes are normally  whatever  the
       file  was  when  it  was  checked  in  to BitKeeper.  When
       changes to the mode need to be made, the bk chmod  command
       is used to record the new permissions.

       The permission syntax is one of

       [ugoa]+rwxs
              A  symbolic  way of adding permissions.  The prefix
              before the "+" indicates the  users  to  which  the
              permissions  apply:  "u" is user, "g" is group, "o"
              is other, "a" is all.  If none  are  specified  the
              default  is  "a".   The postfix after the "+" indi-
              cates the permission to add: "r" is  read,  "w"  is
              write,  "x"  is  execute,  "s"  is setuid or setgid
              depending on the prefix.

       [ugoa]-rwxs
              A symbolic way of removing permissions.  As  above.

       [ugoa]=rwxs
              A  symbolic  way of setting permissions absolutely.
              As above.

       octal  A 4 digit octal number wherein 04000 means  setuid,
              02000 means setgid, and in the following 3 digits 4
              means read permission, 2  means  write  permission,
              and  1  means  execute  permission.  The last three
              digits  are  for  user,  group,  other  permissions
              respectively.   This form sets the permission abso-
              lutely,  it  is  not  relative  to  the  previously
              recorded permission.

NOTE
       Write  permission  is  somewhat  pointless since BitKeeper
       will remove write permission if the file  is  checked  out
       unlocked  and  add write permission if the file is checked
       out with a lock.

SEE ALSO
       bk help admin
       bk help prs

CATEGORY
       File

BitMover, Inc               2003/08/08                          1
$
help://ci
help://ci.1
help://bk-ci
help://bk-ci.1

bk ci(1)             BitKeeper User's Manual             bk ci(1)

NAME
       bk ci - checks in modified files

SYNOPSIS
       bk ci [-lupqf] [-i] [-y<comment>] [<file> ... | -]

DESCRIPTION
       The  ci  command  stores  your new revisions into the Bit-
       Keeper repository. You will be prompted for comments about
       the  changes  to the file, or for convenience, you can use
       the -y option to set comments.  Citool  is  the  preferred
       method for checking in files and committing changes.

OPTIONS
       -f          force creation of a null delta
       -i          check in new file
       -l          follow  check  in with a locked check out like
                   get -e
       -p          print differences before  prompting  for  com-
                   ments
       -q          run silently
       -u          follow  check  in  with  an unlocked check out
                   like get
       -y<comment> sets the revision comment to <comment>

SEE ALSO
       bk help citool
       bk help co
       bk help delta
       bk help edit

CATEGORY
       File
       Common

BitMover, Inc               2002/09/17                          1
$
help://citool
help://citool.1
help://bk-citool
help://bk-citool.1

bk citool(1)         BitKeeper User's Manual         bk citool(1)

NAME
       bk citool - BitKeeper graphical check-in tool

SYNOPSIS
       bk citool [<dir> | <file_list>]

DESCRIPTION
       The citool application is a graphical interface for check-
       ing in new, modified, and pending files.  When called with
       no  arguments,  citool examines the current repository for
       files requiring checkin. Otherwise, citool  will  look  in
       the list of arguments for files or directories.  The argu-
       ments are processed by bk sfiles, and have to  follow  the
       restrictions imposed by bk sfiles.

       Citool  has  three main windows that are positioned verti-
       cally.  The top window contains the list of files that can
       be  checked  in to a changeset.  The middle window is used
       for entering comments about the selected  file  while  the
       bottom  window  displays  different  things  depending  on
       whether viewing a modified file or a file not under  revi-
       sion  control. For modified files, the differences between
       the modified file and its parent are  shown  and  for  new
       files, the file contents are shown.

       Along  the upper right side of the upper two windows are a
       group of buttons. Some of the buttons have different  pur-
       poses  depending  on what the user is doing.  For example,
       the Checkin/Commit button becomes the Commit  button  when
       there  are comments for the ChangeSet file. Otherwise, the
       button is the Checkin  button  which  signifies  that  the
       files  will  be  checked in, but no ChangeSet will be cre-
       ated. The Checkin feature  is  useful  when  checkpointing
       files to save state when you know you want to make changes
       that may break things. Other times you want to  checkpoint
       when you've created distinct new work and want to get back
       to it in the future.

       Typical usage is to move to each file, add  comments,  and
       repeat until done. When all files are commented and a com-
       ment exists for the ChangeSet file, the commit  button  is
       pressed  to make the changes part of a ChangeSet. Citool's
       default behavior is to exit  after  the  commit  finishes.
       However,  the ci.rescan configuration option forces citool
       to rescan the repository for files that still need  to  be
       added  to a changeset. This feature is useful when modify-
       ing files that should be in separate changesets. For exam-
       ple,  if  you  modify  five files and three of those files
       form a logical unit of work, you can start citool, add the
       three  files to a changeset and then commit. After commit-
       ing the files to a changeset, citool returns so  that  you
       can  comment  the  remaining  files  and add them to a new
       changeset. Basically, this option prevents the  user  from
       restarting  citool  multiple  times  if  all files are not
       added to a changeset.

       You can move around within the file list by clicking on  a
       file  name  or  using  the keyboard accelerators Control-n
       (next file) and Control-p (previous file).   You  may  add
       comments, move around, come back, and update the comments.
       The comments are not applied to the files  until  [Commit]
       is clicked.

       The  question  mark  icon  to  the  left  of the file name
       denotes files that are not under revision control. To  add
       the new files to the changeset, click on the question mark
       icon or use the Control-t key to add the file to the  cur-
       rent changeset.  Clicking on the question mark changes the
       icon to a check mark, indicating that  the  file  will  be
       part of the cset.

       Some  of the new files might be files that you do not wish
       to put under revision  control  and  having  them  visible
       clutters  up  the  file  window.  When a new file is high-
       lighted, the Ignore button is activated on the button  bar
       menu.  If  you  click the ignore button, the selected file
       will be added to the  BitKeeper/etc/ignore  file  so  that
       when  citool  is  run again, the selected file will not be
       shown. If you accidentally click ignore on a file that you
       want, click the Unignore button. The BitKeeper /etc/ignore
       file is not updated until the changeset is committed.  The
       ignore  file  is a revision controlled file like any other
       BitKeeper file and can be edited with a text editor if you
       want  to  remove  or  add  files  to the ignore list.  The
       entries that are selected to be ignored are not  added  to
       the ignore file until the changeset is committed.

       At  times,  you might wish to exclude files from a change-
       set. For example, if you are working on a  file  and  have
       made  changes  to  it (changes can be committed and in the
       pending state), but don't want these changes to  propagate
       when  you push your work to another repository. To exclude
       files from the changeset, use the  left  mouse  button  to
       click on the file-type icon.  If the file can be excluded,
       the icon will change to a red X. If you try to  exclude  a
       pending  file while a modified version of the file exists,
       both the pending and the modified file will  be  excluded.
       It is possible to exclude the modified file, while keeping
       the pending file in an included state.

       When you move to a file, the differences for this file are
       shown in the bottom window.  When entering comments, it is
       normal to want to scroll the differences window  (assuming
       that  the  differences are larger than the window).  While
       this can be done using the mouse and  the  scrollbar,  the
       following  keyboard  accelerators  will work at all times,
       even when typing in the comments window:

KEYBOARD BINDINGS
       Home             Scroll to the start of the differences
       End              Scroll to the end of the differences
       PageUp           Scroll the differences up 1 screen
       PageDown         Scroll the differences down 1 screen
       Shift-DownArrow  Scroll the differences down 1 line
       Shift-UpArrow    Scroll the differences up 1 line
       MouseWheel       Scroll the differences 1 screen
       Shift-MouseWheel Scroll the file list window 1 screen

       Control-c        Copy the contents of the comments  window
                        to the cut buffer.
       Control-x        Delete  the contents of the comments win-
                        dow, saving in the cut buffer.
       Control-v        Paste the contents of the cut buffer into
                        the  comments  window  and advance to the
                        next file.
       Middle-Button    On Unix, this will paste the  X11  selec-
                        tion buffer into the comments window.

       Control-n        Go to the next file
       Control-p        Go to the previous file
       Control-l        Rerun  the diffs in case an external pro-
                        gram has changed the file.
       Control-t        Toggle   include/exclude   state   and/or
                        add/don't  add state.  See the text about
                        include/exclude and new files.
       Control-T        Toggle all new files into or out off  the
                        changeset.
       Control-Enter    Do  the  commit.  Same as clicking on the
                        Commit button.
       Control-q        Same as clicking the [Quit] button.

       Control-b        Scroll the differences up 1 screen
       Control-f        Scroll the differences down 1 screen
       Control-u        Scroll the differences up 1/2 screen
       Control-d        Scroll the differences down 1/2 screen
       Control-e        Scroll the differences down 1 line
       Control-y        Scroll the differences up 1 line

EDITING THE COMMENTS
       The comments window is a standard TK text widget with word
       and  line  erase  added.   Moving  around is down with the
       arrow keys, backspace to delete  the  previous  character,
       Control-w (or Alt-w) to erase a word, and Alt-u to erase a
       line.

BUTTONS
       There are a series of buttons on the right.  They  perform
       the following functions:

       [Cut comments]   takes the contents of the current comment
                        window and saves them in a buffer.
       [Paste comments] pastes comments  saved  by  the  previous
                        button,  overwriting  any  existing  com-
                        ments.
       [Commit]         displays all comments in the  differences
                        window and asks if you want to commit.
       [Edit]           a  pull  down menu, giving you the choice
                        of running a simple TK  based  editor  or
                        your $EDITOR on the current file.  Saving
                        the file in the editor will overwrite the
                        current  file.  The pull down also has an
                        option to pop you into bk fmtool  on  the
                        checked  in  version and the current ver-
                        sion of the file.   You may  then  select
                        the  changes  you do not want to keep and
                        "merge" the two versions to  a  new  ver-
                        sion,  which  will  replace  the  current
                        file.
       [History]        starts up revtool on the current file
       [Diff tool]      starts up difftool on  the  previous/cur-
                        rent versions of the file.
       [Discard]        destroys  the changes made to the current
                        file, in other  words,  throws  away  the
                        differences.
       [Ignore]         When  a  new file is selected, the ignore
                        button will add the selected file to  the
                        BitKeeper /etc/ignore file.
       [Unignore]       When a new file is selected and is in the
                        ignore state, the  Unignore  button  pre-
                        vents  the selected file from being added
                        to the BitKeeper /etc/ignore file.
       [Help]           Starts up the  BitKeeper  help  tool  and
                        displays this help.
       [Quit]           Quits.   If  you  have provided comments,
                        this will prompt you to  save  your  com-
                        ments or discard you comments.

LOCKING
       If  the  repository  is locked, and you try to commit, the
       commit will fail.  You can wait for the lock  to  go  away
       and  then try the commit again; it should succeed.  If the
       lock is an invalid one  (left  over  from  an  old  remote
       update),  then you can switch to another window and unlock
       the repository.   After it is unlocked, the commit  should
       work.

SEE ALSO
       bk help ci
       bk help config-gui
       bk help fmtool
       bk help ignore
       bk help sfiles

CATEGORY
       GUI-tools
       Common
       Repository

BitMover, Inc               2002/09/17                          1
$
help://clean
help://clean.1
help://bk-clean
help://bk-clean.1

bk clean(1)          BitKeeper User's Manual          bk clean(1)

NAME
       bk clean - removes unmodified files

SYNOPSIS
       bk clean [-pqv] [<file> ... | -]

DESCRIPTION
       The clean command is used to remove (clean) all unmodified
       files from the current directory,  regardless  of  whether
       they are checked-out in a locked or unlocked state.

       If  there  are  files  which are both locked and modified,
       clean will refuse to delete them  and  will  instead  list
       them as needing a check-in.

OPTIONS
       -p     Prints  diffs for all modified files. The diffs are
              printed in the least readable diff format; you  may
              prefer to use bk sfiles -c | bk diffs -u -
       -q     Run quietly.
       -v     Run verbosely.  List files deleted as well as modi-
              fied files.

SEE ALSO
       bk help unedit
       bk help unlock

CATEGORY
       Common
       File

BitMover, Inc               2002/09/17                          1
$
help://clone
help://clone.1
help://bk-clone
help://bk-clone.1
help://lclone

bk clone(1)          BitKeeper User's Manual          bk clone(1)

NAME
       bk clone - create a new copy of a package

SYNOPSIS
       bk  clone [-ql] [-E<env>=<val>] [-r<rev>] [-z[<d>]] <from>
       [<to>]

DESCRIPTION
       The clone command copies from the  <from>  repository  and
       creates a copy at <to>.  If <to> is not specified then the
       basename of the <from> is the implied  destination.   This
       works  for fully and partially specified pathnames as well
       as BK URLs.  See bk help url for further  naming  informa-
       tion.

       If  <rev> is specified, the cloned repository will include
       only changesets up to and including <rev>.

       The cloned repository remembers from which  repository  it
       was  cloned.   The <from> repository is known as the "par-
       ent", while the newly cloned repository is  known  as  the
       "child".

       Subsequent  updates  to  the  child can be done by running
       bk pull.  Changes made in the child  can  be  pushed  back
       into the parent by running bk push.

       Only  completed changesets are cloned.  Any pending deltas
       are removed from the child before the clone completes.

OPTIONS
       -E<var>=<x> Export an environment variable to remote  Bit-
                   Keeper repository.
       -l          Clone  using  hardlinks instead of copying the
                   data.   This  is   much   faster   and   saves
                   diskspace, but only works within a single Unix
                   filesystem.
       -q          Run quietly.
       -r<rev>     Clone the repository up to and including  cset
                   <rev>.   A  changeset  number or changeset key
                   can be used to specify  <rev>.   See  bk  help
                   terms for more information.
       -z<d>       Do  compression  at  level  <d>,  if possible;
                   default is -z6.  Compression is possible  when
                   using  ssh  or  the  BitKeeper daemon, but not
                   with rsh.

SEE ALSO
       bk help bkd
       bk help parent
       bk help pull
       bk help push
       bk help relink
       bk help terms
       bk help triggers
       bk help url

CATEGORY
       Repository
       Common

BitMover, Inc               2002/09/17                          1
$
help://cmdlog
help://cmdlog.1
help://bk-cmdlog
help://bk-cmdlog.1

bk cmdlog(1)         BitKeeper User's Manual         bk cmdlog(1)

NAME
       bk  cmdlog  -  show  the  log of commands executed in this
       repository

SYNOPSIS
       bk cmdlog [-a]

DESCRIPTION
       List the history  of  repository  level  commands  run  in
       repository  of  current  directory.  Repository level com-
       mands are clone, commit, export, pull, and push.

       Commands are listed in least recent to most recent  order.

OPTIONS
       -a     List history of all commands run in the repository,
              not just repository level commands.

       -c[<cutoff>]
              List commands which happened during the date  range
              specified by <cutoff>.

NOTES
       The  two  command  logs are maintained by BitKeeper in the
       BitKeeper/log  directory.   repo_log  contains  repository
       level  commands run in a repository.  cmd_log contains all
       commands run in a repository.

SEE ALSO
       bk help range

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://co
help://co.1
help://bk-co
help://bk-co.1

bk co(1)             BitKeeper User's Manual             bk co(1)

NAME
       bk co - check out files

SYNOPSIS
       bk co [-klpq] [<file> ... | -]

DESCRIPTION
       Retrieves a read-only copy of the file.

OPTIONS
       -k     do  not  expand  either SCCS or RCS keywords in the
              checked out file.
       -l     Checks out a locked copy of the file  for  editing.
              Like bk get -e.
       -p     print  the file to stdout rather than storing it in
              the g.file.  Useful in pipelines.
       -q     Run silently.

SEE ALSO
       bk help ci
       bk help edit
       bk help get

CATEGORY
       Common
       File

BitMover, Inc               2002/09/17                          1
$
help://comments
help://comments.1
help://bk-comments
help://bk-comments.1
help://comment

bk comments(1)       BitKeeper User's Manual       bk comments(1)

NAME
       bk comments - change checkin comments

SYNOPSIS
       bk   comments   [-p]   [-C<csetrev>]  [-r<rev>]  [-y<cmt>]
       [-Y<file>] [file ...] [-]

DESCRIPTION
       The comments command changes the  stored  comments  for  a
       revision  controlled  file.  The comments may be specified
       on the command line, or if  they  are  not,  you  will  be
       placed in your editor to type in the comments.

       If  given - for a file argument, then comments will read a
       list of files and comments to be  edited  in  batch.   The
       format is like:

           ### Comments for file.c|1.23
           this is a sample comment
           ### Comments for file2.h|1.2.3.4
           these are
           other comments

OPTIONS
       -r<rev>     Change  the  comments  for the specified revi-
                   sion.  The default is the  most  recent  revi-
                   sion.
       -y<comment> Use  <comment>  as  the  new  comment  for all
                   files.
       -Y<file>    Use the contents of <file> as the new  comment
                   for all files.
       -C<rev>     Edit  all  the  file comments on the requested
                   changeset at once.
       -p          Generate the list of all comments in the files
                   requested and write them to stdout.  This file
                   can be edited and then later fed into bk  com-
                   ments - on stdin to change the comments.

       If  no files to edit is given on the command line then -C+
       is assumed and the comments for  the  files  in  the  last
       changeset are edited.

BUGS
       Nota bene: if the deltas being commented have been commit-
       ted to a changeset and have been pulled out of this repos-
       itory,  the comment changes will not propagate on the next
       bk pull.  It is strongly suggested that you use this  only
       on  uncommitted  deltas  which  have  not   been pulled or
       cloned.  In the future, we will add  a  way  of  enforcing
       this.

SEE ALSO
       bk help prs
       bk help sccslog

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://commit
help://commit.1
help://bk-commit
help://bk-commit.1
help://changeset
help://changesets

bk commit(1)         BitKeeper User's Manual         bk commit(1)

NAME
       bk commit - commit deltas to a changeset

SYNOPSIS
       bk commit [-adRq] [-S<tag>] [-y<x>]
       bk commit [-adRq] [-S<tag>] [-Y<file>] [-]

DESCRIPTION
       This command commits work to a changeset, creating a logi-
       cal group of changes which can span multiple files  and/or
       multiple deltas within a single file.

       The  first  form  will search the repository for any files
       which are in "pending" state, i.e., have deltas  which  do
       not yet belong to a changeset, and groups all of them into
       a changeset.   The  second  form,  typically  used  by  bk
       citool, takes the list of files to commit from stdin.

       You  can  see  what  will be added to a changeset when you
       commit by running:

           $ bk pending

       Pending lists only files which  have  checked  in  deltas;
       files  that  are not yet checked in are not shown.  Use bk
       status if you want to see both.

       Using citool is the best way  to  commit.  Not  only  will
       citool  help with checking in files, it will also create a
       changeset if you enter ChangeSet comments.  If you must do
       a command line commit, use:

           $ bk commit

       All  revisions  which you have checked in will become part
       of a changeset.  As part of the commit step, you  will  be
       prompted  for  comments.  The comments should describe the
       changes that you have made.  It's useful to have the  out-
       put of bk pending in another window to see what you did.

       Note:  using  the  default  comments  on  an import is not
       advisable.  The default comments contain information about
       each file and can create very large comment entries in the
       ChangeSet file.  The  ChangeSet  file  is  the  center  of
       activity  in  BitKeeper, and having an unnecessarily large
       one will not help performance.

OPTIONS
       -a        Do not ask the user about logging, fail the com-
                 mit unless OK.
       -d        Don't  run interactively; do the commit with the
                 default comments.
       -R        Tell commit that it  is  processing  the  resync
                 directory.
       -q        Run quietly.
       -S<tag>   Tag  the tree with <tag> at the same time as the
                 commit.
       -Y<file>  Get check-in comment for changeset from  <file>.
       -y<x>     Set check-in comment of changeset to <x>.

SEE ALSO
       bk help changes
       bk help citool
       bk help import
       bk help pending
       bk help tag

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://compatibility
help://compatibility.1
help://bk-compatibility
help://bk-compatibility.1

bk compatibility(1)  BitKeeper User's Manual  bk compatibility(1)

NAME
       bk  compatibility  - Commands compatible between other SCM
       tools and BitKeeper

DESCRIPTION
       BitKeeper tries to make a  transition  from  other  source
       control  management  products  easier by offering commands
       commonly used in other products as  aliases  to  BitKeeper
       commands.

       For example, the following are equivalent in BitKeeper:

           bk deledit
           bk delta -l

SCCS
       add       Add a file to the repository.  Same as bk delta.
       create    Create (initialize) history files.  Same  as  bk
                 new && bk get.
       deledit   Follow a check-in with a locked check-out.  Same
                 as bk delta -l.
       delget    Follow a check-in with  an  unlocked  check-out.
                 Same as bk delta -u.
       enter     Add  a  new  file to the repository.  Same as bk
                 new.
       sccsdiff  Show  differences  in  revision  control  files.
                 Same as bk diffs.
       val       Check s.file structure and time stamps.  Same as
                 bk admin -hhhh

RCS
       ci     Check in a file.  Same as bk delta.
       co     Check out a file.  Same as bk edit.

SEE ALSO
       bk help delta
       bk help diffs
       bk help get
       bk help new
       bk help admin

CATEGORY
       Compat

BitMover, Inc               2002/09/17                          1
$
help://config
help://config.1
help://bk-config
help://bk-config.1

bk config(1)         BitKeeper User's Manual         bk config(1)

NAME
       bk config - show repository configuration information

SYNOPSIS
       bk config

DESCRIPTION
       The config command is used to display configuration infor-
       mation associated with a BitKeeper repository.  It is  not
       typically used by users.

CATEGORY
       Admin

SEE ALSO
       bk help config-etc
       bk help config-gui

BitMover, Inc               2002/09/17                          1
$
help://config-etc
help://config-etc.1
help://bk-config-etc
help://bk-config-etc.1
help://configuration
help://user preferences
help://repository preferences

bk config-etc(1)     BitKeeper User's Manual     bk config-etc(1)

NAME
       bk config-etc - configuring BitKeeper per repository

DESCRIPTION
       BitKeeper  config  files  contain repository configuration
       information  including  project   description,   licensing
       information,  logging information, user preferences, BKWeb
       preferences,  and  contact  information.   Each  BitKeeper
       repository must have the minimum configuration information
       available in order to properly execute BitKeeper commands.

       Repository  configuration information can be stored in two
       files, a repository level config file and a  system  level
       config file:

       BitKeeper/etc/config      Repository   level  config  file
                                 (required)
       /etc/BitKeeper/etc/config System   level    config    file
                                 (optional)

       Repository  level configuration specifications take prece-
       dence over system level specifications by  default,  mean-
       ing,    if   both   BitKeeper/etc/config   and   /etc/Bit-
       Keeper/etc/config files exist, BitKeeper/etc/config values
       are  augmented by /etc/BitKeeper/etc/config values that do
       not exist in BitKeeper/etc/config.    BitKeeper/etc/config
       values  will  not  be  replaced  by  values  in  /etc/Bit-
       Keeper/etc/config.  However, if a '!' is put at the end of
       the   line   in   the   System   config   file  (/etc/Bit-
       Keeper/etc/config) then that  setting  will  override  any
       matching key in local config files.

       Minimum  content requirements for the BitKeeper/etc/config
       file are the key value pairs for

           logging:
           description:
           email:

       (See "CONFIG FILE ENTRIES" section below for allowed  val-
       ues.)

       A  default  config  file  may  be created in order to make
       setup easier consistent for every repository on the system
       by creating a file,

           /etc/BitKeeper/etc/config.template

       that  is readable by all bk users on that system.  If this
       file exists, bk setup will automatically use that  as  the
       BitKeeper/etc/config  file.   See  bk  help setup for more
       information.

CONFIG FILE ENTRIES
   LICENSE KEY
       The use of BitKeeper without Open Logging enabled requires
       a commercial license key.  You can obtain a 30-day license
       for  evaluation  by  emailing  a  request  to   sales@bit-
       mover.com.

       Once  a  license  key  is  obtained,  add  a  line to Bit-
       Keeper/etc/config that looks like:

           license: <license key>

   LOGGING
       If there is an address to which you would like logs to  be
       sent add a line to BitKeeper/etc/config:

           logging:<address>

       To  set  up  Open Logging for the repository add a line to
       BitKeeper/etc/config:

           logging: logging@openlogging.org

   LOGGING CONFIRMATION
       To configure the repository to not ask for confirmation to
       send   logs,   put   the   following   line  in  the  Bit-
       Keeper/etc/config file:

           logging_ask:no

       By doing this you  are  agreeing  to  send  logs  for  all
       instances of this repository.

   DISABLE LOGGING
       To disable logging add a line to BitKeeper/etc/config:

           logging:none

       Please be aware this option is only available to customers
       with commercial licenses and single users.

   SINGLE USERS
       To set the package for a single  user  add  the  following
       lines to the BitKeeper/etc/config file:

           single_user:<user_name>
           single_host:<host_name>

       Please  note,  single  user repositories can be changed to
       multi-user repositories, but they can not be changed  back
       to single_user repositories.  See bk multiuser.

   PROJECT INFORMATION
       The   config  file  can  contain  information  that  helps
       describe the project.  The description field is  required.

           description:
           category:

       The values for these entries can be anything.

   CONTACT INFORMATION
       By filling in the contact information, you are providing a
       contact person for the project in the event that BitKeeper
       discovers a problem that requires local intervention.  The
       email field is the only required field.

           contact:
           email:
           street:
           city:
           state:
           postal:
           country:
           phone:
           cell:
           pager:
           hours:

   USER PREFERENCES
       Repository  preferences  can  be  defined  in   the   Bit-
       Keeper/etc/config file.  The general format for the repos-
       itory preference config file is

           [filter]preference:option

       The optional filter can be any of the following:

       no filter     preference:option
       empty filter  []preference:option
       per user      [jdoe]preference:option
       per host      [@xyz.com]preference:option
       per pathname  [:/path/to/repo]preference:option
       per user@host [jdoe@xyz.com]preference:option
       per repository
                     [:/path/to/repo]preference:option
                     [@xyz.com:/path/to/repo]preference:option
                     [jdoe@xyz.com:/path/to/repo]prefer-
                     ence:option

       Preferences  can  be  listed multiple times with different
       filters.  The filters are examined in order and the  first
       line  that matches the current user, host, and pathname is
       used.  So  in  general  the  most  restrictive  directives
       should appear first.

   KEYWORD EXPANSION
       Keyword  expansion is turned OFF by default.  To have key-
       word expansion flags applied to a file automatically  upon
       checkin,   add   the   keyword   preference  to  the  Bit-
       Keeper/etc/config file.

       Keyword preference options are:

       sccs    expand SCCS keywords (%keyword%).
       expand1 expand keywords in the first  line  that  contains
               keywords only (avoids printf conflicts).
       rcs     expand rcs keywords ($keyword$)

       For example, having

           keyword: sccs, expand1

       in  the  config file will expand SCCS keywords only in the
       first line encountered that contains sccs keywords.

   LINE TERMINATION
       The unix and win32 operating systems use different charac-
       ters to represent line terminations (eoln).  BitKeeper, by
       default, sets the EOLN_NATIVE flag to "on" when  an  sfile
       is created.  EOLN_NATIVE mode means that files checked out
       on Windows will have the Windows eoln  and  files  checked
       out  on  UNIX  will have the UNIX eoln.  To force the UNIX
       eoln mode on all platforms use:

           eoln:unix

       to the BitKeeper/etc/config file.

       There is no way to force the  Windows  eoln  mode  on  all
       platforms.

   CHECKOUT MODE
       Specify checkout mode for a repository.  The default is to
       not show gfiles unless files are checked out.  To override
       the  default,  to  have gfiles checked out in read-only or
       read-write  mode,  a  line  must  be  added  to  the  Bit-
       Keeper/etc/config file as follows:

           [filter]checkout:option

       Where option is one of:

       get    Automatically  do  a bk get <file> after doing a bk
              delta <file>.  (Checkout in read-only mode.)
       edit   Automatically do a bk edit <file> after doing a  bk
              delta <file>.  Note: This will also adjust the mod-
              ification time of  the  s.file  to  be  one  second
              before the modification time of the gfile, which is
              needed in order to prevent make(1) from  attempting
              to reget the file.  (Checkout in edit mode.)
       none   Clear  the  gfile  after  doing  a bk delta <file>.
              (This is the default.)

   COMPRESSION
       By default, when you setup a  repository  the  compression
       algorithm  will be set to gzip in the BitKeeper/etc/config
       file with a line as follows:

           compression:gzip

       This results in the compression  of  stored  s.files.   In
       other words, when you run

           bk new

       what really happens is

           bk new -Zgzip

       To  make  the  repository  use  no compression by default,
       change the compression line  in  the  BitKeeper/etc/config
       file to be:

           compression:none

       See bk help delta for more information about the -Z option
       for compression.

   AUTOFIX
       The bk check command can automatically  fix  a  number  of
       problems  found in a repository.  The default is that this
       variable is on in newly created repositories, and that the
       variable  will  be  passed  through as the -f option to bk
       check.  To enable or disable autofix, one of the following
       should be in BitKeeper/etc/config file:

           autofix:yes
           autofix:no

   BKWEB PREFERENCES
       BKWeb   preferences   can   be   specified   in  the  Bit-
       Keeper/etc/config file.  If these preferences  are  speci-
       fied,  information given will appear on the BKWeb site for
       the project.

       bkweb     specify the BKWeb address for a project
       homepage  the home page for your project or company
       master    the location from which source can be cloned

       For example,

           bkweb:    http://www.bitkeeper.com:8888//home/bk/stable
           master:   bk://www.bitkeeper.com:7000
           homepage: http://www.bitkeeper.com

SEE ALSO
       bk help config-gui
       bk help config
       bk help setup
       bk help admin

CATEGORY
       Overview
       Admin

BitMover, Inc               2002/02/05                          1
$
help://config-gui
help://config-gui.1
help://bk-config-gui
help://bk-config-gui.1
help://GUI
help://gui
help://GUI-config
help://gui-config
help://gui config
help://gui configuration

bk config-gui(1)     BitKeeper User's Manual     bk config-gui(1)

NAME
       bk  config-gui  -  configuration  for  BitKeeper graphical
       tools

DESCRIPTION
       BitKeeper uses a configuration file called config-gui  for
       the  configuration  of the BitKeeper graphical tools.  The
       configuration file is used to modify  colors,  fonts,  and
       widget dimensions.

       The  location of this configuration file can be determined
       for your platform by running the command  bk dotbk.   This
       command  will  return  the pathname of the directory where
       the BitKeeper graphical tools will look for the config-gui
       file.

       The config file must be a valid tcl program as it is eval-
       uated by the BitKeeper GUI tools (which  are  also  tcl/tk
       programs).   The point of being a program is that tcl code
       may be added to the config file in order to customize  the
       gui based on arbitrary values such as machine name, screen
       size, etc.  For example, if all screens of a certain  size
       were known to be LCD screens (typically laptops), then the
       following technique could  be  used  to  get  colors  more
       appropriate for those screens:

           if {[winfo screenwidth .] <= 1024} {
                # These show up better on LCD displays.
                set gc(oldColor) lightseagreen
                set gc(newColor) gray
                set gc(fm3.handColor) yellow
           }

       The  point  of the config-gui file is to change configura-
       tion options.  A typical line looks like this:

           set gc(oldColor) #f0f0f0

       and the meanings for each part of that line are:

           set           tcl syntax for assigning variables
           gc(oldColor)  configuration option
           #f0f0f0       hexadecimal color value

       Each variable in the config  file  may  take  one  of  two
       forms,  tool specific or global.  Tool specific variables,
       which apply only to the named tool, have the tool name  as
       a prefix, i.e.,

           set gc(cset.fixedFont)  {fixed 12 roman}
           set gc(buttonColor)     blue

       whereas  global variables, which apply to all tools unless
       there is a tool specific version  defined  as  well,  look
       like

           set gc(fixedBoldFont) {fixed 12 roman bold}

       As  an example, if you want pink buttons in citool, yellow
       buttons in helptool, and blue in all of the  rest  of  the
       tools, add the following to your config file:

           set gc(buttonColor) blue
           set gc(ci.buttonColor) pink
           set gc(help.buttonColor) yellow

       The  tool names used to get to tool specific variables (or
       to have a change only apply to  that  tool)  are  the  GUI
       tool's name with the trailing "tool" dropped, i.e., "diff"
       for "difftool."

TCL INFORMATION
       The following tcl/tk commands may be  useful  for  display
       specific customization:

       [winfo depth .]
              returns  the  color  depth  of  the screen in bits,
              i.e., 16 means the screen can  do  65536  different
              colors.

       [winfo screen .]
              Returns the name of the screen in the form display-
              Name.screenIndex, i.e., "disks.bitmover.com:0.0".

       [winfo screenheight .]
              returns the height of the screen in pixels.

       [winfo screenwidth .]
              returns the width of the screen in pixels.

GUI CONFIGURATION
   GLOBAL CONFIGURATION
       The following is a list of variables used by  the  various
       gui tools.  Each of these needs to be in a statement like:

           set gc(<variable>) <value>

       but in the list below we just show the <variable> part.

       fixedFont         Font used in all  of  the  text  widgets
                         such  as  file  lists,  entry boxes, and
                         text widgets showing contents of  files.
                         Default: {fixed 12 roman}
       fixedBoldFont     Bold font used to highlight text such as
                         difference  within  lines  in  difftool.
                         Default: {fixed 12 roman bold}
       buttonFont        Font  used  in buttons.  Default: {times
                         12 roman bold}
       scrollWidth       Width of the scrollbar widget in pixels.
                         Default: 12  in  everything except help-
                         tool where the default is 14.
       buttonColor       Color of button when  in  an  unselected
                         state. Default: #d0d0d0
       listBG            Color for the help topic widget and list
                         backgrounds Default: #e8e8e8
       newColor          Color of the  newer  revision  or  diff.
                         Default: #a8d8e0
       oldColor          Color  of  the  older  revision or diff.
                         Default: #b48cff
       noticeColor       Color   for   warnings   and   messages.
                         Default: #b0b0e0
       searchColor       Highlight color for search matches. Used
                         in difftool and revtool.   Default: yel-
                         low
       selectColor       Color  of the current file in citool and
                         csettool. Color of the current topic  in
                         helptool. Default: yellow
       statusColor       Status  windows  in  csettool, difftool,
                         and renametool.  Default: lightblue
       warnColor         Color of the  error  messages.  Used  in
                         citool,     difftool    and    csettool.
                         Default: yellow
       textBG            Background color for text windows.  Used
                         in all of the tools.  Default: white
       textFG            Text  color.   Used in all of the tools,
                         Default: black
       scrollColor       Color of the scrollbar  slider  and  end
                         arrows.  Default: #d9d9d9
       troughColor       Color    of   the   scrollbar   troughs.
                         Default: lightblue
       BG                Background color for miscellaneous  wid-
                         gets not listed above. Default: #f0f0f0
       diffHeight        Height  of a difference window in number
                         of  lines.  Used  in  citool,  csettool,
                         difftool,    fmtool,   and   renametool.
                         Default: 30   in    everything    except
                         difftool where it is 50 lines.
       diffWidth         Width  of  a difference window in number
                         of  characters.    Used   in   csettool,
                         difftool,  and  fmtool,  and renametool.
                         Default: 65
       geometry          Default size/location. Follows the stan-
                         dard  X11 notation.  See X(1).  Geometry
                         is WIDTHxHEIGHT+XOFF+YOFF.
                         +XOFF  The left edge  is  to  be  placed
                                XOFF pixels from the left edge of
                                the screen
                         -XOFF  The right edge is  to  be  placed
                                XOFF  pixels  from the right edge
                                of the screen
                         +YOFF  The top edge of the window is  to
                                be  placed  YOFF  pixels from the
                                top of the screen
                         -YOFF  The bottom edge of the window  is
                                to be placed YOFF pixels from the
                                bottom of the screen
                         For example, a value of "+0+0" indicates
                         that  the  tool  should be placed at the
                         upper left of the screen.  Default: none
       mergeHeight       Height   of  a  merge  window.  Used  in
                         fmtool.  Default 20
       mergeWidth        Width of a merge window. Used in fmtool.
                         Default 80
       quit              Key  used  to  exit  from the gui tools.
                         Default: <Control-q>

   CITOOL CONFIGURATION
       ci.commentsHeight height of the comments window.
       ci.diffHeight     height of the diffs  window  (the  lower
                         window).
       ci.display_bytes  Number  of bytes to show in new files in
                         citool. If set to 0, the entire file  is
                         displayed. Default: 8192
       ci.editHeight     Height of the popup editor.  Default: 30
       ci.editWidth      Width of the popup editor.  Default: 80
       ci.excludeColor   Color of the exclude icon (X character).
                         Default: red
       ci.filesHeight    number of files in the top window.
       ci.rescan         Set  this  to  option  to 1 if you would
                         like citool to run again after doing the
                         commit.  Rescanning  is useful if you do
                         development in the manner where you mod-
                         ify  many files that logically belong to
                         separate changesets.  This  option  then
                         allows  you to stay in citool and create
                         different changesets for the files with-
                         out   restarting   citool   each   time.
                         Default: 0

   CSETTOOL CONFIGURATION
       cset.annotation   Annotation options to apply when getting
                         files  to  be diffed.  See the -a option
                         to bk get.  Example:  "-aum".   Default:
                         "" (do not display annotations)
       cset.listHeight   Number  of  lines  in  the list windows.
                         Default: 12

   DIFFTOOL CONFIGURATION
       diff.diffHeight   Number of lines  in  the  diff  windows.
                         Default: 50
       diff.searchColor  Highlight   color  for  search  matches.
                         Default: lightblue

   FM3TOOL CONFIGURATION
       charColor         Color used to highlight  portions  of  a
                         line which has changed.  Default: orange
       comments          Boolean which controls  the  display  of
                         the   comments   window   at   the  top.
                         Default: 1 (on).
       firstDiff         Keyboard accelerator for  going  to  the
                         first change.  Default: "-".
       handColor         Color  used  to  highlight hand selected
                         merge choices in the side by side  local
                         and       remote      diff      windows.
                         Default: lightyellow.
       lastDiff          Keyboard accelerator for  going  to  the
                         last change.  Default: "+".
       mergeColor        Color  used  to highlight merge choices,
                         both manual and automatic, in the  lower
                         merge window.  Default: lightblue.
       nextConflict      Keyboard  accelerator  for  going to the
                         next    conflict    (skips    automerged
                         changes).  Default: "}".
       nextDiff          Keyboard  accelerator  for  going to the
                         next change.  Default: "]".
       prevConflict      Keyboard accelerator for  going  to  the
                         previous   conflict   (skips  automerged
                         changes).  Default: "{".
       prevDiff          Keyboard accelerator for  going  to  the
                         previous change.  Default: "[".
       sameColor         Color used to highlight the portion of a
                         conflict consisting of unchanged  lines.
                         Default: #1cc7d0.
       spaceColor        Color  used  to highlight the beginnings
                         of lines which are "spacers" inserted to
                         make  the  changes line up horizontally.
                         Default: black.
       undo              Keyboard  accelerator  for  undoing  the
                         last merge selection.  Default: "u".

   HELPTOOL CONFIGURATION
       help.linkColor    Color  of  the  hyperlinks  in helptool.
                         Default: blue
       help.topicsColor  Highlight   color   for   topic   search
                         matches.  Default: orange
       help.height       Number  of  rows to display in helptool.
                         Default: 50
       help.width        Number of columns to  display  in  help-
                         tool. Default: 72
       help.exact        Only  return  full  word/phrase matches.
                         Default: 0, set to 1 to enable.

   RENAMETOOL CONFIGURATION
       rename.listHeight Height  of  the  file  list  widget   in
                         renametool (in lines). Default: 8

   REVTOOL CONFIGURATION
       rev.canvasBG      Color    of    the   graph   background.
                         Default: #9fb6b8
       rev.commentBG     Background color of the  comment  window
                         in      the      annotated      listing.
                         Default: lightblue
       rev.arrowColor    Color of the arrows connecting the revi-
                         sion boxes.  Default: darkblue
       rev.mergeOutline  Color  of  the box surrounding the merge
                         revisions.  Default: darkblue
       rev.revOutline    Color of the box surrounding the regular
                         revisions.  Default: darkblue
       rev.revColor      Fill   color  of  the  unselected  node.
                         Default: #9fb6b8
       rev.tagColor      Fill    color    of    tagged     nodes.
                         Default: #9fb6b8
       rev.selectColor   Highlight  color  for the selected anno-
                         tated line. Default: #adb8f6
       rev.commentHeight Height of the comment window  above  the
                         annotated file listing. Default: 5
       rev.textWidth     Width  of  widget that displays the file
                         content. Default: 92
       rev.sccscat       Arguments  to   the   sccscat   command.
                         Default: -aum
       rev.textHeight    Height  of widget that displays the file
                         content. Default: 50
       rev.showHistory   The time period of  revisions  that  are
                         shown.  The  value  needs  to be a valid
                         entry for the prs -R option. Default: 1M
       rev.dateColor     Color  of the date text at the bottom of
                         graph.  Default: #181818

SEE ALSO
       Any Tcl/Tk documentation
       X(1)
       bk help citool
       bk help config
       bk help csettool
       bk help difftool
       bk help helptool
       bk help revtool
       bk help fmtool
       bk help renametool

CATEGORY
       Overview
       Admin
       GUI-tools

BitMover, Inc               2003/06/13                          1
$
help://cp
help://cp.1
help://bk-cp
help://bk-cp.1
help://copy

bk cp(1)             BitKeeper User's Manual             bk cp(1)

NAME
       bk  cp  -  create a copy of a file preserving its revision
       history

SYNOPSIS
       bk cp <oldfile> <newfile>

DESCRIPTION
       Use bk cp to copy an existing file and its  revision  his-
       tory to a new file.  The new file will have a changed root
       identifier so that it is a different inode.  The new  file
       will  be  distinct  from  the old file moving forward, but
       will have the revision history  from  the  old  file  pre-
       served.

SEE ALSO
       bk help mv
       man cp

CATEGORY
       File

BitMover, Inc               2002/01/09                          1
$
help://crypto
help://crypto.1
help://bk-crypto
help://bk-crypto.1

bk crypto(1)         BitKeeper User's Manual         bk crypto(1)

NAME
       bk crypto - Cryptography services

SYNOPSIS
       bk crypto -i <bits> <secret-key> <public-key>
       bk crypto -s <secret-key> < <data> > <signature>
       bk crypto -v <public-key> <signature> < <data>

DESCRIPTION
       The  bk  crypto  command  allow access to the cryptography
       subsystem of BitKeeper for use in scripts to sign and val-
       idate  data.   This  code  uses  a  straight RSA signature
       scheme.

OPTIONS
       -i        Create a new RSA key pair.  This option  creates
                 a new random RSA keypair and saves the output in
                 two filenames given on the  command  line.  This
                 command  needs  to generate a lot of random data
                 from your system so it can take a long  time  to
                 complete.
       -s        Create  a RSA signature for data read from stdin
                 using a private key.  Given a  RSA  private  key
                 created  with the 'bk crypto -i' command, the -s
                 option will read arbitrary data from  stdin  and
                 then  write a signature to standard out that can
                 be verified with the 'bk crypto -v' command.
       -v        Validate a RSA signature  using  a  public  key.
                 This command will read arbitrary data from stdin
                 and a RSA public key from the command  line  and
                 will validate that the signature matchs the data
                 and can only have be  created  by  the  matching
                 private key.

EXIT STATUS
       0 if no problems and if RSA signature validates correctly.

SEE ALSO
       bk help base64

CATEGORY
       Utility

BitMover, Inc               2002/09/20                          1
$
help://cset
help://cset.1
help://bk-cset
help://bk-cset.1

bk cset(1)           BitKeeper User's Manual           bk cset(1)

NAME
       bk cset - creates and manipulates changesets

SYNOPSIS
       bk cset [-Cpq] [-i<list>] [-l ] [-M<range>] [-r<rev>]

DESCRIPTION
       The  cset  command  is  a low level command used mostly to
       generate BitKeeper patches.

OPTIONS
       -C        Clear and remark all ChangeSet boundaries.
       -i<list>  Create a new cset on TOT that includes the csets
                 in <list>.
       -l        Read  changeset revisions or keys from stdin and
                 print the list of deltas in each of the  change-
                 sets.
       -M<range> Mark the files included in the <range> of csets.
       -p        Print the list of  deltas  being  added  to  the
                 cset.
       -q        Run quietly.
       -r<rev>   Print  the list of deltas in ChangeSet revision,
                 <rev>.
       -x<list>  Create a new cset on TOT that excludes the csets
                 in <list>.

BUGS
       This command does too much and needs to be split apart.

CATEGORY
       Repository

BitMover, Inc               2003/06/02                          1
$
help://csetprune
help://csetprune.1
help://bk-csetprune
help://bk-csetprune.1

bk csetprune(1)      BitKeeper User's Manual      bk csetprune(1)

NAME
       bk csetprune - shrink a repository by removing files

SYNOPSIS
       bk csetprune [-S] [ -k<16hexDigits>] < keylist

DESCRIPTION
       The  csetprune command is used to prune certain files from
       the repository.  These files are removed in a way which is
       permanent, i.e., the prune cannot be undone.

       The  command  operates  on  a list of file keys (sometimes
       called BitKeeper inodes).  Each file associated with a key
       is  removed from the repository and from all changesets in
       the ChangeSet file.  If a changeset  becomes  empty  as  a
       result  of the key removal, then that changeset is removed
       from the ChangeSet file history.  If a  removed  changeset
       had  a  tag,  the  tag is moved to the closest non-removed
       ancestor in the ChangeSet  file.   If  that  ancestor  was
       already  tagged  with  the  same tag, the duplicate tag is
       discarded.

       After all files have been removed,  the  identity  of  the
       ChangeSet  file  is  changed  (using  bk  newroot) and the
       remaining files are ``reparented'' to  the  new  ChangeSet
       file.

OPTIONS
       -S        Keep  the  symbol  structure  intact.   This  is
                 needed when doing a csetprunes over time on same
                 key  set and wanting the resulting repository to
                 communicate with a repository created by an ear-
                 lier csetprune.  Without this option, the inter-
                 nal symbol graph structure is streamlined.
       -k<16hexDigits>
                 Specify the <16hexDigits> used in  a  repository
                 root  key.   This  is  needed when doing a cset-
                 prunes over time on same key set and wanting the
                 resulting   repository  to  communicate  with  a
                 repository created by an earlier csetprune.

       GENERATING KEYS

       The prs command may be used to generate the list of  keys.
       When  generating  keys,  it  is  important to realize that
       looking in a particular subdirectory  is  likely  to  miss
       some  of the files that you may want to remove.  The files
       may have been moved to another directory or they may  have
       been  removed  (which  is  really  just a move to the Bit-
       Keeper/deleted subdirectory).

       The following command will generate a list of keys for all
       files  originally  created  in  the ``junk'' subdirectory,
       including all deleted and/or moved files:

           bk -r prs -hr+ -nd:ROOTKEY: | grep '|junk/'

EXAMPLE
       Suppose there is a repository which has two major  subsec-
       tions,  called  ``docs''  and  ``src''  respectively.  The
       repository has grown to be too large and the  goal  is  to
       split it in two.  The process for doing so would be to

       (1) Make sure all users have pushed their changes into the
           main repository.  Changes made after  the  split  will
           have  to exported as a traditional patch and imported,
           which loses the checkin comments.

       (2) Clone the repository twice, once for each of  ``docs''
           and ``src''.

       (3) In each new repository, strip out the files which will
           be in the other repository.

       Commands which will do this:

           bk clone master src
           bk clone master docs
           # Remove the docs files from the src repository
           cd src
           bk -r prs -hr+ -nd:ROOTKEY: | grep '|docs/' | bk csetprune
           # Remove the src files from the docs repository
           cd ../docs
           bk -r prs -hr+ -nd:ROOTKEY: | grep '|src/' | bk csetprune

SEE ALSO
       bk help newroot
       bk help prs
       bk help sfiles

CATEGORY
       Admin

BitMover, Inc               2003/02/26                          1
$
help://csets
help://csets.1
help://bk-csets
help://bk-csets.1

bk csets(1)          BitKeeper User's Manual          bk csets(1)

NAME
       bk csets - run csettool on last set of imported changes

SYNOPSIS
       bk csets

DESCRIPTION
       The  csets command will run the bk csettool command on the
       last set of changesets imported into this repository  with
       a  bk pull,  or bk push.  This is useful for tracking down
       problems and/or doing a quick review.

SEE ALSO
       bk help csettool
       bk help pull
       bk help push

CATEGORY
       Repository

BitMover, Inc               2003/06/04                          1
$
help://csettool
help://csettool.1
help://bk-csettool
help://bk-csettool.1

bk csettool(1)       BitKeeper User's Manual       bk csettool(1)

NAME
       bk csettool - BitKeeper graphical changeset browser

SYNOPSIS
       bk csettool [-r<revs>] [-f<file@rev>] [-]

DESCRIPTION
       csettool  is  used  to view detailed information about the
       specified changeset[s].  csettool  displays  the  list  of
       changes  in each changeset, the ChangeSet history, and the
       differences found in each file contained in  each  change-
       set.

       Csettool  is  a  very useful aide when tracking down bugs.
       For example, when using revtool to  view  comments  for  a
       specific  file in order to track when a change was made to
       the file. Once the desired file is  found,  the  user  can
       then  click  on  the "View ChangeSet" button in revtool to
       bring up csettool to see what other files were modified at
       the same time that the file of interest was modified.

       To  see  the  changes  for a particular file, click on the
       file name in the top left window and you will see:

       => the number of diffs in the middle status window
       => the old version of the file in the lower-left window
       => the new version of the file in the lower-right window
       => the ChangeSet's comments followed by the  delta's  com-
          ments in the upper-right window

       Use  the  space bar to move between diffs and files.  Each
       time you hit the space bar, the next diff is brought  into
       view.   If you are on the last diff, the tool moves to the
       next file. The Next (>>) buttons and Previous (<<) buttons
       in  the  top  menu  bar  will also allow you to browse the
       files and diffs.

       The History button in the menu bar can be  used  to  start
       the  graphical  history  browser,  revtool,  on either the
       entire project (ChangeSet file) or on the file highlighted
       in the upper-left window.

OPTIONS
       All  options  are  mutually  exclusive, i.e., pick one (or
       none) of the following.

       -r<revs>
              ChangeSet revision to  examine.  Can  be  a  single
              revision  or  a range of revisions. If no -r option
              is given, csettool defaults to -r+, i.e.  the  most
              recent changeset.

       -f<file@rev>
              Given  a  filename and revision, csettool starts up
              with the specified file and revision selected.

       -      expects a list of revisions on stdin.

BINDINGS
       Home            Scroll both files to the top
       End             Scroll both files to the bottom
       PageUp          Scroll both files one screen up (also Con-
                       trol-b)
       PageDown        Scroll  both  files  one screen down (also
                       Control-f)
       UpArrow         Scroll both files one line up  (also  Con-
                       trol-y)
       DownArrow       Scroll both files one line down (also Con-
                       trol-e)
       LeftArrow       Scroll both files to the left
       RightArrow      Scroll both files to the right

       Alt-UpArrow     Make the diffs windows one line bigger and
                       the lists windows one line smaller.
       Alt-DownArrow   Make  the  diffs  windows one line smaller
                       and the lists windows one line bigger.

       Control-q       Quit
       space           Next diff, if last diff in this file, then
                       goto next file
       n               Next diff, if last diff in this file, then
                       goto next file
       p               Previous diff, if first diff in this file,
                       then goto previous file
       .               Center the current diff on the screen
       Control-n       Next file
       Control-p       Previous file
       Double-Clicking Double clicking the left mouse button on a
                       file in the file list  brings  up  revtool
                       for the specified file.
       MouseWheel      Move  wheel  towards you to view next diff
                       and away from you to view previous diff

FUTURE DIRECTIONS
       We plan on having a single screen diff window option where
       the changes are all shown color coded in one window.

SEE ALSO
       bk help cset
       bk help difftool
       bk help revtool
       bk help ranges
       bk help config-gui

CATEGORY
       GUI-tools
       Repository

BitMover, Inc               2002/10/02                          1
$
help://delta
help://delta.1
help://bk-delta
help://bk-delta.1

bk delta(1)          BitKeeper User's Manual          bk delta(1)

NAME
       bk delta - check in modified files

SYNOPSIS
       bk delta [-acChilpquY] [-y[<msg>]] [more] [<file> ... | -]

DESCRIPTION
       The bk delta command is used to check in changes  made  to
       revision controlled files.  This command is fairly rich in
       features and is the  preferred  interface  for  scripting.
       For humans, easier interfaces are bk ci and bk citool.

OPTIONS
        -a          Normally,  delta  wants a -i to add a file to
                    the revision control system.  If this  option
                    is set, then the following do the same thing:

                        bk delta -a newfile
                        bk delta -i newfile
                        bk new newfile

                    The usefulness of this option is more  appar-
                    ent  when you consider having a mixed list of
                    files, some under revision control  and  some
                    not.

                    When  called  with this option, bk delta will
                    not create a null delta  on  an  edited,  but
                    unmodified file.

        -C          Take checkin comments from SCCS/c.<filename>.
                    It is an error if the c.file does not  exist.
        -D<file>    Take diffs from <file>.
        -E<enc>     Set file encoding (like admin).
        -h          Invert sense of file's hash flag.
        -I<file>    Use init <file> for meta data.
        -i          Initial  check-in, create a new revision his-
                    tory.
        -l          Follow check in with a locked check out  like
                    bk get -e.
        -M<mode>    Set  the  permissions  on  the  new  delta to
                    <mode>.
        -p          Print differences before prompting  for  com-
                    ments.
        -q          Run silently.
        -u          Follow  check  in  with an unlocked check out
                    like bk get.
        -Y[<file>]  Prompt for one comment, then use it  for  all
                    the  files.  If <file> is specified then take
                    the comments from that file.
        -y<comment> Sets the revision comment to <comment>.
        -Z, -Z<alg> Compress stored s.file with <alg>, which  may
                    be:
                    gzip - like gzip(1)
                    none -  no compression

BUGS
       The format of the init file is not documented.

SEE ALSO
       bk help ci
       bk help citool
       bk help co
       bk help edit
       bk help get

CATEGORY
       File

BitMover, Inc               2003/06/04                          1
$
help://diffs
help://diffs.1
help://bk-diffs
help://bk-diffs.1
help://differences
help://sdiffs

bk diffs(1)          BitKeeper User's Manual          bk diffs(1)

NAME
       bk diffs - show differences in revision controlled files

SYNOPSIS
       bk  diffs  [-bBcDfhMnpsuUvw]  [-d<date>] [-l<rev>] [-r<r>]
       [-R<r>] [<file> ... | -]

DESCRIPTION
       To view changes you have made to all of  the  files  in  a
       directory since checking the files out, type:

           $ bk diffs | more

       To see the changes for all files in your tree, do the fol-
       lowing:

           $ bk -r diffs | more

       The bk diffs command supports context,  unified,  procedu-
       ral,  and  side-by-side  diffs.   All  of the above can be
       optionally annotated with author,  date,  and/or  revision
       numbers.

       You can also diff specific revisions. For example:

           $ bk diffs -r1.2..1.4 foo.c

       When  only  one  revision  is  supplied with -r, then that
       revision is compared to the working file  or  the  top  of
       trunk if the file is not edited.

       You can use this to diff your entire tree, including edits
       against an existing changeset  revision  or  tag  in  your
       repository.   The  following are equivalent, the two forms
       are shown because it is sometimes useful to diff a subset,
       which  may  be  accomplished by filtering the output of bk
       rset.

           $ bk rset -l<rev> | bk -R diffs -u -
           $ bk -r diffs -r@<rev> -u

OPTIONS
       -b        Ignore changes in amount of white space.
       -B        Ignore  changes  that  just   insert  or  delete
                 blank lines.
       -c        Do context diffs.
       -C<rev>   diff   the   repository  against  the  specified
                 changeset version <rev>.  Useful if you want  to
                 capture  the checked changes as well the work in
                 progress (modified files).
       -D        Prefix lines with dates.
       -d<date>  Diff using date or symbol.
       -f        Prefix lines with file names.
       -h        Don't print headers.
       -l<rev>   Show all changes made by the changeset  contain-
                 ing rev <rev>.
       -M        Prefix lines with revision numbers.
       -n        Do RCS style diffs.
       -p        Procedural diffs, like diff -p.
       -r<rev>   Diff revision <rev>.  (Or key or changeset revi-
                 sion. See bk help terms under 'rev argument')
       -R<rev>   Show diffs between parent of <rev> and <rev>.
       -s        Display side-by-side diffs.
       -U        Prefix lines with user names.
       -u        Do unified diffs.
       -v        Be verbose about non-matching ranges.
       -w        Ignore white space when comparing lines.

SEE ALSO
       diff(1)
       bk help difftool
       bk help export
       bk help treediff

CATEGORY
       File
       Common

BitMover, Inc               2003/07/10                          1
$
help://difftool
help://difftool.1
help://bk-difftool
help://bk-difftool.1

bk difftool(1)       BitKeeper User's Manual       bk difftool(1)

NAME
       bk difftool - BitKeeper Graphical Diff Tool

SYNOPSIS
       bk difftool
       bk difftool -
       bk difftool <file1>
       bk difftool -r<rev>  <file1>
       bk difftool -r<rev1>  -r<rev2>  <file1>
       bk difftool <file1> <file2>
       bk difftool </path/file1> <../someother/path/>

DESCRIPTION
       The  difftool command is a side-by-side differences viewer
       that shows the files being compared in  separate  windows.
       The  differences are color coded, but as you move to a new
       diff, that diff becomes highlighted in a bold  font.   You
       can  move  back and forth through the diffs using the keys
       described below.

ARGUMENTS
       If no arguments are given, difftool finds all the modified
       files  in  the  current  directory  and subdirectories and
       allows the user to select the files they are interested in
       via  a  pull-down menu. Also, keyboard accelerators can be
       used to navigate between the files.

       If a dash (-) is given as an argument,  difftool  takes  a
       list of files to view from stdin. For example,

           bk sfiles -gc | bk difftool -

       If  only  one  file is specified and that file is a locked
       and modified file, difftool  will  diff  the  most  recent
       revision against the locked version.

       If  a  revision  and  a  checked  out  file are specified,
       difftool diffs that version against the checked out  file.

       If  two revisions and a file are specified, difftool diffs
       those two versions of the file.

       If two files  are  specified,  difftool  diffs  those  two
       files.

       If  a  file  (or  a path with a filename) are given as the
       first argument and a directory  is  given  as  the  second
       argument,  then  the  basename  of  the  first argument is
       appended to the second argument. The purpose of this call-
       ing  convention  is to save typing. For example, if I have
       multiple-related repositories at the  same  level  in  the
       filesystem  and I want to diff a file in the local reposi-
       tory against the same  file  in  another  version  of  the
       repository, I can do the following:

           bk difftool src/filename.c ../../repo/src

       The above command is equivalent to doing the following:

           bk difftool src/filename.c ../../repo/src/filename.c

KEY BINDINGS
       Home        Scroll both files to the top
       End         Scroll both files to the bottom
       PageUp      Scroll both files one screen up
       PageDown    Scroll both files one screen down
       UpArrow     Scroll both files one line up
       DownArrow   Scroll both files one line down
       Left        Scroll both files to the left
       Right       Scroll both files to the right

       Control-q   Quit
       space       Next diff
       n           Next diff
       p           Previous diff
       .           Center the current diff on the screen
       Control-n   Go to then next file
       Control-p   Go to the previous file

SEE ALSO
       bk help diffs
       bk help fmtool
       bk help config-gui

CATEGORY
       GUI-tools
       Common
       File

BitMover, Inc               2002/09/17                          1
$
help://edit
help://edit.1
help://bk-edit
help://bk-edit.1

bk edit(1)           BitKeeper User's Manual           bk edit(1)

NAME
       bk edit - check out a file for editing (writable)

SYNOPSIS
       bk edit [-q] [<file> ... | -]

DESCRIPTION
       Use  edit  when modifying existing files.  Edit checks the
       file out of the SCCS directory in a  read-write  mode  and
       locks the file for modifications.

       Edit  with no options will check out all files in a direc-
       tory.

OPTIONS
       -q     run quietly

NOTE
       edit is actually an alias for bk get -e

SEE ALSO
       bk help co
       bk help get
       bk help new

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://editor
help://editor.1
help://bk-editor
help://bk-editor.1

bk editor(1)         BitKeeper User's Manual         bk editor(1)

NAME
       bk  editor  - automatically check out BitKeeper files when
       using $EDITOR

SYNOPSIS
       bk editor <file>

DESCRIPTION
       bk editor is used as a shortcut to edit a file whether  or
       not it is a BitKeeper file.  If the file is under revision
       control, bk editor will bk edit the  file  then  exec  the
       editor  of  choice on that file.  If the file is not under
       revision control, it will exec the editor on that file.

       The EDITOR environment variable must be set appropriately.

       bk editor can be used as follows:

           bk editor foo.c

       A  preferred method is to set the EDITOR environment vari-
       able and alias the editor  name  to  'bk  editor'.   Using
       xemacs as an example, set EDITOR and then alias:

           EDITOR=xemacs
           alias xemacs='bk editor'

       To open the file for editing:

           xemacs foo.c

CATEGORY
       Compatibility

BitMover, Inc               2002/09/17                          1
$
help://emacs
help://emacs.1
help://bk-emacs
help://bk-emacs.1
help://Compat/vc

bk emacs(1)          BitKeeper User's Manual          bk emacs(1)

NAME
       bk emacs - info on how to use emacs' vc-mode

DESCRIPTION
       BitKeeper  is  similar  to  SCCS, and vc-mode more or less
       supports SCCS, so most of the things that you can do  with
       vc-mode  work:  visit-file  will check out files automati-
       cally, C-x C-q locks files  for  editing,  C-x  v  v  will
       prompt for comments and check in an individual file, C-x v
       = will compare versions, and so on.   Filename  completion
       doesn't  know  about  sfiles; this appears to be a general
       problem with vc-mode, not a BitKeeper specific issue.

       You cannot create changesets with vc-mode; use  bk  citool
       or  bk  commit.   vc-mode  does not understand BitKeeper's
       symbol handling and lines of development, neither of which
       were  in  the  original  SCCS.  Do not attempt to use vc's
       symbol, snapshot, and branch commands with BitKeeper.

       vc-mode expects to be  able  to  refer  to  SCCS  commands
       directly  instead  of via the bk front end.  In theory, it
       should suffice to put

           setq vc-path /usr/libexec/bitkeeper

       in .emacs, but this didn't work when last tested (most  of
       the  BK  developers use vi).  The commands vc wants to run
       are: bk admin, bk get, bk delta, bk unget,  bk rmdel,  and
       bk prs.  This just happens to be the list of commands that
       we symlink into /usr/bin during a standard installation.

       If you check in a file using bk citool or bk  delta  in  a
       shell window, vc-mode will not notice; you can go right on
       editing the buffer, and BitKeeper will get  very  confused
       the  next  time  you  try to check out the file (locked or
       not).  The right way to get out of this mess  is  to  kill
       off  the offending buffer, rename the modified file out of
       the way, check out the file for  editing,  and  rename  it
       back.  Do all the rearrangement from a shell prompt.  Kill
       all your buffers before running bk  citool  to  avoid  the
       problem.

CATEGORY
       Compat

BitMover, Inc               2002/09/17                          1
$
help://export
help://export.1
help://bk-export
help://bk-export.1

bk export(1)         BitKeeper User's Manual         bk export(1)

NAME
       bk export - checks out clear-text version of all BitKeeper
       files

SYNOPSIS
       bk export -tpatch [-hT] [-d u|c] -r<rev1,rev2>
       bk   export   [-tplain]   [-kTvw]   [-i<pat>]    [-x<pat>]
       -r<rev> [<source>] <dest>

DESCRIPTION
       The  export  command  generates a directory tree alongside
       the BitKeeper repository which contains checked-out copies
       of  all  the  files  under BitKeeper control.  It can also
       generate traditional (diff -urN) patches between  any  two
       revisions  of the source tree.  By default, bk export only
       exports user files.  Files under the  BitKeeper  directory
       are  not  exported.  This behavior can be changed with the
       -i and -x options.

       If you are trying the export a patch for a  sub-directory,
       and  some  of  the files in that directory have been moved
       out of the directory. You want to make  sure  the  out-of-
       view file looks like deleted file. This is done by replac-
       ing the |rev part of the out-of-view file  to  |1.0.   You
       can do this using the following command:

           bk rset -hrA,B | your_script | bk gnupatch

OPTIONS
       -d<u|c>   Set  patch's  diff  style  to unified or context
                 diff.  If no style specified, do regular  diffs.
       -h        Disable patch header.
       -i<pat>   Export only pathnames matching <pat> pattern.
       -k        Do  not  expand  keywords  (default is to expand
                 keywords).
       -r<rev>   Export the tree as of revision <rev>.
       -T        Set gfile modification time to check-in time.
       -t<type>  Select export format via <type>:
           plain  export file in plain text to a directory  tree.
           patch  export file in gnu patch format.
       -v        Be verbose.
       -w        Make files writable (default is read-only).
       -x<pat>   Export all pathnames not matching <pat> pattern.

       Note that -i and -x take a  file  glob  like  used  by  bk
       ignore  which is matched against the partial pathname from
       the root.

SEE ALSO
       diff(1)
       bk help gnupatch
       bk help rset

CATEGORY
       Compat

BitMover, Inc               2002/09/17                          1
$
help://extras
help://extras.1
help://bk-extras
help://bk-extras.1

bk extras(1)         BitKeeper User's Manual         bk extras(1)

NAME
       bk extras - list extra files not under revision control

SYNOPSIS
       bk extras [<dir>] [-a]

DESCRIPTION
       The  extras  command finds files which are not under revi-
       sion control and are not listed in the ignore file (see bk
       help ignore).

       The  default  behavior  is  to find all extra files in the
       entire tree, this can be changed by specifying a subdirec-
       tory like so

               bk extras .

       The  default  behavior is to respect the ignore file, this
       can be changed by adding the -a flag  (which  must  follow
       the optional directory argument) like so

               bk extras -a    # find all extra files
               bk extras . -a

BUGS
       The -a position is lame.

SEE ALSO
       bk help ignore
       bk help sfiles

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://files
help://files.1
help://bk-files
help://bk-files.1

bk files(1)          BitKeeper User's Manual          bk files(1)

NAME
       bk files - summary of BitKeeper file types

DESCRIPTION
       For  each  file under revision control, there are a number
       of files associated with the  main  file.   The  following
       list describes the purpose of each file:

       foo.c         gfile  (aka  "gotten"  file),  this  is your
                     source file

       SCCS/s.foo.c  s.file - the revision history  of  all  ver-
                     sions of the gfile

       SCCS/p.foo.c  p.file -  the  lock  file,  created when the
                     file is edited.  The pfile contains the fol-
                     lowing columns:

                        parent     new
                        revision   revision  user    date/time
                        1.5        1.6       lm      01/01/2000 12:43:54

                     This  file  is an exclusive lock whose exis-
                     tence indicates  that  the  gfile  has  been
                     checked  out  for editing.  Unlike ATT SCCS,
                     BitKeeper allows only one locker at a  time.

       SCCS/z.foo.c  z.file - a lock file created when locking or
                     checking in a new version. This is an exclu-
                     sive  lock used when updating or locking the
                     s.file.

       SCCS/x.foo.c  x.file - a temporary file which contains the
                     new  version  of  the s.file under construc-
                     tion.  When the check-in  is  finished,  the
                     s.file  is  removed  and the x.file is moved
                     into its place.

       SCCS/c.foo.c  c.file - a temporary copy of check  in  com-
                     ments, currently used only by bk citool.

       SCCS/d.foo.c  d.file -  a  temporary  file  that indicates
                     there is at least one pending delta  in  the
                     s.file.

CATEGORY
       Overview
       File

BitMover, Inc               2002/09/17                          1
$
help://findkey
help://findkey.1
help://bk-findkey
help://bk-findkey.1

bk findkey(1)        BitKeeper User's Manual        bk findkey(1)

NAME
       bk findkey - look for keys in files

SYNOPSIS
       bk findkey [opts | key] [<file> ... | -]

DESCRIPTION
       bk  findkey  may  be  used to look for keys in one or more
       files.  In BitKeeper, keys  are  the  internal  names  for
       files and for file deltas.

       Either entire keys or one or more portions of a key may be
       specified.  Each delta in each file that matches all spec-
       ified parts is listed.

OPTIONS
       -b<random>  specify the random bits part of a key.
       -c<chksum>  specify the checksum part of a key.
       -e<email>   specify the user@host.domain part of a key.
       -h<h.dom>   specify the host.domain part of a key.
       -p<path>    specify the path part of a key.
       -t<utc>     specify  the  timestamp  part  of a key.  Date
                   formats accepted are either YYYYMMDDHHMMSS  or
                   YYYY/MM/DD HH:MM:SS.
       -u<user>    specify the username part of a key.

SEE ALSO
       bk help prs

CATEGORY
       File

BitMover, Inc               2002/11/19                          1
$
help://fix
help://fix.1
help://bk-fix
help://bk-fix.1

bk fix(1)            BitKeeper User's Manual            bk fix(1)

NAME
       bk fix - re-edit a checked in (but uncommitted) delta

SYNOPSIS
       bk fix [-v] <file.c>
       bk fix -c [-v]

DESCRIPTION
       The  fix  command allows you to revise changes made to the
       most recent delta in a file.  Typically, this  feature  is
       used immediately after a check in when it is realized that
       that delta was not done or was incorrect.

       In general, only deltas which have not yet been  committed
       to  a  changeset  may be modified.  The reason for this is
       that changesets are immutable -  once  they  are  created,
       they may not be modified.

       In  some  cases,  it is useful to be able to "uncommit" an
       entire changeset.  If, and only if, you are positive  that
       there  are  no  other  copies  of  this changeset in other
       repositories, then use bk fix -c which will fix all deltas
       in the most recent changeset.  It is not an error if there
       are other copies of the changeset, it just means you  will
       have to merge the two versions of the same change.

       The checkin comments are preserved if the subsequent check
       is made bi bk citool.

OPTIONS
       -c     fix an entire changeset.
       -v     be verbose.

BUGS
       Symbolic tags are not preserved.

SEE ALSO
       bk help ci
       bk help edit
       bk help stripdel

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://flags
help://flags.1
help://bk-flags
help://bk-flags.1

bk flags(1)          BitKeeper User's Manual          bk flags(1)

NAME
       bk  flags  -  show  a listing of files and their BitKeeper
       flags

SYNOPSIS
       bk flags [<file> ... | -]

DESCRIPTION
       Displays a listing of files and their BitKeeper  flags  in
       the following format:

           foo.c  BITKEEPER,CSETMARKED,EXPAND1,SCCS

SEE ALSO
       bk help admin
       bk help prs

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://fmtool
help://fmtool.1
help://bk-fmtool
help://bk-fmtool.1
help://GUI-tools/fm

bk fmtool(1)         BitKeeper User's Manual         bk fmtool(1)

NAME
       bk fmtool - BitKeeper side-by-side merge tool

SYNOPSIS
       bk fmtool
       bk fmtool <local_file> <remote_file> <merged_file>

DESCRIPTION
       fmtool  is  a  side-by-side  merge tool used for resolving
       differences between two different versions of a file.

       If fmtool is started without arguments, use the Open  but-
       ton to select the files that you wish to merge.

       When  fmtool is started, there are three main windows, the
       ``local'' window on the left, the ``remote'' window on the
       right, and the ``merge'' window on the bottom.  When doing
       a bk pull, your repository is  considered  local  and  the
       other  one is considered remote, and BitKeeper arranges to
       have the local version of the file on the  left  side  and
       the remote version on the right.

       Merging is done as follows:

       1.     fmtool  starts  scanning  both  files  from the top
              until difference are found. The identical work (i.e
              the  work up to the point where the differences are
              found) is put in the merge window.
       2.     The user selects whether the remote or  local  ver-
              sion  of  the  change  will be used by clicking the
              "Use Left" or "Use Right" buttons.  When  the  user
              picks  a  version,  the  changes  are placed in the
              merge window.
       3.     Repeat the process until all changes are placed  in
              the merge file.

       The  changes in the merge window are colored so that it is
       easy to tell whether the work was from the local or remote
       file.

       Each  merge  may  be  undone either by clicking the "Undo"
       button or using the keys listed below.  The undo works all
       the way to the start of the file.

       If you need to make adjustments to the merge, you can edit
       the work in the merge window.  The merge window is a  sim-
       ple editor - move the mouse pointer where you want to make
       the changes and start typing.

BINDINGS
       Control-LeftArrow   Use the diff in the left window.
       Control-RightArrow  Use the diff in the right window.
       Control-DownArrow   Skip the current diff, using  neither.
       Control-UpArrow     Undo the last choice.
       Control-q           Exit from fmtool.
       Alt-UpArrow         Grow  the  merge window and shrink the
                           diff windows.
       Alt-DownArrow       Grow the diff windows and  shrink  the
                           merge window.

       The following keys operate on the set of windows that have
       the focus.  Click in the diff windows or the merge  window
       to set the focus.

       PageDown  Scroll  the  diffs  or  the  merge window up one
                 screen.
       PageUp    Scroll the diffs or  the  merge  window  up  one
                 screen.
       DownArrow Scroll  the  diffs  or  the  merge window up one
                 line.
       UpArrow   Scroll the diffs or  the  merge  window  up  one
                 line.

SEE ALSO
       bk help config-gui
       bk help merge
       bk help merge-binaries
       bk help merging

CATEGORY
       GUI-tools
       File

BitMover, Inc               2003/06/04                          1
$
help://gca
help://gca.1
help://bk-gca
help://bk-gca.1

bk gca(1)            BitKeeper User's Manual            bk gca(1)

NAME
       bk gca - show the greatest common ancestor

SYNOPSIS
       bk gca [-t] -r<rev1>  -r<rev2>  <file>

DESCRIPTION
       This command will print the revision which is the greatest
       common ancestor of the specified two revisions.  If  there
       is  no  node  in  the  graph  which is an exact match, the
       printed revision will  have  an  include  list  and/or  an
       exclude list of revisions which must be added to the revi-
       sion in order to get the actual gca.

OPTIONS
       -r<rev>  specify  the  first  and  second  rev  (both  are
                required).

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://get
help://get.1
help://bk-get
help://bk-get.1

bk get(1)            BitKeeper User's Manual            bk get(1)

NAME
       bk get - check out BitKeeper files

SYNOPSIS
       bk     get    [-aCdDeFkmnNpqu]    [-G<name>]    [-i<list>]
       [-r<rev>|-c<date>] [-x<list>] [<file> ... | -]

DESCRIPTION
       get is used to check out files for viewing or building. By
       default, files are checked out unlocked and in a read-only
       mode.  The get command is used primarily within  automated
       scripts  and  is not the preferred method for checking out
       files for editing.  To check out files for editing, see bk
       edit.

       You  do  not need to check out every file in order to com-
       pile your program since most versions of the Make  program
       will check files out as they are needed. In order for this
       to work, the get command needs to be in your path and  the
       dependencies  need to be correct in the Makefile.  If that
       is true, a simple "make" will check  out  and  build  your
       product.

OPTIONS
       -a        Align  prefix  output  in a human readable form.
                 Used with one of the following options  [mNnud].
       -c<date>  Get the latest revision before <date>.
       -C        implicitly  specifies  a  revision  which is the
                 most recent revision committed to a changeset.
       -d        Prefix each line with the date of last modifica-
                 tion.
       -D        Output a diff.
       -DD       Output cset diffs.
       -DDD      Output hash diffs.
       -e        Get  file  for  editing. A lock is placed on the
                 s.file.
       -F        Do not verify the file checksum.
       -g        Suppress the retrieval of any text.
       -G<name>  Place the checked out file in <name> instead  of
                 the default gfile location.
       -h        Invert sense of file's hash flag.
       -H        Put file in its historic location.
       -i<list>  Include revs in <list>.
       -k        Don't expand RCS or SCCS keywords. -k is implied
                 by -e.
       -m        Prefix each line with the revision of last modi-
                 fication.
       -M<rev>   Merge with <rev>.
       -n        Prefix each line with the filename.
       -N        Prefix each line with its line number.
       -p        Write   file   to  standard  output  (useful  in
                 scripts).  Required with -r <rev> where <rev> is
                 anything other than the most recent delta.
       -P        Write to stdout, force get; useful for corrupted
                 files.
       -q        Run quietly.
       -R        Rev is part of pathname, i.e.,  src/get.c|1.102.
       -r<rev>   Get  this  revision.  (Or key or changeset revi-
                 sion. See bk help terms under 'rev argument')
       -S        If a gfile exists, don't check it out again.
       -T        Set the gfile's modification time to the delta's
                 creation time.
       -u        Prefix each line with the user who last modified
                 it.
       -x<list>  Exclude revs in <list>.

SEE ALSO
       bk help co
       bk help edit

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://gethost
help://gethost.1
help://bk-gethost
help://bk-gethost.1

bk gethost(1)        BitKeeper User's Manual        bk gethost(1)

NAME
       bk gethost - display machine name

SYNOPSIS
       bk gethost [-r]

DESCRIPTION
       Outputs the fully-qualified name of the machine. Used pri-
       marily when doing bk scripting.

       -r     print the real host name, ignoring $BK_HOST.

SEE ALSO
       bk help getuser

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://getuser
help://getuser.1
help://bk-getuser
help://bk-getuser.1

bk getuser(1)        BitKeeper User's Manual        bk getuser(1)

NAME
       bk getuser - display user name

SYNOPSIS
       bk getuser [-r]

DESCRIPTION
       This  command  displays  BitKeeper's  idea of the caller's
       user name.  With the -r option, ignores $BK_USER.

SEE ALSO
       bk help gethost

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://gnupatch
help://gnupatch.1
help://bk-gnupatch
help://bk-gnupatch.1

bk gnupatch(1)       BitKeeper User's Manual       bk gnupatch(1)

NAME
       bk gnupatch - generate traditional patches

SYNOPSIS
       bk gnupatch [-ehT] [-d u|c|n]

DESCRIPTION
       bk  gnupatch  is  used as part of the process of exporting
       traditional patches from a BitKeeper  repository.   It  is
       not  typically  used directly.  The bk export command does
       the following when exporting patches

              bk rset -hr<rev>| bk gnupatch

       The   expected   input   format    is    <current>|<start-
       ing>|<rev>|<ending>|<rev>,     where     <current>,<start-
       ing>,<end>  are the location of the file now, where it was
       at  the start, and where it was at the end of the range of
       diffs.

OPTIONS
       -e        expand keyword before  generating  patch.   Key-
                 words are not expanded normally.
       -h        do  not  prefix  the  patch  with  the BitKeeper
                 header describing the patch.
       -T        Use the time of checkin for the file time stamps
                 (recommended).
       -d u|c|n  Select the style of diff(1) output, -du for uni-
                 fied diffs, -dc for context diffs, -dn for  RCS-
                 format diffs.  The default is -du if this option
                 is not used.

SEE ALSO
       bk help export
       bk help rset
       diff(1)

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://gone
help://gone.1
help://bk-gone
help://bk-gone.1

bk gone(1)           BitKeeper User's Manual           bk gone(1)

NAME
       bk gone - mark a file (key) as gone

SYNOPSIS
       bk gone [-q] [<key key ...> | -]

DESCRIPTION
       The  gone  command  is  used  when a file has been lost or
       physically deleted and the administrator of the repository
       has decided that the file should be marked as gone.

       The key of the file can be generated from an existing file
       like this:

           $ bk prs -hr+ -d:ROOTKEY: file

       The key that is returned from the above command  needs  to
       be  marked  as  gone if the file is to be removed from the
       repository.

       Sometimes a file is lost (i.e. the  gotten  file  and  the
       s.file  have  been  removed by accident). Whenever reposi-
       tory-level commands are run, consistency checks  are  per-
       formed.  When  these  checks  run, they will notice that a
       file is lost and will complain.  After  looking  over  the
       consistency  check  output carefully, you can run the fol-
       lowing command to automatically mark all the missing files
       as gone:

           bk -r check -ag | bk -R gone -

OPTIONS
       -q     be quiet.

NOTE
       Just  adding  the  key  to the gone file does not make the
       file "go away".  All it does is make BitKeeper be happy if
       the  file  is actually gone.  If you want to really remove
       the file, save the key, physically remove  the  file,  and
       run  bk -r check -a.  If that complains, run the gone com-
       mand on the listed keys.

SEE ALSO
       bk help check

CATEGORY
       Admin

BitMover, Inc               2002/09/17                          1
$
help://grep
help://grep.1
help://bk-grep
help://bk-grep.1

bk grep(1)           BitKeeper User's Manual           bk grep(1)

NAME
       bk grep - search some/all revisions for a pattern

SYNOPSIS
       bk  grep [-adeimnNu] [-c<dates>] | [-r<rev>] | [-R[<rev>]]
       <pattern> [<file> ... | -]

DESCRIPTION
       If you need to find a string which you think may  be  pre-
       sent in some version of some file, you can use the bk grep
       command to do that.

       By default, bk grep searches only the most recent  version
       of  each  file.   The listing can be annotated with dates,
       revision numbers, file names, and/or user names.

       If no annotations are selected, the default is to do "-mn"
       (revision numbers and file names).

       If a revision is specified with -r, then bk get is used to
       annotate just that version of the file.

       If a range of revisions are specified with -R, or a  range
       of dates are specified with -c, then bk sccscat is used to
       get the changes made by that range  of  revisions.   Note:
       just the additions made by the selected versions are anno-
       tated in this case.

       The output found is passed through the native grep(1) com-
       mand.

OPTIONS
       -a        Suppress all annotations.
       -c<dates> Specify the versions as a range of dates.
       -d        Prefix each line with the date it was last modi-
                 fied.
       -e        Use egrep instead of grep.
       -i        Ignore the case of letters in making comparisons
                 (passed through to grep(1)).
       -m        Prefix  each line with the rev it was last modi-
                 fied in.
       -n        Prefix each line with the filename.
       -N        Prefix each line with the line number.
       -r<rev>   Only look in revision <rev> for the pattern.
       -R[<rev>] Only look in range of revisions  <rev>  for  the
                 pattern.    If  <rev>  is  not  specified,  that
                 implies all versions of the file[s].   The  dif-
                 ference  between  this  option  and the previous
                 option is that in this case bk grep looks in the
                 lines  added  by  the specified revision, but in
                 the -r case, the entire contents of  the  speci-
                 fied version is searched.
       -u        Prefix each line with the user who last modified
                 it.

EXAMPLES
       To see if <pattern> occurs anywhere in any version of  any
       file of your tree:

           $ bk -r grep -R pattern

       To see if it occurs anywhere in the most recent version of
       of any file of your tree:

           $ bk -r grep pattern

       To see if it was added by the most recent delta made in of
       any file of your tree:

           $ bk -r grep -R+ pattern

BUGS
       The  ways  of specifying which versions to search are non-
       obvious.  You need to read  the  examples  carefully.   We
       made the default be the most useful/common one.

       There  really  ought to be a way to grep changes made by a
       changeset or range of changesets.

       When looking through annotated files, the if  the  annota-
       tion  contains  the  string but the line data does not, it
       still matches.  In other words, if you look for "foo"  and
       you  have  a  file  named "foobar", all lines in that file
       will be printed.

SEE ALSO
       grep(1)
       bk help range
       bk help sccscat

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://help
help://help.1
help://bk-help
help://bk-help.1

bk help(1)           BitKeeper User's Manual           bk help(1)

NAME
       bk help - get help for BitKeeper commands

SYNOPSIS
       bk help [-akp] [-f <filename>] <specific-topic>
       bk help topics

DESCRIPTION
       The bk help command displays the online help for the spec-
       ified command or topic.  Output gets displayed in the cur-
       rent  command  shell window.  See bk helptool for informa-
       tion about the graphical interface for help.

       A quick reference guide can be printed on Unix systems  as
       follows:

           lpr `bk bin`/bk_refcard.ps

       or  on  Windows/NT, click on the ``Quick Reference'' title
       in the start menu, and assuming Acrobat is installed,  the
       card  will be displayed.  To print on Windows/NT, click on
       the ``file->print'' menu entry of the Acrobat reader.

       To get a list of all bk help topics use

           bk help topics

OPTIONS
       -a       Just search the  docs  for  the  string  <topic>.
                This matches substrings and prints the topic fol-
                lowed by the matching line.
       -f<file> Use <file> as the helptext file.
       -k       Similar to -a, but only matches whole words.
       -p       disable the use of any pager just send the output
                to stdout.

FUTURE DIRECTIONS
       We will be adding a bk man command to format the man pages
       on the fly.

TODO
       The help system is actually useful for other docs  besides
       BitKeeper.   At BitMover we have the Tcl/Tk docs reformat-
       ted into a helpdoc and some day we  need  to  explain  how
       other people can do this.

SEE ALSO
       bk help helptool

CATEGORY
       Common

BitMover, Inc               2002/09/17                          1
$
help://helptool
help://helptool.1
help://bk-helptool
help://bk-helptool.1

bk helptool(1)       BitKeeper User's Manual       bk helptool(1)

NAME
       bk  helptool  -  graphical front-end to the BitKeeper help
       system

SYNOPSIS
       bk helptool [<topic>]

DESCRIPTION
       The helptool command  is  a  graphical  interface  to  the
       online help system.

       There  are  two text windows displayed, a window of topics
       on the left and the help text on  the  right.   There  are
       multiple sections, which group related topics together.  A
       topic is slightly indented, the section heading is not.

       You can move around using the mouse, clicking  on  topics.
       You  can  also page through the entire help using PageDown
       or PageUp.  To move from section to section, use the  Left
       arrow  to  move  up  and  the Right arrow to move forward.
       This is fairly useful since the first entry in  each  sec-
       tion tries to give a brief overview of that section.

HYPERLINK STACK
       Helptool has a stack of places that you have visited, very
       similar to  the hyperlink stack in Netscape.  If you click
       on  a topic you will notice that the "Back" button becomes
       enabled.  Clicking it  will  move  back  to  the  previous
       topic.   Similarly  for  forward.  The same hot keys which
       work in Netscape are used here for forward and back.

SEARCHING
       Helptool includes a simple search facility.  To search for
       information,  you type a word or phrase and hit return (or
       click on Search).  The search facility  is  fairly  basic,
       single word searches tend to work better than phrases.  If
       a phrase is wanted, it must be put in quotes, i.e.,  "lock
       file".   By  default,  the  search will return approximate
       matches, i.e., searching on "a" will return anything  with
       the  letter  "a".   There  is a config option to turn this
       off.

       The  lines  which  match,  if  any,  are  shown   slightly
       indented.   Above the indent lines is the name of the com-
       mand or help page which contains the lines.  You can click
       on  that to jump to that page.  Each command or page which
       contains the search  phrase  will  be  be  highlighted  in
       orange  so  that you click through each of the pages which
       contain the information.

       If you go to a page and it was not what  you  wanted,  and
       you  wish to look at the summary lines again, jump back by
       clicking Search or hitting return.  Note that  the  search
       results  are  not  part  of the hyperlink stack of visited
       pages, but you can get back to the search results  at  any
       time by hitting Return.

BINDINGS
       The  up/down  bindings  will  move through topics, so when
       they hit the end and the key is pressed again,  the  topic
       changes to the next or previous.

       DownArrow      Scroll the help text down one line.
       UpArrow        Scroll the help text up one line.
       LeftArrow      Scroll the help text left one column.
       RightArrow     Scroll the help text right one column.
       PageDown       Scroll the help text down one screen.
       PageUp         Scroll the help text up one screen.
       Home           Scroll to the top of help text.
       End            Scroll to the bottom of the help text.
       Control-Up     Move  to  the  beginning  of  the  previous
                      topic.
       Control-Down   Move to the beginning of the next topic.
       Control-Left   Move to the beginning of the  next  section
                      (not topic).
       Control-Right  Move  to the beginning of the previous sec-
                      tion (not topic).
       Alt-Left       Move backwards to  the  previously  visited
                      topic.
       Alt-Right      Move  forwards  to the to the next topic in
                      the stack.
       Escape         Exit bk helptool.
       Control-b      Scroll the help text up one screen.
       Control-f      Scroll the help text down one screen.
       Control-e      Scroll the help text down one line.
       Control-y      Scroll the help text up one line.
       Control-q      Exit from helptool.

SEE ALSO
       bk help config-gui

CATEGORY
       GUI-tools

BitMover, Inc               2002/10/02                          1
$
help://history
help://history.1
help://bk-history
help://bk-history.1

bk history(1)        BitKeeper User's Manual        bk history(1)

NAME
       bk  history  - guide to viewing changes over time of files
       and repositories

DESCRIPTION
       Note: there is a GUI tool  for  viewing  changes,  see  bk
       revtool.

       If  you  want to view the high-level changes to a package,
       (i.e. the changes associated with the ChangeSet) type:

           $ bk changes

       Two ways to view file history are on a per-file basis  and
       a  method  which shows the changes over a set of files.  A
       third method is to use "bk revtool" which is  a  graphical
       file viewer.

       The revision history of a file can be accessed by typing:

           $ bk prs foo.c

       Prs  has  many options. The most useful is probably the -r
       option that lets you specify a revision.

       To see the most recent check-in for every file in the cur-
       rent directory:

           $ bk prs -r+

       To  see  all  changes  from  Alpha  to Beta, (assuming you
       tagged the files with those tags) try:

           $ bk prs -cAlpha..Beta

       The bk sccslog command is useful when you  are  interested
       in  the  history  of  the entire tree or subdirectory, not
       just the per-file revision history.  The bk  sccslog  com-
       mand  sorts  all  the  changes  based  on date, so you see
       deltas from different files in chronological order.   This
       process can take substantial CPU and memory resources, but
       the following is a very useful thing to see:

           $ bk sfiles | bk sccslog - | more

       bk sccslog supports the same range notation as prs.

SEE ALSO
       bk help changes
       bk help prs
       bk help range
       bk help sccslog

CATEGORY
       Overview
       Repository

BitMover, Inc               2002/09/17                          1
$
help://id
help://id.1
help://bk-id
help://bk-id.1
help://identity

bk id(1)             BitKeeper User's Manual             bk id(1)

NAME
       bk id - display the identity of a package or repository

SYNOPSIS
       bk id [-r]

DESCRIPTION
       In  BitKeeper, each repository has two identities: a pack-
       age identity and a repository identity.

       The package identity is the  same  across  all  repository
       instances  of the same package.  Two repositories may syn-
       chronize with each other if and only if they have the same
       package identity.  bk id displays the package identity.

       The  repository  identity is different in each repository,
       regardless of the package.  bk id -r displays the  reposi-
       tory identity.

SEE ALSO
       bk help newroot
       bk help terms

CATEGORY
       Repository
       Admin

BitMover, Inc               2002/11/18                          1
$
help://ignore
help://ignore.1
help://bk-ignore
help://bk-ignore.1

bk ignore(1)         BitKeeper User's Manual         bk ignore(1)

NAME
       bk ignore - ignore shell glob patterns

SYNOPSIS
       bk ignore [<'glob'> [<'glob'>...]]

DESCRIPTION
       The  ignore  command is used to tell BitKeeper about files
       which should be ignored when looking for extras files  not
       under  revision  control.   It  affects  the  output of bk
       sfiles -x and all commands which use that output, such  as
       bk status and bk extras.

       Typical  things  to  ignore  are object files, core files,
       a.out, *.exe, etc.

       The patterns are matched against both the basename of  the
       file  and  the pathname of the file.  If you are trying to
       never have the file  <JUNK>  match,  regardless  of  which
       directory it is in, you can say

           bk ignore 'JUNK'

       and  that  will  match  <JUNK>  and <sub/dir/JUNK> but not
       <JUNK-PRECIOUS>.

       If you want to match a file in just one subdirectory,  you
       can do

           bk ignore sub/directory/this_one

       which   will   match   <sub/directory/this_one>   but  not
       <other_dir/this_one>.

       If you give ignore no arguments it will print out the cur-
       rent ignore list.

       The ignore list is saved in the file BitKeeper/etc/ignore.
       You may edit this file if you wish; the format  is  simply
       one  glob  per  line.  Editing the ignore file is the only
       way to remove entries from the list.

       There is currently no default list, but the  following  is
       suggested:

           core
           *.o
           *.swp
           *.a
           *.exe
           *~
           *.rej
           *.orig
           BitKeeper/etc/*
           BitKeeper/tmp/*
           BitKeeper/triggers/*

BUGS
       There  is  no per directory .bkignore list, nor is there a
       ~/ .bkignore list.

SEE ALSO
       bk help sfiles
       bk help extras

CATEGORY
       Admin

BitMover, Inc               2002/09/17                          1
$
help://import
help://import.1
help://bk-import
help://bk-import.1

bk import(1)         BitKeeper User's Manual         bk import(1)

NAME
       bk import - import files or changes into a BitKeeper pack-
       age

SYNOPSIS
       bk import -tpatch [OPTIONS] <patch> <destination>
       bk import -temail [<destination>] < mbox
       bk import -tplain [OPTIONS] <directory> <destination>
       bk import -tRCS   [OPTIONS] <directory> <destination>
       bk import -tCVS   [OPTIONS] <directory> <destination>
       bk import -tSCCS  [OPTIONS] <directory> <destination>

DESCRIPTION
       Use bk import to  put  plain  text  files,  patches  (diff
       -Nur), patches and comments in the form of email messages,
       SCCS files, and RCS/CVS files (in this document  RCS  will
       mean both RCS AND CVS) into a BitKeeper package.  For file
       (text, SCCS, RCS, etc) imports, bk import  does  its  work
       outside  of  your  original tree thus leaving the original
       files intact while importing them into a  BitKeeper  pack-
       age.

       In  the  case of RCS and SCCS files, import should only be
       invoked once into a destination package.  It can  be  used
       repeatedly  if you are importing traditional patches (diff
       -Nur) into a repository over time.

       A more detailed explanation  of  importing  the  different
       types of files can be found below.

OPTIONS
       -C        Do not commit the ChangeSet.
       -f        Force; do not prompt for list editing.
       -F        Fast;   run  more  quickly  for  large  imports.
                 NOTICE: use this option only when you know  that
                 this  is  the  only  BitKeeper  activity you are
                 doing.   Using  this  option  on  two   parallel
                 imports  may  cause  BitKeeper consistency prob-
                 lems.
       -H        do not pass -h option  to  rcs2sccs  (turns  off
                 verification, faster, unsafe).
       -i        Prompts for a regular expression to apply to the
                 list of files.  All matches are  included.  (For
                 use with all types except patches.)
       -l<file>  Use  the list of files in <file>.  (For use with
                 all types except patches.)
       -q        Be quiet.
       -S<sym>   Add tag <sym> to the  changeset  created  around
                 the import
       -t<type>  Specify import file type.  <type> can be one of:
          plain  Import plain text files
          patch  Import a patch (diffs)
          RCS    Import RCS files
          CVS    Import CVS files
          SCCS   Import SCCS files
       -v        Be verbose.
       -x        Prompts for a regular expression to apply to the
                 list  of files.  All matches are excluded.  (For
                 use with all types except patches.)

RCS OPTIONS
       -A      Attic processing (CVS  import  only).   Moves  all
               files  which  do  not have name conflicts from the
               Attic subdirectories to the enclosing  repository,
               i.e., "mv Attic/*,v .".
       -c<tag> do not import anything after <tag>.
       -j<n>   n-way parallel for RCS conversion.
       -u      Run  files  through bk undos first; this will con-
               vert DOS style end of lines to Unix style  end  of
               lines.

PATCH OPTIONS
       -r  Do  not do rename processing when doing patch imports.
       -R  If a patch fails to apply cleanly, back out the entire
           operation and exit with a failure.
       -y<comment>
           Set  the  message for the delta comments for all files
           to <comment> rather than "Import patch PATCHNAME".

IMPORTING PATCHES
       BitKeeper can be used to track external work by  importing
       patches  (diff  -Nur) into a BitKeeper package.  BitKeeper
       can help with downsides of patches,  namely  that  renames
       are  not tracked well and that there generally aren't very
       good comments if any at all attached to the changes  being
       made.   A  rename  in a patch is viewed as the deletion of
       one file and the creation of another  file,  so  to  track
       these,  bk  import  will launch bk renametool which is the
       graphical tool used to manually match  the  deleted  files
       with the newly created files.

IMPORTING EMAILS
       BitKeeper  can import patches contained in email messages.
       This style of import is an additional layer over the  nor-
       mal patch import.  The usage for this version of bk import
       is

           bk import -temail repo < mailbox

       where mailbox may contain multiple messages, each contain-
       ing  a  patch.   The  user and hostname are taken from the
       email header and the subject line is used as  the  checkin
       comment  for  each  file, as well as the first line of the
       changeset comment.  If there is  any  preamble  above  the
       patch, that is used as the rest of the changeset comments.
       Note that importing an email patch records the name of the
       importer  as  well as the name of author (which is derived
       from the email).  The importer name is available  via  the
       :IMPORTER: key word, see bk help prs for more information.

       This part of import makes use of code copyrighted by Linus
       Torvalds and is used with permission.

IMPORTING RCS FILES
       The default branch of the RCS tree is the one that will be
       imported.  All other  branches  are  discarded.   Metadata
       from  the  ,v files is preserved upon import.  Thus saving
       the history of your files.

       This is a one time only import.  Importing to a  clone  of
       the  destination  package  is  advised  in case the import
       fails, the package won't get corrupted.

       The type of import requires RCS 5.6 or later.

IMPORTING PLAIN TEXT
       Importing a plain text file into a BitKeeper  package  can
       only  be  done  once.   If  there is already a file in the
       package that has the same name as a file  to  be  imported
       the import will fail.

       If  a  package is already populated with files use the -i,
       -x or -l options to avoid trying to import  files  already
       in  the  package.   Because of the preceeding constraints,
       import does not catch renames with plain text files.  If a
       file  has been renamed, it can be imported, but the origi-
       nal file will still exist in the package so it  is  neces-
       sary  to  remove  the  original file from the package tree
       after the import of the renamed file.

       Plain text files can be imported from a directory,

           bk import /path/to/src_files ~/package

       from a list of files relative to the source directory,

           bk import -l/tmp/list /path/to/src_files ~/package

       or by using regular expressions in interactive mode

           bk import -ix ~/src_files ~/package
           End patterns with . by itself or EOF
           File name pattern to include>> *.c
           File name pattern to include>> *.h
           File name pattern to include>> Makefile
           File name pattern to include>> .
           End patterns with . by itself or EOF
           File name pattern to exclude>> *.o
           File name pattern to exclude>> .

IMPORTING SCCS FILES
       Teamware and other SCCS files can be imported.   The  his-
       tory  of  the file is preserved, but the unmerged branches
       are discarded.  This is okay because the  necessary  meta-
       data is in the mainline.

       Importing  BitKeeper files is not supported; use bk clone.

ERROR HANDLING
       Import does not handle errors in a robust way.  If  unsuc-
       cessful,  import  may leave work half done in the destina-
       tion package.  It is suggested that the import destination
       repository is a clone of the original package in case of a
       failed import.

SEE ALSO
       bk help prs
       bk help rcs2sccs
       bk help undos

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://info
help://info.1
help://bk-info
help://bk-info.1

bk info(1)           BitKeeper User's Manual           bk info(1)

NAME
       bk info - show the state of BitKeeper files

SYNOPSIS
       bk info [<file> ... | -]

DESCRIPTION
       The  bk info command shows the state of a set of specified
       or implied set of files.

       The state is as follows:

       slib.c:     1.361 1.362 lm 99/09/22 03:36:18 (modified, needs delta)
       sinfo.c:    1.16 1.17 lm 99/09/22 22:15:58 (modified, needs delta)
       fdiff.c:    1.77 1.78 lm 99/09/22 22:15:57

       The field names (taken from the first line in the example)
       are:

       slib.c   name of the file.
       1.361    basis for (parent revision of) the edited file;
       1.362    revision to be created at checkin time;
       lm       name of the user who edited the file;
       99/09/22 03:36:18
                date and time when the file was locked.
       (modified, needs delta)
                if  present, indicates that the file is modified.

NOTE
       Most people prefer the bk  sfiles  interface  for  finding
       files in a particular state.

SEE ALSO
       bk help prs
       bk help sfiles
       bk help status

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://initscripts
help://initscripts.1
help://bk-initscripts
help://bk-initscripts.1
help://Admin/init.d

bk initscripts(1)    BitKeeper User's Manual    bk initscripts(1)

NAME
       bk  initscripts - sample script for starting the BitKeeper
       daemon

EXAMPLES
           #!/bin/sh
           #
           # bitkeeper    Start/stop the bitkeeper daemon.
           #         @(#)bitkeeper.init 1.1 Copyright (c) 2000 Larry McVoy
           #
           # When starting repositories that are bound
           # to a specific port, create a file named
           # /var/bitkeeper/repositories. The repositories
           # file will contain a line for each repository.
           # The line consists of the directory where the
           # repository resides and a set of options used
           # when started the bk daemon.
           #
           # For example:
           #
           # ---- cut here and remove the leading hash mark and spaces -----
           # /home/bk/LMbench -p5000 -xcd -xpush -u99
           # /home/bk/bitcluster -p6000 -xcd -xpush -u99
           # /home/bk/one -p7000 -xcd -xpush -u99
           # --------------------- cut here ----------------------

           # Source networking configuration.
           if [ -f /etc/sysconfig/network ]
           then . /etc/sysconfig/network

                # Check that networking is up.
                [ ${NETWORKING} = "no" ] && exit 0
           fi
           [ -x /usr/bin/bk ] || exit 0
           VAR=/var/bitkeeper

           case "$1" in
               start_msg) echo "Start BitKeeper daemons"
                     ;;
               stop_msg)  echo "Stop BitKeeper daemons"
                     ;;
               restart)   $0 stop
                     $0 start
                     ;;
               start)     cd $VAR || exit 1
                     test -f repositories || {
                          echo Nothing advertised: Are there any entries in the
                          echo $VAR/repositories file?
                          exit 0
                     }
                     while read dir opts
                     do   (
                          cd $dir || exit 1
                          F=`basename $dir`
                          bk bkd $opts -l$VAR/log.$F -P$VAR/pid.$F
                          echo Started bkd $opts in $dir
                          )
                     done < repositories
                     ;;

               stop)
                     cd $VAR || exit 1
                     echo Shutting down BitKeeper daemons
                     for i in pid.*
                     do   kill -HUP `cat $i`
                          rm $i
                     done
                     ;;

               status)    ps -axf | grep bkd
                     ;;

               *)         echo "Usage: bitkeeper {start|stop|restart|status}"
                     exit 1
                     ;;
           esac
           exit 0

CATEGORY
       Overview
       Admin

BitMover, Inc               2002/09/17                          1
$
help://isascii
help://isascii.1
help://bk-isascii
help://bk-isascii.1

bk isascii(1)        BitKeeper User's Manual        bk isascii(1)

NAME
       bk isascii - check that a file is ascii

SYNOPSIS
       bk isascii <filename>

DESCRIPTION
       bk isascii looks through a file for binary data which Bit-
       Keeper can not handle without  encoding  the  file.   This
       consists of a NULL (zero byte).

EXIT CODES
       0 if ascii, 1 otherwise.

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://key2rev
help://key2rev.1
help://bk-key2rev
help://bk-key2rev.1

bk key2rev(1)        BitKeeper User's Manual        bk key2rev(1)

NAME
       bk key2rev - convert BitKeeper keys to revisions

SYNOPSIS
       cat keys | bk key2rev <file>

DESCRIPTION
       This  utility takes one or more keys on stdin and converts
       them to revision numbers.

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://keywords
help://keywords.1
help://bk-keywords
help://bk-keywords.1

bk keywords(1)       BitKeeper User's Manual       bk keywords(1)

NAME
       bk keywords - list of RCS and SCCS keywords

DESCRIPTION
       BitKeeper  supports  both  the  standard SCCS keywords, as
       well as most of the RCS keywords. In addition,  there  are
       several keywords that are unique to BitKeeper.

       Note: All of the revision-oriented keywords (e.g. %I%) are
       useless in BitKeeper since they may change as a result  of
       a  resynchronization  that  causes a branch creation.  Use
       the %K% keyword when you need an identifier that is unique
       to a specific revision-level of a file. The %K% keyword is
       useful when tracking customer bugs. For example, a techni-
       cian  might ask the end-user to run the what command on an
       executable to check the versions of  the  components  that
       make  up  a program.  The person doing troubleshooting can
       then use the %K% keyword to track down the specific source
       files that make up the executable.

       Note: SCCS keyword expansion can cause problems in printf-
       like strings.  To deal with  unwanted  keyword  expansion,
       BitKeeper  can  be  given options to expand only the first
       keyword found. See bk help admin.

SCCS KEYWORDS
            %A%  Shorthand notation for an ID line with data for what(1):
                 %Z% %M% %I%%Z% @(#) GET 1.1@(#)
            %B%  SID branch component                    0
            %D%  Current date: yy/mm/dd                  91/04/13
            %E%  Date newest applied delta was created:  91/04/13
            %F%  SCCS s.file name                        SCCS/s.GET
            %G%  Date newest applied delta was created: mm/dd/yy
                                                         4/13/91
            %H%  Current date: mm/dd/yy                  4/13/91
            %I%  SID of the retrieved version: %R%.%L%.%B%.%S%
                 1.1 or 1.1.0.0 if fully specified as shown in the previous line
            %K%  Key for the delta (these do not change)
                 lm@va.bitmover.com|src/bkhelp.txt|19991116191217|50766
            %L%  SID level component                     1
            %M%  Module name: either the value of the m flag in the s.file
                 or the name of the s.file less the prefix
                                                         GET
            %P%  Fully-qualified s.file name             /u/lm/SCCS/s.GET
            %R%  SID Release component                   1
            %S%  SID Sequence component                  0
            %T%  Current time: hh:mm:ss                  12:41:29
            %U%  Time the newest applied delta was created: hh:mm:ss
                                                         12:41:29
            %W%  Shorthand notation for an ID line with data for what:
                 %Z%%M% %I%     @(#)GET                  1.1
            %Y%  SCCS Compatible, not expanded in BitKeeper
            %Z%  4-character string: recognized by what. @(#)
            %@%  user@host
            %#%  user

RCS KEYWORDS
       The following is the subset of RCS keywords that BitKeeper
       supports.   The  RCS keywords are only expanded if the RCS
       flag is turned on.  See bk help admin.

        $Revision$  $Revision: 1.2 $
        $Id$        $Id: s.rcs_expand.c 1.2 99/11/16 11:25:18-08:00 lm@r.com $
        $Author$    $Author: lm@r.com $
        $Date$      $Date: 99/11/16 11:25:18-08:00 $
        $Header$    $Header: SCCS/s.rcs_expand.c 1.2 99/11/16 11:25:18-08:00 lm@r.com $
        $RCSfile$   $RCSfile: s.rcs_expand.c $
        $Source$    $Source: /tmp/beta11/src/SCCS/s.rcs_expand.c $

SEE ALSO
       bk help admin
       bk help config-etc
       bk help get

CATEGORY
       Overview

BitMover, Inc                 201E1                             1
$
help://level
help://level.1
help://bk-level
help://bk-level.1
help://workflow

bk level(1)          BitKeeper User's Manual          bk level(1)

NAME
       bk level - set or show the level of the repository

SYNOPSIS
       bk level [<num>]

DESCRIPTION
       The  level command prints or sets the level of the reposi-
       tory.  A repository with  no  level  setting  defaults  to
       level 1.  The level is automatically set when a repository
       is cloned to the level of the parent repository.

       With an argument, it sets  the  level  to  that  argument.
       With no argument, the command prints the repository level.
       If an error occurs,  the  level  is  shown  as  1  million
       (1000000).

       Repository  levels  may  be  used  to  control the flow of
       changesets.  Changes may only flow to a repository of  the
       same  or  higher  level.  The typical use for levels is to
       create a stable or bugfix repository.  If that  repository
       has a lower level than the development repository, changes
       may be moved from stable to development, but not the other
       way.

SEE ALSO
       bk help clone
       bk help pull
       bk help push

CATEGORY
       Repository

BitMover, Inc               2003/06/04                          1
$
help://licensing
help://licensing.1
help://bk-licensing
help://bk-licensing.1
help://Licensing/License
help://Licensing/license
help://single_user

bk licensing(1)      BitKeeper User's Manual      bk licensing(1)

NAME
       bk licensing - BitKeeper Licensing Overview

DESCRIPTION
       This  section briefly explains the licensing models.   See
       the references for more detailed information.

       BitKeeper has multiple licensing models:

       =>free with no Open Logging (aka single  user),  license
       is  the BKL.
       =>free with Open Logging, license is the BKL.
       =>commercial, license is the BKCL.

FREE USE WITH NO LOGGING
       BitKeeper can be used for free, without licensing or  Open
       Logging,  if  the  repository  is single user. To create a
       single user repository, at setup  time  pick  a  permanent
       user   name   and   a  host  name  and  add  to  the  Bit-
       Keeper/etc/config file; all deltas will appear to be  made
       by this user.

       The lines in the config file must look like this:

           single_user:<user_name>
           single_host:<host_name>

       The  <user_name> and <host_name> can be anything, but once
       they have been chosen they cannot be changed.  If  changed
       the  repository will be seen as a multiple user repository
       by BitKeeper and will either need a license  key  or  will
       need to participate in Open Logging.

       To  change  a  single  user  repository to a multiple user
       repository see bk multiuser.

   WARNING
       Single user repositories only work  on  repositories  that
       have less than 1000 files.  If the maximum is reached, the
       repository will not allow any more  changesets  to  occur.
       To  use the repository again, the repository must be setup
       for openlogging or a commercial license must be purchased.

       Once  a repository is changed from a single user to multi-
       ple user repository it can not be changed to a single user
       repository again.  Once a multiple user repository it must
       be setup for openlogging or a commercial license  must  be
       purchased.

       If  you are looking for the BitKeeper License for free use
       (BKL), see bk help bkl.

FREE USE WITH LOGGING
       BitKeeper may be used for free, without any  functionality
       loss or other restrictions, if Open Logging is used.

       To setup openlogging, add the following line to the config
       file:

           logging:logging@openlogging.org

COMMERCIAL USE
       The use of BitKeeper without Open Logging enabled requires
       a commercial license key.  You can obtain a 30-day license
       for  evaluation  by  emailing  a  request  to   sales@bit-
       mover.com.

       Once  the  license key is obtained, add a line to the Bit-
       Keeper/etc/config file that looks like:

           license: <license key>

SEE ALSO
       bk help bkl
       bk help config-etc
       bk help multiuser
       bk help openlogging

CATEGORY
       Licensing
       Overview

BitMover, Inc               2002/09/17                          1
$
help://links
help://links.1
help://bk-links
help://bk-links.1

bk links(1)          BitKeeper User's Manual          bk links(1)

NAME
       bk links - make links to the BitKeeper binary installation
       directory

SYNOPSIS
       bk links <bk_bin_dir> [<public_dir>]

DESCRIPTION
       Makes links from BitKeeper commands in the specified  pub-
       lic  directory  to  the executables in the named BitKeeper
       binary directory.  This is typically used after installing
       BitKeeper as a non-root user.

       The  links  are made to /usr/bin if no public directory is
       specified.

       The purpose of the symbolic links is to provide compatible
       interfaces  for  those tools which understand the ATT SCCS
       system.  BitKeeper deliberately chooses to look like  SCCS
       so  that programs such as make(1), patch(1), emacs(1), and
       others will automatically work with BitKeeper the same way
       they  worked  with  SCCS.   BitKeeper is not an SCCS based
       system, it just appears as such on the  command  line  for
       compatibility with existing applications.

EXAMPLE
           $ bk links /usr/libexec/bitkeeper /usr/local/bin
           ln -s /usr/libexec/bitkeeper/admin /usr/local/bin/admin
           ln -s /usr/libexec/bitkeeper/get /usr/local/bin/get
           ln -s /usr/libexec/bitkeeper/delta /usr/local/bin/delta
           ln -s /usr/libexec/bitkeeper/unget /usr/local/bin/unget
           ln -s /usr/libexec/bitkeeper/rmdel /usr/local/bin/rmdel
           ln -s /usr/libexec/bitkeeper/prs /usr/local/bin/prs
           ln -s /usr/libexec/bitkeeper/bk /usr/local/bin/bk

SEE ALSO
       bk help bin

CATEGORY
       Utility

BitMover, Inc               2003/06/20                          1
$
help://lock
help://lock.1
help://bk-lock
help://bk-lock.1

bk lock(1)           BitKeeper User's Manual           bk lock(1)

NAME
       bk lock - lock a repository or show lockers

SYNOPSIS
       bk lock [-l|r|w|L|U] [-q] [directory]

DESCRIPTION
       The  lock command can be used to lock an entire repository
       or to list the lockers of a repository.  If a directory is
       specified,  the operation applies to the repository rooted
       at that directory.

       Since a lock is valid only as long as the locking  process
       exists,  when  placing   lock,  the  lock command does not
       exit, it goes to sleep waiting for a signal.

OPTIONS
       -l     List the lockers of a repository.
       -q     quiet, exit status only
       -r     Add a read lock (non-exclusive).
       -w     Add a write lock (exclusive).
       -L     Wait for the repository to become locked (primarily
              used for testing).
       -U     Wait for the repository to become unlocked (primar-
              ily used for testing).

EXIT STATUS
       If called with no options or if called with the -l option,
       lock  exits  1  if the repository has locks and exits 0 if
       the repository has no locks.

       If called with either -r or -w, lock exits 1 if unable  to
       lock the repository.

SEE ALSO
       bk help unlock

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://lod
help://lod.1
help://bk-lod
help://bk-lod.1

bk setlod(1)         BitKeeper User's Manual         bk setlod(1)

NAME
       bk lod - line of development

DESCRIPTION
       LODs are not a supported feature in this release.

       The interface is very likely to change to

       bk lod set
       bk lod create
       bk lod pull

       The current interface is undocumented.

BitMover, Inc               2002/09/17                          1
$
help://log
help://log.1
help://bk-log
help://bk-log.1

bk log(1)            BitKeeper User's Manual            bk log(1)

NAME
       bk log - Log changesets

SYNOPSIS
       bk log [-dp]

DESCRIPTION
       bk  log  is  the mechanism by which changesets are sent to
       www.openlogging.org when the repository  is  participating
       in  open  logging.  When a repository is set for open log-
       ging, the bk log command is run  automatically  at  commit
       time or when bk push or bk pull are run.

       bk  log  uses  HTTP  protocol  to  transfer  cset  logs to
       www.openlogging.org.  To  view  the  received  logs  visit
       http://www.bitkeeper.com/v2_logging.

   OPEN LOGGING
       Open  logging is required if BK/free is being used and you
       are not running in single user mode.  Please see the  Bit-
       Keeper  license (bk help bkl), bk help openlogging, and bk
       help config-etc for more information.

       bk log will be unsuccessful in its attempt to send change-
       sets if the host machine is unable to contact www.openlog-
       ging.org.  This may be a result of a network  connectivity
       problem  or problems with the logging tree at www.openlog-
       ging.org.  (See the ERROR HANDLING subsection for  further
       discussion.)

   PENDING CHANGESETS
       If  open  logging  is enabled and bk log is unable to send
       changesets to www.openlogging.org pending changesets  will
       accumulate.  bk commit will fail if there are more than 40
       pending changesets that are older than one week.

       If you are going to be disconnected  from  a  network  for
       more than one week reset pending logs to zero by running

           bk log

       before disconnecting.

       Use  the  -p option to find the number of unlogged/pending
       changesets.

       If the limit is reached it is important to log the change-
       sets  as  soon  as possible.  In emergencies, to get a few
       more pending changesets, set the BK_NEEDMORECSETS environ-
       ment variable.

   ERROR HANDLING
       If a commit fails with the error message:

           Error: Max pending log exceeded, commit aborted

       it  is  generally due to a network connectivity problem or
       problems with the  logging  tree  at  www.openlogging.org.
       Use  the  -d  option to figure out which problem is occur-
       ring.  If a  connectivity  problem  has  been  ruled  out,
       please send the output of

           bk log -d

       to support@bitmover.com.

OPTIONS
       -d     Debug  mode;  print  debug  message (including root
              key).
       -p     Print the number of unlogged changesets.

SEE ALSO
       bk help bkl
       bk help openlogging
       bk help config-etc

CATEGORY
       Admin

BitMover, Inc               2002/09/17                          1
$
help://makepatch
help://makepatch.1
help://bk-makepatch
help://bk-makepatch.1

bk makepatch(1)      BitKeeper User's Manual      bk makepatch(1)

NAME
       bk makepatch - creates BitKeeper patches

SYNOPSIS
       bk makepatch [-vd] [-c<range>] [-e<range>] [-r<range>] [-]

DESCRIPTION
       The makepatch command is a low level command used to  gen-
       erate BitKeeper patches.

OPTIONS
       -c        Like  -r,  except generate only ChangeSet diffs.
                 Used for logging only.
       -d        Add a header with the unified diffs to  the  top
                 of the BitKeeper patch.
       -e<range> Like  -r,  except  generate only metadata diffs.
                 Used for logging only.
       -r<range> Generate a BitKeeper patch  of  the  changes  in
                 <range>.
       -v        Be more verbose for each instance.

NOTES
       The  supported interface for creating BitKeeper patches is
       bk send.  And bk export -tpatch should be used  to  create
       GNU patches.

SEE ALSO
       bk help cset
       bk help export
       bk help gnupatch
       bk help rset

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://merge
help://merge.1
help://bk-merge
help://bk-merge.1

bk merge(1)          BitKeeper User's Manual          bk merge(1)

NAME
       bk merge - three-way text based file merge

SYNOPSIS
       merge <local> <ancestor> <remote> <merge>

DESCRIPTION
       The  bk  merge command combines changes made to <ancestor>
       by <local> with the changes made to <ancestor> by <remote>
       and merges them into <merge>.

       If  all  changes  are  made  to  different  regions of the
       <ancestor>, then the merge is said to be free of conflicts
       and happens without any further human intervention.

       A  conflict  occurs if both <local> and <remote> have made
       changes to the same section of <ancestor>.  If a  conflict
       is found, the conflicting lines will be marked in the out-
       put as follows:

           <<<<<<< <local>
           changes made in the local repository
           =======
           changes made in the remote repository
           >>>>>>> <remote>

       It is up to the  caller  to  edit  the  <merge>  file  and
       resolve any conflicts.

WARNING
       Nobody  likes  to  hear  this,  but this sort of automatic
       merge can get you in trouble.  The problem is that this is
       a  syntactic merge, not a semantic merge.  In other words,
       just because the files do  not  have  overlapping  changes
       does  not  mean  that the merge will work.  It's up to the
       user to look carefully at the  results  and  verify  their
       correctness.

EXIT STATUS
       0 for no conflicts, 1 for conflicts, 2 for errors.

SEE ALSO
       diff3(1)
       bk help smerge
       bk help fmtool
       bk help merging
       bk help resolve

CATEGORY
       Repository
       File

BitMover, Inc               2002/09/17                          1
$
help://merge-binaries
help://merge-binaries.1
help://bk-merge-binaries
help://bk-merge-binaries.1

bk merge-binaries(1) BitKeeper User's Manual bk merge-binaries(1)

NAME
       bk merge-binaries - help on merging binary conflicts

DESCRIPTION
       This section documents the binary merge process started by
       the resolve command.  See bk resolve for details on  using
       resolve.

       While in resolve, you can hit the return key to see a sum-
       mary of the commands.

       BitKeeper has no built in  mechanism  to  merge  binaries,
       since it does not know what is in the binaries.  The built
       in choices you have are  outlined  in  the  resolver,  and
       amount  to choosing either the local or the remote version
       of the file.

       The built in choices do not include a  file  viewer  since
       BitKeeper  does  not  know what to use.  You can call your
       own file viewer.  Suppose you knew that the file was a gif
       and you wanted to look at each of them to choose which one
       to use.  You could do a

           logo.gif>> !xv $BK_LOCAL
           logo.gif>> !xv $BK_REMOTE
           logo.gif>> ul

       to view each and then choose the local version.

       You may also call an external tool to merge changes.

           logo.gif>> !<command>

       then <command> will be run with the  appropriate  environ-
       ment variables set.  This technique may be used to use any
       external merge tool.

ENVIRONMENT VARIABLES
       BK_LOCAL  pathname of a temp  file  containing  the  local
                 version
       BK_GCA    pathname  of  a  temp file containing the common
                 ancestor
       BK_REMOTE pathname of a temp file  containing  the  remote
                 version
       BK_MERGE  pathname  where  the  merged  content  should be
                 placed

NON-BINARY FILES
       Sometimes a file may  be  marked  as  binary  incorrectly,
       where incorrectly means that normal text based tools would
       work on this file.  You may force the file to  be  treated
       as  a text file with the "t" command.  This drops into the
       normal text file resolver.

SEE ALSO
       bk help merge
       bk help merging
       bk help fmtool
       bk help revtool
       bk help resolve

CATEGORY
       Overview
       Repository

BitMover, Inc               2002/09/17                          1
$
help://merging
help://merging.1
help://bk-merging
help://bk-merging.1

bk merging(1)        BitKeeper User's Manual        bk merging(1)

NAME
       bk merging - help on merging conflicts

DESCRIPTION
       This  section  documents  the merge process started by the
       resolve command.  See bk  resolve  for  details  on  using
       resolve.

       While in resolve, you can hit the return key to see a sum-
       mary of the commands.

       The bk resolve command prompts you on each file  that  has
       conflicts.   A  conflict  is defined as two deltas made in
       parallel in different repositories.  If the conflict  does
       not  have  any  overlapping  lines,  then it may have been
       automerged, depending if bk resolve was run  with  the  -a
       option.

       There are other sorts of conflicts, besides the usual file
       content conflicts.  BitKeeper manages file names,  permis-
       sions,  flags,  symbols,  and descriptive text in the same
       way as it manages file contents.  That means that you  can
       have  a  permissions  conflict if, for example, one person
       changed the file to 0755 mode and another  changed  it  to
       0777 mode.

       The  resolve  process for all conflicts is fairly similar.
       For each type of  conflict  on  each  file,  you  will  be
       prompted  for  an  action.  To view a brief summary of the
       conflict and a list of available actions, hit  return  (or
       "?"  or  "help").   The  choices  usually  include  a more
       detailed explanation of the situation; we try  to  consis-
       tently  make  this  available  as  the  "x" command (as in
       eXplain).

       Some of the available actions allow you to diff the files,
       view  file  history, and merge using graphical tools, etc.
       See the command summary for the full list.

VIEW DIFFERENCES AND HISTORY
       To see the diffs use the "d"  command.   For  side-by-side
       diffs, use the "sd" command.  You can also diff one or the
       other branches against the common ancestor using  "dr"  or
       "dl".   Type  "D" to get a graphical, color coded side-by-
       side diff browser.

       There are also built-in commands to show  the  history  of
       the  file  (see "h", "hl", "hr").  In addition, "p" starts
       the the graphical file browser which allows  you  to  view
       the  difference between versions by clicking the left but-
       ton on the earlier rev and the right  button  on  a  later
       rev.   The  bottom  of the screen will show the diffs.  If
       you type Return at the prompt, the three revisions forming
       the merge are part of the help message.

MERGING CONTENTS
       When  in  resolve, there are four different files for each
       merge.  They are:

       local  The version of the file in the local repository.
       remote The version of the file in the other repository.
       merge  The merged file.
       GCA    A common ancestor of the local/remote versions.

       Your goal is to generate the merge file using one  of  the
       methods below.

       The  easiest  and  most popular merge method is to use the
       "m" command for  cases  where  there  are  no  overlapping
       lines. This method performs a three-way diff and merge and
       warns you when there are overlapping lines.  If there  are
       overlaps,  you  have  to edit the merged file (use the "e"
       command), find the conflict markers which look like "<<<<"
       or  ">>>>",  and manually fix the conflicts.  This command
       requires care since non-overlapping lines  does  not  mean
       that the merge makes semantic sense.

       If  the  merge  looks  complicated,  a good approach is to
       start up the file browser with "p" and  then  start  up  a
       side-by-side  filemerge  with  "f".  Then walk through the
       diffs, picking and choosing with blocks of  code  to  use.
       If  you  get  confused about who added what, you can go to
       the history tool browser (revtool) and left click  on  the
       common ancestor and right click on each of the two tips of
       the trunk/branch to see who added what.

       It is also possible to  use  a  combination  of  graphical
       tools  and  the  automatic merge.  You can type "p" to run
       the file browser, "D" to  run  difftool,  "m"  to  do  the
       merge,  and  then  "e"  to edit the merged file.  The file
       browser is run in so you can look at the  various  changes
       as described above.  Warning: if you are running your edi-
       tor and the file merge program, then both are  working  on
       the  same  output  file  and whichever one writes it last,
       overwrites any earlier versions.

       You may also call an external tool to merge changes.  When
       in the resolver, if you say

           file.c>> !<command>

       then  <command> will be run with the following environment
       variables set:

       BK_LOCAL  pathname of a temp  file  containing  the  local
                 version
       BK_GCA    file containing the common ancestor
       BK_REMOTE pathname  of  a  temp file containing the remote
                 version
       BK_MERGE  pathname where  the  merged  content  should  be
                 placed

COMMIT
       The  merge  process  is  not complete until you commit the
       file with the "C" command at  the  resolve  prompt.   This
       means  you  can  merge repeatedly until you are happy with
       the results.  Each time you merge and save,  however,  you
       overwrite the previous merge attempt.

       When  you  are  happy with your merged file, click done in
       filemerge, exit the file browser,  and  type  "C"  at  the
       prompt to commit the file and move on to the next one.

SEE ALSO
       bk help smerge
       bk help merge
       bk help fmtool
       bk help revtool
       bk help resolve

CATEGORY
       Overview
       Repository

BitMover, Inc               2002/09/17                          1
$
help://multiuser
help://multiuser.1
help://bk-multiuser
help://bk-multiuser.1

bk multiuser(1)      BitKeeper User's Manual      bk multiuser(1)

NAME
       bk  multiuser  -  convert  a  single-user  repository to a
       multi-user repository

SYNOPSIS
       bk multiuser

DESCRIPTION
       Single User repositories are not obligated to  participate
       in  openlogging, however they only allow one person to use
       the repository.  If the repository is going to be used  by
       multiple  users or exceeds the 1000 file limit, it must be
       converted to a multi-user repository using bk multiuser.

       The conversion will generate a  new  ROOTKEY,  update  the
       csetfile  pointer  in all files, update all xflags, update
       the config  file,  and  create  a  changeset.   All  these
       changes  create  a  new  identity for the repository while
       saving the history of that repository.

       Please note that a converted  repository  and  a  non-con-
       verted  repository  can  not communicate, i.e., pushes and
       pulls will fail.  If there are two or  more  instances  of
       the  repository  to  be  converted,  make sure all pending
       changes are pushed to the master repository, run  bk  mul-
       tiuser on the master repository, and re-clone (making sure
       to remove all single-user clones).

       Multi-user repositories must follow the guidelines in  the
       BitKeeper  license  (see bk help bkl) by either setting up
       for Open Logging or by purchasing a commercial license.

SEE ALSO
       bk help openlogging
       bk help newroot
       bk help bkl

CATEGORY
       Repository
       Admin

BitMover, Inc               2002/09/17                          1
$
help://mv
help://mv.1
help://bk-mv
help://bk-mv.1

bk mv(1)             BitKeeper User's Manual             bk mv(1)

NAME
       bk mv - rename file[s]

SYNOPSIS
       bk  mv  [-f]  <source file[s]> <destination file or direc-
       tory>

DESCRIPTION
       To rename a file/directory from <A> to <B> do this:

           $ bk mv A B

       The mv command will rename the checked out file  (if  any)
       as  well  as  the revision control file.  Edited files are
       also renamed and then  reedited,  preserving  any  changes
       made but not yet checked in.  The rename will appear as an
       additional change to the file when  you  commit  the  next
       changeset.

       Renames  propagate  just  like content changes, i.e., they
       happen automatically  when  you  pull  changes  into  your
       repository  from  another  repository unless you have also
       renamed the file.  In that case, the resolver will  prompt
       you to choose a name.

       If  the  last  argument  is an existing directory, `bk mv'
       moves each other given file into a file with the same name
       in  that  directory.   Otherwise,  if  only  two files are
       given, it renames the first as the second.  It is an error
       if  the last argument is not a directory and more than two
       files are given. In summary, `bk mv' behaves like a a reg-
       ular  Unix  `mv'  command,  execpt that it knows about the
       additional BitKeeper files.

NOTES
       bk mv will refuse to move BitKeeper metafiles without  the
       -f option (use of which is not recommended).

SEE ALSO
       bk help commit
       bk help names
       bk help pull
       bk help push
       bk help rm
       bk help rmdir

CATEGORY
       File

BitMover, Inc               2003/06/04                          1
$
help://mvdir
help://mvdir.1
help://bk-mvdir
help://bk-mvdir.1

bk mvdir(1)          BitKeeper User's Manual          bk mvdir(1)

NAME
       bk mvdir - rename a BitKeeper directory

SYNOPSIS
       bk mvdir <source_dir> <destination_dir>

DESCRIPTION
       bk  mvdir  a deprecated interface.  To rename a directory,
       please use bk mv.

SEE ALSO
       bk help mv
       bk help rmdir

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://names
help://names.1
help://bk-names
help://bk-names.1

bk names(1)          BitKeeper User's Manual          bk names(1)

NAME
       bk names - put BitKeeper files where they should be

SYNOPSIS
       bk names [-q] [<file> ... | -]

DESCRIPTION
       Each  BitKeeper  s.file  records  its path relative to the
       root of the repository.  This command examines each of the
       listed  files  and moves them into their recorded location
       if they are not there already.

OPTIONS
       -q     Quiet mode.

CATEGORY
       Utility

BitMover, Inc               2000/12/15                          1
$
help://new
help://new.1
help://bk-new
help://bk-new.1
help://add

bk new(1)            BitKeeper User's Manual            bk new(1)

NAME
       bk new - add a file to the repository

SYNOPSIS
       bk new [-bq] <file>
       bk sfiles -x | bk new -

DESCRIPTION
       The new command is used when placing files under BitKeeper
       control.  The first form checks in a single file, the sec-
       ond  form  checks in all files in the repository which are
       not under BitKeeper control (be careful, the  second  form
       will  check  in anything, such as a.out, *.o, core, etc.).
       The bk new command is an alias for bk  delta  -i.   For  a
       complete list of options see bk help delta.

       When checking in multiple files in a directory, do:

           bk sfiles -x *.[ch] | bk new -

       When  you  want to check in files in the current directory
       and all subdirectories, do the following:

           bk sfiles -x | egrep '*.[ch]$' | bk new -

       After the files are checked in, don't be surprised to  see
       that  the  files are no longer in your directory. The pro-
       cess of checking in  files  removes  the  files  from  the
       directory  and  places them in the SCCS directories.  Once
       in the SCCS directory, the file can be retrieved with  the
       bk  get  or  bk  edit commands.  Most versions of the Unix
       make command know about SCCS and will automatically  check
       out files as they are needed.

OPTIONS
       -b     force  binary  encoding  with no keyword expansion;
              recommended for all binaries and Postscript  files,
              but will work on text files as well.
       -q     be quiet.

SEE ALSO
       bk help delta
       bk help edit
       bk help get
       bk help sfiles

CATEGORY
       File
       Common

BitMover, Inc               2002/02/05                          1
$
help://newroot
help://newroot.1
help://bk-newroot
help://bk-newroot.1

bk newroot(1)        BitKeeper User's Manual        bk newroot(1)

NAME
       bk newroot - change the identity of a repository

SYNOPSIS
       bk newroot

DESCRIPTION
       newroot  is  an  administrative command used to generate a
       new identity for a repository.  It is typically used  only
       after having repaired a repository.  After running newroot
       that repository will not be able to push to or  pull  from
       it's parent or any other related repository.

SEE ALSO
       bk help identity
       bk help clone
       bk help pull
       bk help push
       bk help terms

CATEGORY
       Repository
       Admin

BitMover, Inc               2002/10/31                          1
$
help://obscure
help://obscure.1
help://bk-obscure
help://bk-obscure.1

bk obscure(1)        BitKeeper User's Manual        bk obscure(1)

NAME
       bk obscure - obscure BitKeeper file comments and contents

SYNOPSIS
       bk obscure --I-know-this-destroys-my-tree

NOTICE
       This  command  will  destroy your repository, do it if and
       only if the repository in question is an unneeded copy.

DESCRIPTION
       The obscure command is typically used if you wish to  send
       someone  a  repository  for  performance  analysis  and/or
       debugging.  All data files have their  contents  and  com-
       ments  obscured.   The intent is that the obscuring of the
       repository data will result in a repository which has  the
       same  size, shape, number of deltas, number of changesets,
       etc., but with different data.

       The current method used to obscure the  data  is  to  sort
       each line of data alphabetically, i.e.,

           Please obscure me

       turns into

           ussromleeeecbaP

       The  obscuring is currently fairly simple and is theoreti-
       cally reversible with enough compute power so this is  not
       a means to encrypt a repository.  All commercial customers
       of BitMover are covered by  an  non-disclosure  clause  in
       their  commercial contract; the combination of that clause
       and the obfuscation are a reasonable way to  provide  Bit-
       Mover access to a repository.

SEE ALSO
       bk help admin

CATEGORY
       Admin

BitMover, Inc               2003/01/14                          1
$
help://openlogging
help://openlogging.1
help://bk-openlogging
help://bk-openlogging.1
help://Licensing/Open Logging
help://Licensing/openlogging

bk openlogging(1)    BitKeeper User's Manual    bk openlogging(1)

NAME
       bk openlogging - Open Logging explanation

DESCRIPTION
       Open  Logging  is the sending of metadata information to a
       centralized,  public   web   server   (http://www.openlog-
       ging.org), where it is sorted by project, date, and domain
       name,  and  published  so  that  others  may  follow  your
       progress.

       Open  Logging  is an easy way for all developers to follow
       each other's progress.  Because BitKeeper is a truly  dis-
       tributed  system,  without Open Logging, there would be no
       centralized place to go and see what  is  happening  to  a
       particular project.

WHAT IS SENT?
       => The ChangeSet file (comments and contents).
       => The  messages  which annotate modifications of the data
          (also known as check in  comments,  ChangeLog  entries,
          and/or log messages)
       => All  files  contained in the top level BitKeeper direc-
          tory in  a BitKeeper  repository,  in   particular  the
          BitKeeper/html  directory  and the BitKeeper/etc/config
          and BitKeeper/etc/logging_ok files.

WHAT IS NOT SENT?
       Your source code or other data managed by BitKeeper.

       Read that part again.  People frequently think  that  Open
       Logging means publishing their source code, but that isn't
       the case.

WHEN IS THE METADATA PUBLISHED?
       After  we  receive  confirmation  that  your  project   is
       intended for public viewing.

WHY DID WE DO THIS?
       The  original  reason  was  because  Alan  Cox, one of the
       developers of the Linux Kernel,  realized  that  BitKeeper
       was  really  distributed  and pointed out that there was a
       shortcoming with that model: there was no one place to  go
       to  see who was doing what.  We developed the Open Logging
       feature to address this shortcoming.

       The other reason is financial.  BitKeeper has a  dual  use
       model  which  allows  both  commercial and non-paying cus-
       tomers to use the same software.  Our  goal  is  that  the
       Open Source community can use BitKeeper by paying a  small
       amount of privacy but no money, and that  commercial  cus-
       tomers can use BitKeeper by paying money and keeping their
       privacy.  Open Logging is how this accomplished.

       If BitKeeper is used for free,  by  multiple  users,  then
       Open Logging is required, not optional.  This amounts to a
       loss of privacy,  which  should  not  be  an  unreasonable
       requirement for the intended users.  Since the Open Source
       community is developing software out in the open, with  no
       boundaries,  we felt that requiring the Open Logging would
       in general not be a burden, in fact, it would be of  bene-
       fit  in  that  there  is a centralized place to see change
       activity.

       Some people wish to use BitKeeper for free  and  also  not
       participate in Open Logging.  While we do have a policy of
       allowing this for certain educational or research institu-
       tions, in general, we do not allow this.  BitKeeper is not
       free software, it is paid for software, wherein people may
       choose  to  pay either in privacy or in money.  Commercial
       customers value their privacy, and Open Logging has essen-
       tially  quantified  that  value.   If we made Open Logging
       optional, commercial customers would have  little  motiva-
       tion to pay for BitKeeper.  It would also be unfair to the
       commercial customers, since they should get  something  of
       value that the non-paying users do not get.

       Some people dislike our model and urge us to consider tra-
       ditional Open Source models.  We  tried  that  found  them
       unworkable  for our product.  For our product space, there
       is no evidence that the traditional Open Source models are
       viable.   It is enlightening to note that Cyclic Software,
       the people who supported CVS, did less  than  $150,000  in
       their  best  year.   Rational does around $625,000,000 per
       year, that's the difference between optional  payment  and
       required payments.   BitKeeper cost millions of dollars to
       develop and will cost millions more to  maintain,  extend,
       and  support.   If  BitKeeper  generated money at the same
       rate that Cyclic did, it  would  be  20  years  before  we
       recovered the development costs to date.

CATEGORY
       Licensing

BitMover, Inc               2002/09/17                          1
$
help://parent
help://parent.1
help://bk-parent
help://bk-parent.1

bk parent(1)         BitKeeper User's Manual         bk parent(1)

NAME
       bk parent - show or set the parent repository

SYNOPSIS
       bk parent [-qpr] [<repository>]

DESCRIPTION
       The  parent  command  prints  or sets the default location
       where the bk pull/bk push commands get/put new work.

       With no argument, the  command  prints  the  parent  name.
       With an argument, it sets the parent to that argument.

       The  parent  is  automatically  set  when  a repository is
       cloned and will be named according to  the  access  method
       (see bk help url for more information).

OPTIONS
       -q     Run quietly.
       -p     Just print parent without other text. (for scripts)
       -r     Remove the parent pointer.

SEE ALSO
       bk help bkd
       bk help clone
       bk help pull
       bk help push
       bk help url

CATEGORY
       Repository

BitMover, Inc               2003/06/04                          1
$
help://path
help://path.1
help://bk-path
help://bk-path.1

bk path(1)           BitKeeper User's Manual           bk path(1)

NAME
       bk path - show the path that BK uses for all subprocesses

SYNOPSIS
       bk path

DESCRIPTION
       Mainly for debugging, bk path shows where BK will look for
       commands first.

CATEGORY
       Utility

BitMover, Inc               2002/03/11                          1
$
help://pending
help://pending.1
help://bk-pending
help://bk-pending.1

bk pending(1)        BitKeeper User's Manual        bk pending(1)

NAME
       bk pending - list deltas which need to be in a changeset

SYNOPSIS
       bk pending

DESCRIPTION
       The  pending  command shows changes that have been checked
       into your local work area, but  not  yet  committed  to  a
       changeset.   You have to commit to a changeset in order to
       send the change to other work areas.

       To see what needs to be committed to a change set, run:

           $ bk pending

SEE ALSO
       bk help commit
       bk help changes

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://prompt
help://prompt.1
help://bk-prompt
help://bk-prompt.1

bk prompt(1)         BitKeeper User's Manual         bk prompt(1)

NAME
       bk prompt - prompt a user with a message

SYNOPSIS
       bk prompt [opts] [message]

DESCRIPTION
       bk  prompt  is used to prompt a user with a message, get a
       positive or negative response, and exit accordingly.

       This interface may be used  for  either  command  line  or
       graphical   environments.   If  the  environment  variable
       BK_GUI is set,  then  the  graphical  tool  will  be  used
       instead of the command line version.  All of the BitKeeper
       GUI tools set this variable automatically  such  that  any
       call  to  bk  prompt  from inside the graphical tools will
       result in a graphical prompt, including the  execution  of
       any user supplied triggers.

       If the environment variable BK_MSG_GEOM is set, the graph-
       ical tool will use the value of this  variable  to  locate
       itself  on the screen.  The format of the variable must be
       in the for +x+y where "x" and "y" are screen  coordinates.
       bk  citool  sets this variable automatically such that the
       prompt will be at the same x/y location as the upper  left
       corner of citool.

OPTIONS
       -c          Only  for command line prompts, print the mes-
                   sage and exit 0.
       -e          Indicates that the prompt is an error message.
       -f<file>    Specifies  the  file contain the message to be
                   displayed.   Unless  this  option  or  the  -p
                   option is present, the last command line argu-
                   ment is must be present and  is  used  as  the
                   message.
       -g          Override  the BK_GUI variable and force a com-
                   mand line prompt if called in a graphical con-
                   text.
       -i          Indicates  that the prompt is an informational
                   message.
       -n<no>      If set, specifies the message for the label in
                   the  graphical tool which is to be used if the
                   user does not agree.  Default  is  "NO".   Not
                   used in command line context.
       -o          OK  only,  clears the default "no" value.  Not
                   used in command line context.
       -p<prog>    If set, specifies a program which,  when  run,
                   will produce the message contents.
       -t<title>   If  set,  specifies the title of the graphical
                   tool.  Default is  "BitKeeper  Message".   Not
                   used in command line context.
       -y<yes>     If set, specifies the message for the label in
                   the graphical tool, or the prompt in the  com-
                   mand  line  tool,  which  is to be used if the
                   user does agree.  Default is "OK".
       -w          Indicates that the prompt is  a  warning  mes-
                   sage.

EXIT STATUS
       Exits 0 if the user agreed, 1 if the user did not agree.

SEE ALSO
       bk help citool
       bk help triggers

CATEGORY
       File

BitMover, Inc               2002/09/30                          1
$
help://prs
help://prs.1
help://bk-prs
help://bk-prs.1

bk prs(1)            BitKeeper User's Manual            bk prs(1)

NAME
       bk prs - print revision summary

SYNOPSIS
       bk prs [-adDfhmMov] [-c<d>] [-C<r>] [-r<r>] [-x<r>] [<file> ... | -]

DESCRIPTION
       The bk prs command is used to extract revision history and
       or  metadata  from  a  file  or set of files.  The default
       behavior is to print a summary of each revision to each of
       the  specified  files.   There are options to restrict the
       set of revisions to print, a very  commonly  used  one  is
       -r<+>, which  restricts  the  set to the most recent revi-
       sion.

       With no options prs output defaults to giving  information
       on  all  revisions  of  all files in the present directory
       that are under BitKeeper control.  Output is given as fol-
       lows:  the name of the file and range of revisions is fol-
       lowed by a detailed account of  each  revision.   Revision
       number,  revision  date and time, user who made that revi-
       sion, what the relative path from root of repository is to
       that  file,  the  comments that go with that revision, and
       documents if the file has been renamed.

OPTIONS
       -a        Print info on all deltas, not just data  deltas.
       -c<date>  Cut-off dates.  See Range Specifications (below)
                 or bk help range for details.
       -C<rev>   Make the range be all revs  that  are  the  same
                 cset as <rev>.
       -d<spec>  Override  the default output format (see below).
       -D        Do  not  skip  files  in  the  BitKeeper/deleted
                 directory.
       -f        Print  the changes in forward (oldest to newest)
                 order.  The default is backward.
       -h        Suppress range header.
       -m        Print metadata, such as users and tags.
       -M        Do not  include  branch  deltas  which  are  not
                 merged.
       -n        Add a newline to each printed record.
       -o        Reverse  the  sense  of  which  deltas to print,
                 i.e., print all unspecified deltas.
       -r<rev>   Specify a revision, or part of a range.  (Or key
                 or  changeset  revision. See bk help terms under
                 'rev argument')
       -x<rev>   Exclude <rev> from  the  selection  in  -r.   If
                 <rev> is the special value 1st, then exclude the
                 first (earliest) revision in the selection (use-
                 ful when combined with the output of bk rset).
       -v        Complain  about SCCS files that do not match the
                 range.

       Note that either <rev> or <date> may be  a  symbolic  tag,
       which  implies  the  revision  or  date of the delta which
       matches the symbolic tag.

   RANGE SPECIFICATIONS
        -r+         prints the most recent delta
        -r1.3..1.6  prints all deltas 1.3 through 1.6
        -c9207..92  prints all deltas from July 1 '92 to  Dec  31
                    '92
        -c92..92    prints  all  deltas  from Jan 1 '92 to Dec 31
                    '92
        -c-1d       prints all deltas made in the last 24  hours;
                    similarly  for  s/m/h/d/M/Y  for seconds/min-
                    utes, hours, days, months, and years.

OUTPUT FORMAT
       The bk prs command has a default output format  which  can
       be  overridden.  There are many different pieces of infor-
       mation in an SCCS file and bk  prs  can  extract  most  of
       them.   To  extract  specific  information,  a dspec (data
       specification) string must be provided and should  contain
       keywords,  surrounded  by colons.  bk prs will expand each
       of these keywords in the output it produces.  To specify a
       TAB  character in the output, use \t; to specify a NEWLINE
       in the output, use \n.  An example dspec which prints  the
       SCCS    file    name    and   the   revision   number   is
       ':SFILE: :REV:\n'.

       In almost all cases, a trailing newline is not provided by
       any of the variables and one should be provided as needed.
       The list of variables which  currently  provide  one  are:
       COMMENTS, DEFAULT, PATH, and TAGS.

       Multi-line  variables  are printed with no spacing or new-
       lines between the lines by default.  You may insert spaces
       or newlines with a $each() loop like so

           bk prs -d'$each(:C:){:C:\n}' foo.c

       The list of variables with this behavior is: C, GB, FD.

   CONDITIONAL OUTPUT
       The dspec can produce output conditionally.  The following
       will print the default output  format  for  each  revision
       made by lm:

           bk prs -d'$if(:P:=lm){:DEFAULT:}' foo.c

   CONDITIONAL STATEMENTS
       $if(<expr>){<anything>}
               prints <anything> if <expr> is true.  If <expr> is
               a  field,  i.e.,  <:MERGE:>,  then  the  field  is
               expanded  and  returns  true  if  it  has a value.
               <anything> can contain  fields  as  normal,  i.e.,
               <:REV:>.
       $unless(<expr>){<anything>}
               prints <anything> if <expr> is false.

   CONDITIONAL OPERATORS
       strings <lhs>=<rhs> true if <lhs> is identical to <rhs>.
               <lhs>!=<rhs> true if <lhs> is different than
               <rhs>.
               Note: no spaces on either side of the operator.
       numbers <lhs> -eq <rhs> equality;
               <lhs> -ge <rhs> equal or greater than;
               <lhs> -gt <rhs> greater than;
               <lhs> -le <rhs> equal or less than;
               <lhs> -lt <rhs> less than.
               Note: spaces required on both sides of the opera-
               tor.

   ITERATIVE OUTPUT
       Some  fields, such as comments or tags, may be multi-line.
       To print a prefix in front of each  of  these  lines,  the
       idiom is:

           bk prs -d'$if(:C:){$each(:C:){C  (:C:)\n}}' foo.c

       The GB variable may not be used in a $each().

   KEYWORDS
       Some  fields  are  per file and are marked with F in the T
       column below; other fields are per delta  and  are  marked
       with  D.   In  the ``What is printed'' column, D refers to
       the specified delta, since some operations  work  relative
       to  D.  Some fields are compatible with ATT SCCS, they are
       typically the one and two letter fields;  BitKeeper fields
       tend to be longer.

       Name        T   What is printed
       ==========================================================
       AGE         D   D's age, i.e., seven hours, two weeks, etc.
       C           D   D's comments
       COMMENTS    D   comments portion of :DEFAULT:
       COMPRESSION D   D's compression (gzip|none)
       CSETKEY     D   delta key if D is at a changeset boundary
       CSETREV     D   revision of first cset boundary after D
       CSETFILE    F   key of the ChangeSet file for this file
       D           D   D's date as YY/MM/DD (years may be 4 digits)
       DANGLING    D   D's rev if & only if D is a dangling delta
       DEFAULT     D   default prs dspec
       DFB         F   default branch if set (similar to Ds)
       DI          D   D's includes/excludes as +I,I/-X,X (serials)
       DL          D   lines inserted/deleted/unchanged in D
       DOMAIN      D   the domain part of the hostname of D
       DP          D   the serial number of the parent of D
       DPN         D   the pathname of g.file as of D
       DS          D   the serial number of D
       DSUM        D   D's 16 bit unsigned checksum
       DSUMMARY    D   first line of :DEFAULT:
       DT          D   the type (D|R|M) of D
       Dd          D   day part of D's date as DD
       Dm          D   month part of D's date as MM
       DM          D   month part of D's date (Jan..Dec)
       Dn          D   serial numbers of D's includes, if any
       Ds          F   default branch or "none"
       Dt          D   D's data as :DT::I::D::T::P::DS::DP:
       Dx          D   serial numbers of D's excludes, if any
       Dy          D   year part of D's date as YY or YYYY
       ENC         F   current encoding scheme (ascii|binary)
       F           F   basename of the SCCS file
       FD          F   file descriptive text
       FLAGS       D   file flags as of D in words (HASH, YEAR4...)
       FSUM        F   16 bit unsigned checksum of the s.file
       FUDGE       D   timestamp fudge used make time monotonic
       G           F   basename of the gfile
       GB          D   file as of version D
       GCA         D   find the graph GCA for D's parents
       GCA2        D   find the set GCA for D's parents
       GFILE       F   pathname of the gfile
       HASHCOUNT   D   count of key/value pairs in D if & only if hash file
       HOST        D   hostname of D
       IMPORTER    D   name of the importer of D, if D was an emailed patch
       HTML_C      D   Comments in a form suitable for web pages.
       HTML_AGE    D   Age in a form suitable for web pages.
       I           D   D's revision number
       KEY         D   BitKeeper key of D
       KID         D   D's kid in the graph data structure
       L           D   the second field in D's rev (R.L.B.S)
       LD          D   lines deleted in D (%u)
       LI          D   lines inserted in D (%u)
       LU          D   lines unchanged in D (%u)
       Ld          D   lines deleted in D (%05u)
       Li          D   lines inserted in D (%05u)
       Lu          D   lines unchanged in D (%05u)
       MD5KEY      D   Crypto based BitKeeper key of D
       MERGE       D   D's rev if & only if D has a merge parent
       MGP         D   D's merge parent's serial number
       MODE        D   D's file modes as an octal (777)
       MPARENT     D   D's merge parent's revision
       N           D   Number of deltas, use instead of DS, DS may have gaps.
       NEXT        D   next entry after D in delta table
       P           D   programmer who made D; same as USER
       PARENT      D   D's parent's revision
       PATH        D   path portion of :DEFAULT:
       PN          D   pathname of s.file, same as SFILE
       PREV        D   previous entry before D in delta table
       R           D   the first field in D's rev (R.L.B.S)
       RANDOM      F   Random bits part of ROOTKEY
       RENAME      D   D's path if different from parent's path
       REV         D   same as I, D's revision
       RI          D   revision numbers of D's includes/excludes
       ROOTKEY     F   key of the 1.0 delta, file's internal name
       RWXMODE     D   D's file modes as ascii (-rwxrwxrwx)
       Rn          D   revision numbers of D's includes
       Rx          D   revision numbers of D's excludes
       S           D   last field in D's rev (R.L.B.S)
       SFILE       F   pathname of s.file
       SHORTKEY    D   D's key as user@host.domain|path|date
       SIBLINGS    D   rev sibling's pointer in D
       SPN         D   pathname of s.file as of D
       SYMLINK     D   value of D's symlink target
       T           D   time of D as HH:MM:SS
       TAG         D   any symbolic tag[s] associated with D
       TAGS        D   the symbolic tag portion of DEFAULT
       TIME_T      D   D's date as GMT time_t, TZ and Fudge adjusted
       TIP         D   D's rev if D is at the tip (TOT)
       TYPE        F   file type (SCCS | BitKeeper)
       TZ          D   offset from GMT as +/-HH:MM
       Th          D   hour part of D's date as HH
       Tm          D   minute part of D's date as MM
       Ts          D   seconds part of D's date as SS
       USER        D   programmer who made D; same as P
       UTC         D   D's timestamp as YYYYMMDDHHMMSS in GMT
       UTC-FUDGE   D   like UTC but without the date fudge
       VERSION     F   file format version
       W           D   what string
       X_FLAGS     D   D's per file flags as 0xFFFF
       Z           D   @(#)

BUGS
       Not  very  compatible  with ATT SCCS dspec; this should be
       considered a feature unless you are trying to maintain old
       scripts.

CATEGORY
       Common
       File

BitMover, Inc               2003/07/11                          1
$
help://pull
help://pull.1
help://bk-pull
help://bk-pull.1

bk pull(1)           BitKeeper User's Manual           bk pull(1)

NAME
       bk pull - updates the repository from its parent

SYNOPSIS
       bk  pull  [-iqRt] [-E<env>=<var>] [-z[<d>]] [-c<n>] [<par-
       ent>]

DESCRIPTION
       Pull updates a repository from its  parent.   Changes  are
       retrieved  and  automatically  applied,  if possible.  You
       will only be asked to resolve conflicts by hand if a  file
       has  overlapping  changes (changes where both repositories
       have touched the same line in the same file).

       Pull normally runs resolve, the  tool  which  applies  the
       pulled  changes, automatically.  Resolve will look at each
       change, make sure there are no  conflicts  that  it  can't
       merge, and apply the change.  You may have to (or want to)
       run resolve  manually.   If  you  do  not  want  automatic
       merges,  i.e., you want to diff them by hand, then use the
       -i option.  If resolve was run automatically and it  found
       conflicts,  the  changes have _not_ been applied; you will
       need to run an interactive resolve to merge and apply  the
       changes.

       You  can  override the default parent by specifying a dif-
       ferent one.  Doing so changes the parent for the  duration
       of this command only.

       If  you've pulled in error you may use bk unpull to remove
       the changesets introduced by the pull.

OPTIONS
       -c<n>  try to get the remote lock <n> times before  giving
              up (default forever).
       -E<env>=<val>
              Export environment variable to remote site.
       -i     Turn off automerge feature in resolve.
       -l     This  option  has  been  obsoleted  by  bk changes.
              Please see bk help changes (-R/-L options) for more
              information on getting repository differences.
       -n     This  option  has  been  obsoleted.   Please use bk
              changes.
       -q     Be quiet.
       -R     Do not run resolve at all.  You must run bk resolve
              later.
       -t     Pass  -t  to  resolve ( -t means do not use the GUI
              tools.)
       -z<d>  Do compression at level <d>, if possible, where <d>
              is  an integer value 0-9; default is -z6.  Compres-
              sion is possible when using ssh or the  BK  daemon,
              but not with rsh.

SEE ALSO
       bk help bkd
       bk help parent
       bk help push
       bk help changes
       bk help resolve
       bk help triggers
       bk help unpull

CATEGORY
       Repository
       Common

BitMover, Inc               2002/12/13                          1
$
help://push
help://push.1
help://bk-push
help://bk-push.1

bk push(1)           BitKeeper User's Manual           bk push(1)

NAME
       bk push - send local changes to the parent repository

SYNOPSIS
       bk  push  [-agqt] [-E<env>=<var>] [-z[<d>]] [-c<n>] [<par-
       ent>]

DESCRIPTION
       Push sends changes in the current repository back  to  its
       parent if and only if the current repository is a superset
       of the parent.  When the parent has changes not  found  in
       the  current  repository, push will fail and you will need
       to do a bk pull, merge those changes, and retry the  push.
       The idea is that the parent is typically a shared resource
       and should not be locked for merging.

       If there is no new work in the parent, then all changes in
       the child will be sent to the parent and auto-applied.

       You  can  override the default parent by specifying a dif-
       ferent one.  Doing so changes the parent for the  duration
       of this command only.

       You  can override the no-merge policy by going to the par-
       ent and doing a bk pull  and  specify  the  child  as  the
       bk parent.

OPTIONS
       -a     If  the parent is a superset of the current reposi-
              tory, then automatically pull that  work  into  the
              current repository.
       -c<n>  Try  to get the remote lock <n> times before giving
              up (default forever).
       -E<env>=<val>
              Export environment variable to remote site.
       -g     Allow the use  of  GUI  tools  during  the  resolve
              (unlike resolve -t).
       -l     This  option  has  been  obsoleted  by  bk changes.
              Please see bk help changes (-R/-L options) for more
              information on getting repository differences.
       -n     This  option  has  been  obsoleted.   Please use bk
              changes.
       -q     Run quietly.
       -t     Pass -t to resolve ( -t means do not  use  the  GUI
              tools)  during  the pull operation (requires -a and
              that the parent is a superset).
       -z<d>  Do compression at level <d>, if  possible;  default
              is  -z6.  Compression is possible when using ssh or
              the BK daemon, but not with rsh.

SEE ALSO
       bk help pull
       bk help parent
       bk help changes
       bk help resolve
       bk help triggers

CATEGORY
       Repository
       Common

BitMover, Inc               2002/12/13                          1
$
help://r2c
help://r2c.1
help://bk-r2c
help://bk-r2c.1

bk r2c(1)            BitKeeper User's Manual            bk r2c(1)

NAME
       bk r2c - convert file revision to ChangeSet revision

SYNOPSIS
       bk r2c -r<rev>  <file>

DESCRIPTION
       This  command takes a revision and a filename and converts
       the specified revision into the changeset  revision  which
       contains the file revision.

SEE ALSO
       bk help c2r

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://range
help://range.1
help://bk-range
help://bk-range.1
help://date
help://dates
help://ranges

bk range(1)          BitKeeper User's Manual          bk range(1)

NAME
       bk range - demo program to show ranges & dates

SYNOPSIS
       bk range [-q] [-c<range>|-r<rev>] [<file> ... | -]

DESCRIPTION
       Many commands can take ranges of deltas as an argument.  A
       range is a continuous sequence of  deltas,  such  as  1.1,
       1.2, 1.3, and 1.4.  Deltas may be specified by their revi-
       sion    number     (1.2),     delta     key     ('amy@bit-
       mover.com|man/man1/bk-terms.1|20020714011327|59990'),    a
       symbolic name (@tag), changeset rev (@1.33), or  changeset
       key                       (@'lm@disks.bitmover.com|Change-
       Set|20020912140445|17593').  (see bk help terms  for  more
       info)

       You may specify both end-points at once like so:

           bk prs -r1.1..1.5

       Revision  ranges  have  a  way to say "after" or "before".
       You may say

           -r1.3..1.7 to mean 1.3, 1.4, 1.5, 1.6, 1.7
           -r1.3,.1.7 to mean 1.4, 1.5, 1.6, 1.7
           -r1.3,,1.7 to mean 1.4, 1.5, 1.6

       The "," operator means "after" or "before"  the  specified
       revision.

       You may specify dates instead of revisions like so

           bk prs -c98..98

       If there are two dates, or there is a date and a revision,
       then the date  format  is  [+-]YYMMDDHHMMSS  with  missing
       fields  either  rounded  up  or rounded down.  Rounding is
       explicit if there is a "+" (rounds up) or  a  "-"  (rounds
       down) prefix on the date.  If there is no prefix, then the
       rounding is context sensitive.  If the date is  the  first
       date  i.e.,  the  starting point, then the date is rounded
       down.  If it is the second date in the range, then  it  is
       rounded  up.   So  98..98  is  the same as 980101000000 ..
       981231235959.

       Note: the mixing of dates and revisions is deprecated.

       If there is only one date specified, without  a  revision,
       then a very useful form of the date is to specify a recent
       period of time, such as

           bk prs -c-1d

       which will display the last 24  hours  worth  of  changes.
       This  works  the same way for Years/Months/days/hours/min-
       utes/seconds, i.e.,

           In the last year:   prs -c-1Y (or -1y)
           In the last month:  prs -c-1M
           In the last week:   prs -c-1W (or -1w)
           In the last day:    prs -c-1D (or -1d)
           In the last hour:   prs -c-1h
           In the last minute: prs -c-1m
           In the last second: prs -c-1s

       If you leave off the multiplier, 1 is assumed.

       While you may not build up specific dates as -1Y2m3d,  you
       can  specify  fractions,  i.e.,  to  get the last 6 months
       worth, try

           bk prs -c-.5Y

       Dates can also be in the form of symbolic tags  (ChangeSet
       file  only).   If  you  tagged  a changeset with Alpha and
       another changeset with Beta, you can type:

           bk prs -cAlpha..Beta

       Ranges need not include both endpoints.  If you wanted  to
       see everything from Beta forward, you could type:

           bk prs -cBeta..

       A single -r, because it is the first revision seen, rounds
       down and means 1.1.  To get the most  recent  delta,  type
       "-r+".

OPTIONS
       -c<range> Specify deltas by a date range
       -r<rev>   Specify deltas by revision number
       -q        run  quietly; default is to warn about all files
                 which do not match the range

SEE ALSO
       bk help annotate
       bk help diffs
       bk help get
       bk help prs

CATEGORY
       Overview
       File

BitMover, Inc               2002/09/12                          1
$
help://rcs2sccs
help://rcs2sccs.1
help://bk-rcs2sccs
help://bk-rcs2sccs.1

bk rcs2sccs(1)       BitKeeper User's Manual       bk rcs2sccs(1)

NAME
       bk  rcs2sccs  - converts a CVS or RCS repository to a Bit-
       Keeper repository

SYNOPSIS
       bk rcs2sccs [-hqu] [-c<tag>] [<file> ... | -]

DESCRIPTION
       This program is a conversion tool to convert an  RCS  file
       to an SCCS file.

OPTIONS
       -c<tag>  do not import any changes made after <tag>.
       -h       Verify after converting.
       -q       Show minimal status.
       -u       Run  the  RCS  file  through bk undos first; this
                will convert DOS style end of lines to Unix style
                end of lines.

CATEGORY
       Compat

BitMover, Inc               2002/09/17                          1
$
help://rcsparse
help://rcsparse.1
help://bk-rcsparse
help://bk-rcsparse.1

bk rcsparse(1)       BitKeeper User's Manual       bk rcsparse(1)

NAME
       bk rcsparse - test RCS parser

SYNOPSIS
       bk rcsparse [<file> ... | -]

DESCRIPTION
       This  command  simply runs the RCS parser on the specified
       files, checking to see if the  BitKeeper  RCS  parser  can
       handle the specified file.

SEE ALSO
       bk help rcs2sccs

CATEGORY
       Compat

BitMover, Inc               2002/09/17                          1
$
help://receive
help://receive.1
help://bk-receive
help://bk-receive.1

bk receive(1)        BitKeeper User's Manual        bk receive(1)

NAME
       bk receive - receive a BitKeeper patch

SYNOPSIS
       bk receive [<takepatch_options>] [<repository>]

DESCRIPTION
       Use  when  applying  a  BitKeeper  patch  you received via
       email.  You can take a BitKeeper patch and pipe the  whole
       email  message through bk receive. Headers and footers are
       stripped automatically.

       When someone sends you a patch with the following command:

           $ bk send -rbeta.. you@your.host.com

       You  will receive an email message which needs to be saved
       so you can feed it to the receive command:

           $ bk receive ~/mypackage < patch

       Many Unix email programs (pine, elm, etc) will  allow  you
       to pipe a message directly to a program. For example, when
       you are reading a message in pine, you  can  hit  the  '|'
       key,  and  you  will be prompted with a message asking you
       for a program name where the message should be piped.

       Remember that if you are getting the very first patch, you
       need to create a new repository by adding the "-i" option.
       BitKeeper does not create repositories by default.

       Specifying the repository is optional; if it  is  unspeci-
       fied,  receive tries to use the current working directory.

       Patches may be wrapped. If they are you will see something
       like

           ## Wrapped with uu ##

       near  the top of the patch.  BitKeeper knows how to unwrap
       patches which it wrapped.  We currently support only uuen-
       coded  wrappers,  but  it  is  trivial to create different
       ones, see bk help wrap for more information.

       Once a patch is run through bk receive, run bk resolve  to
       apply the changes.

OPTIONS
       All  options  are  sent  to  takepatch.   With no options,
       takepatch is completely silent.  If you want  to  see  the
       progress  reports  you  see  with  bk pull, add -vv to the
       options.

       -a     Apply the changes (call bk resolve.)
       -c     Do not accept conflicts with this patch.
       -i     Initial patch, create a new repository.
       -v     Verbose level, more is more verbose,  -vv  is  sug-
              gested.

SEE ALSO
       bk help send
       bk help takepatch
       bk help wrap

CATEGORY
       File

BitMover, Inc               2003/06/04                          1
$
help://relink
help://relink.1
help://bk-relink
help://bk-relink.1
help://hardlink

bk relink(1)         BitKeeper User's Manual         bk relink(1)

NAME
       bk relink - recreate broken hardlinks

SYNOPSIS
       bk relink [-q] <from> [<from2> <from3> ...]  <to>

DESCRIPTION
       The  relink command is used to conserve disk space.  It is
       typical for a single user to have many repositories,  each
       one representing a different work in progress.  It is also
       typical to use the -l option to bk clone  to  create  hard
       linked  repositories.   A  hardlinked repository uses much
       less space than a copied repository.  As files  are  modi-
       fied,  the  links  are broken.  As the same set of changes
       come into a  set  of  repositories,  the  links  could  be
       restored.  That is what the relink command does.

       The  relink  command looks at each SCCS file in the <from>
       repository and if it is the same as the same file  in  the
       <to> repository, it replaces the file in the <from> repos-
       itory with a hardlink to the file in the <to>  repository.

OPTIONS
       -q     Run quietly.

WARNINGS
       While hardlinked repositories are less disk intensive than
       replicated repositories, they are also more vulnerable  to
       disk or file system corruption.  It is advisable to always
       have at least one recent copy of a repository, rather than
       100% hardlinked repositories.

       It  is  possible to break all the links by recomputing the
       per file checksums:

           bk -r check -ac          # stop if this has errors
           bk -r admin -z

AVAILABILITY
       This command works only on Unix filesystems  and  only  if
       both repositories are in the same file system.

SEE ALSO
       bk help clone

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://renames
help://renames.1
help://bk-renames
help://bk-renames.1

bk renames(1)        BitKeeper User's Manual        bk renames(1)

NAME
       bk  renames -list file renames contained in a changeset or
       range of changesets

SYNOPSIS
       bk renames -r<rev>
       bk renames -r<rev,rev>

DESCRIPTION
       Show a listing of files which have been renamed as
       <oldname> -> <newname>

SEE ALSO
       bk help renametool

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://renametool
help://renametool.1
help://bk-renametool
help://bk-renametool.1

bk renametool(1)     BitKeeper User's Manual     bk renametool(1)

NAME
       bk renametool - graphical tool for finding renames

SYNOPSIS
       bk renametool < <filelist>

DESCRIPTION
       The  renametool command is a graphical interface for find-
       ing renames.  Renametool is invoked automatically  by  the
       import command when importing patches.

       The  purpose  of this tool is to maintain revision history
       across  file  renames.   A  repository  which  is  managed
       entirely by BitKeeper manages revision history across file
       renames. However, a system managed by BitKeeper, but which
       imports  traditional  patches  (i.e. diff -Nur) needs some
       help because patches do not directly record renames.

       Conceptually, a patch rename is seen as a deletion of  one
       file  and  a  creation  of  another  file.  When BitKeeper
       imports a patch, it detects the set of created and deleted
       files.   These  files are then fed to renametool where you
       are given the chance to  find  files  which  are  actually
       renames and record that information.

       When renametool starts up, you are looking at several text
       windows.  The game is that you need to match up  files  in
       the  create  window  with files in the delete window.  You
       can click on files in each window and the tool  will  show
       you  diffs.   When  you find two files which you think are
       the same, you can click the rename button to  rename  them
       and remove them from the lists.  The guess button tries to
       find matches for you, based on the basename of the  files.
       When  you  click  on  a  created file, the guess button is
       invoked once automatically.  You can click  on  the  guess
       button again to find the next potential match.

       After you have matched up every file there is to match up,
       click "create all" and  "delete  all"  to  finish  up  any
       stragglers, and then click apply.

BINDINGS
       Home        Scroll both diff windows to the top
       End         Scroll both diff windows to the bottom
       PageUp      Scroll both diff windows one screen up
       PageDown    Scroll both diff windows one screen down
       UpArrow     Scroll both diff windows one line up
       DownArrow   Scroll both diff windows one line down
       LeftArrow   Scroll both diff windows to the left
       RightArrow  Scroll both diff windows to the right

       These  bindings  are  the  same as clicking the associated
       buttons:

       space, n  Next diff
       a         Apply the actions in the Resolved files window
       C         Create all files in the Created files window
       c         Create the highlighted file in the Created files
                 window
       D         Delete all files in the Deleted files window
       d         Delete the highlighted file in the Deleted files
                 window
       g         Guess what the match might be
       h         Show history of  the  highlighted  file  in  the
                 Deleted files window
       p         Previous diff
       Control-q Quit without applying any changes
       r         Rename the two marked files
       u         Undo  the highlighted file in the Resolved files
                 window

SEE ALSO
       bk help config-gui
       bk help renames

CATEGORY
       GUI-tools
       File

BitMover, Inc               2002/09/17                          1
$
help://renumber
help://renumber.1
help://bk-renumber
help://bk-renumber.1

bk renumber(1)       BitKeeper User's Manual       bk renumber(1)

NAME
       bk renumber - regenerate the revision history numbers

SYNOPSIS
       bk renumber [-nq] [<file> ... | -]

DESCRIPTION
       This  command  exists primarily because Sun's Teamware had
       some bugs at one point and put nonsensical  revision  num-
       bers  in the s.files.  Lucky for Sun, SCCS does not really
       care about the revision numbers, it  maintains  the  graph
       structure  elsewhere.  This program uses that other infor-
       mation to start over and renumber the entire graph.

OPTIONS
       -n     do not do anything, dry run.
       -q     be quiet.

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://resolve
help://resolve.1
help://bk-resolve
help://bk-resolve.1

bk resolve(1)        BitKeeper User's Manual        bk resolve(1)

NAME
       bk resolve - merge and/or apply new work after a push or a
       pull

SYNOPSIS
       bk resolve [-aAcdqrtv1234] [-l<log>] [-m<merge>]  [-y<com-
       ment>] [<package_root>]

DESCRIPTION
       After  a  bk push, or bk pull, use resolve to merge and/or
       apply new work.  Resolve is automatically run  by  the  bk
       pull  and  bk push commands, but must be run again after a
       bk pull if there were conflicts which were not automerged.

       If  you want to preview the new changesets before merging,
       you can run bk csets and that will  run  csettool  on  the
       list  of  changes  (which  can  be  found  in  RESYNC/Bit-
       Keeper/etc/csets).

       Resolve traverses all of the files, prompting you  with  a
       list of files needing to be merged.  The following are the
       stages when resolving files:

       =>  create and rename conflicts
       =>  mode conflicts (file permissions)
       =>  file flag conflicts
       =>  file content conflicts

       In the future, we will be adding resolve  stages  for  the
       following:

       => symbol  "conflicts" (local and remote added the "alpha"
          symbol to different deltas)
       => descriptive text conflicts

       When there are no conflicts left  to  be  merged,  resolve
       groups any merge changes into a changeset and moves every-
       thing into your repository.

       While it is OK to quit out of resolve  without  finishing,
       the  repository will be locked and remain locked until you
       return to resolve and finish up the merge process.

       For detailed help on the merge process, see bk help merge.

OPTIONS
       -1        Run only pass 1; similarly for 2 3 and 4.
       -a        Automerge.  This will run a diff3-based merge of
                 all non-overlapping lines.  If there  are  over-
                 lapping  lines  in  merged files, the merge will
                 fail and the files will  not  be  resolved;  you
                 have  to run resolve again without the -a option
                 to finish the resolve.
       -A        Auto advance.  Normally, when doing an  interac-
                 tive  resolve,  the  resolution  is not complete
                 until you tell the system  to  commit  the  file
                 ("C"  in the content resolve menu).  This allows
                 for several false starts on a merge, you can use
                 "m"  to  merge,  decide that you didn't like it,
                 and use "m" again to try over.  If -A  is  used,
                 any sort of merge which completes is immediately
                 used and the resolver advances to the next file.
       -c        No conflicts.  This option tells resolve to com-
                 plete if and only if  new  non-conflicting  work
                 appears in the patch.
       -d        Debugging  (mainly  useful to BitKeeper develop-
                 ers).
       -l<log>   Log operations to <log> (or stderr  if  destina-
                 tion  specified).  This option is to provide for
                 audit trails; support is not yet complete.
       -m<merge> Use <merge> as the merge program called when you
                 press  "m"  in  the content resolver.  The merge
                 program takes four  file  arguments:  the  local
                 version of the file, the ancestor version of the
                 file, the remote version of the  file,  and  the
                 merged file.  It is the job of the merge program
                 to merge the changes into the merge file.
       -q        Be quiet.
       -r        Re-merge.  If you started to resolve, exited the
                 resolver,  and  then  restarted,  files  already
                 merged will be skipped.  This options allows you
                 to  re-merge  files  which need help, yet allows
                 you to skip past the ones you are happy with  by
                 hitting "C" in the resolve menu.
       -t        Text-only.  Enables  the text-based resolve menu
                 when doing the final  commit  instead  of  using
                 citool.
       -y<comment>
                 Use <comment> as the changeset check-in message.
                 This option is typically set by the calling pro-
                 gram,  i.e.,  bk pull.  If <comment> is not pre-
                 sent, resolve will  prompt  for  one  at  commit
                 time.

SEE ALSO
       bk help csets
       bk help merge
       bk help pull
       bk help push

CATEGORY
       Repository

BitMover, Inc               2003/06/04                          1
$
help://revtool
help://revtool.1
help://bk-revtool
help://bk-revtool.1
help://bk-sccstool.1
help://bk-sccstool
help://sccstool

bk revtool(1)        BitKeeper User's Manual        bk revtool(1)

NAME
       bk revtool - BitKeeper graphical history browser

SYNOPSIS
       bk  revtool [-G<rev_gca>  -l<rev_local>  -r<rev_remote>] [
       <filename>]

DESCRIPTION
       revtool is one of the primary tools used when  doing  code
       reviews,  tracking  down  bugs,  and  when  following  the
       progress of a project.

       revtool shows checkin comments and the graph history of  a
       project or file.  Revtool may be used to view any revision
       controlled file, including the  ChangeSet  file.  When  no
       filename is given, the entire package history is shown.

       Revtool has an upper window which shows the graph of revi-
       sion history and a lower window which can show either  the
       checkin comments or differences between versions.

HISTORY AND DIFFERENCES
       Upon  startup, the bottom window displays the last month's
       revision history for the file or project.

       To view the comments for just  one  revision,  left  click
       once on that revision in the graph.

       To  see  the differences between two revisions, left click
       the older revision and right click on the newer  revision.
       The  differences  will be displayed in the lower text win-
       dow.  You can right click on  another  revision  and  diff
       again.  The default diff format is -u (unified diffs).

       To see the contents of a file, double click the left mouse
       button on the revision node in the graph.  The text  shown
       for  the file is annotated with the user name and the lat-
       est revision that modified the line. The file text is gen-
       erated with the bk get -ump command.

       Once  the  annotated  file  listing is shown, you can then
       click on the text to view the checkin comments  associated
       with the chosen line. Double clicking on an annotated line
       brings up csettool and shows all of the other  files  that
       were  modified in the same changeset as the selected line.

       To get a side-by-side view of the differences, select  the
       two revisions and click on the "Diff tool" button.

CHANGESETS
       When  operating  on  the  ChangeSet  file, the behavior is
       slightly different.  Double-clicking a  revision  displays
       the  revision  history of the changeset and the history of
       the changes to each file contained in that changeset.

       If you click left/right on a range of changesets, you will
       get the history of the entire range of changesets.  To see
       the history and the differences in detail, you  can  click
       on  the  "View changeset" button to bring up the changeset
       browser tool, csettool.  Typical usage is  to  browse  the
       ChangeSet  file with revtool and drill down using bk cset-
       tool.

BINDINGS
       The scrollbars can be used to orient the  view  of  either
       window.   In  addition,  there  are the following keyboard
       bindings:

       LeftArrow         Scroll graph window left 1 line.
       RightArrow        Scroll graph window right 1 line.
       Shift-LeftArrow   Scroll graph window left 1 screen.
       Shift-RightArrow  Scroll graph window right 1 screen.
       Shift-UpArrow     Scroll graph window up 1 line.
       Shift-DownArrow   Scroll graph window down 1 line
       Shift-PageUp      Scroll graph window up 1 screen.
       Shift-PageDown    Scroll graph window down 1 screen.
       Shift-Home        Scroll graph window to the  first  revi-
                         sion.
       Shift-End         Scroll  graph  window  to the last revi-
                         sion.

       UpArrow           Scroll text window up 1 line (also  Con-
                         trol-y).
       DownArrow         Scroll  text  window  down  1 line (also
                         Control-e).
       PageUp            Scroll text window  up  1  screen  (also
                         Control-b).
       PageDown          Scroll  text  window down 1 screen (also
                         Control-f).
       Home              Scroll text window to the top.
       End               Scroll text window to the bottom.
       MouseWheel        Scroll the text window up or down.
       Shift-MouseWheel  Scroll the graph left or right.
       Control-MouseWheel
                         Scroll the graph up or down.

       s                 Show the raw SCCS file.

       c                 Show an annotated listing  of  all  ver-
                         sions  of  the  file.  The data shown is
                         the union of all lines ever added to the
                         file   in   any   version,  deletes  are
                         ignored.  Lines which were created at  a
                         particular  spot  in the file tend to be
                         grouped together.
       d                 Show   the   differences   between   the
                         selected item and its parent. If a graph
                         node is selected, the difference between
                         it and its parent are shown. However, if
                         a line within the annotated file listing
                         is  selected, the difference between the
                         selected revision  and  its  parent  are
                         shown.
       h                 Show  the  entire  revision history com-
                         ments.
       t                 Show only csets that have a tag  associ-
                         ated with them.
       /                 Search the text window for a string.
       ?                 Reverse search.
       n                 Search  for  the  next occurrence of the
                         string.
       Control-q         Quit revtool.

SEE ALSO
       bk help Basics-Overview
       bk help config-gui

CATEGORY
       GUI-tools
       Common
       File
       Repository

BitMover, Inc               2002/09/17                          1
$
help://rm
help://rm.1
help://bk-rm
help://bk-rm.1

bk rm(1)             BitKeeper User's Manual             bk rm(1)

NAME
       bk rm - remove BitKeeper file[s]

SYNOPSIS
       bk rm [-f] <file1> [<file> ...]

DESCRIPTION
       To delete a file, do this:

           $ bk rm foo.c

       Removing    the   file   actually   moves   it   to   Bit-
       Keeper/deleted/.del-foo.c~293843edf341df.    All    future
       operations will ignore the file unless you name it explic-
       itly, but it will still exist in the repository  and  will
       still  be  propagated  by  bk pull and/or bk push.  Edited
       files can not be deleted, you must check them in first.

       If you wish to obliterate all traces of a file, use the bk
       gone facility.

       To resurrect the file, use bk unrm.

           bk unrm foo.c

NOTES
       bk  rm will not remove directories, use bk rmdir for that.

       bk rm will refuse to remove  BitKeeper  metafiles  without
       the -f option (use of which is not recommended).

SEE ALSO
       bk help gone
       bk help rmdir
       bk help unrm

CATEGORY
       File

BitMover, Inc               2003/06/04                          1
$
help://rmdel
help://rmdel.1
help://bk-rmdel
help://bk-rmdel.1

bk rmdel(1)          BitKeeper User's Manual          bk rmdel(1)

NAME
       bk rmdel - remove a delta from a file

SYNOPSIS
       bk rmdel [-q] -r<rev>  <file>

DESCRIPTION
       bk  rmdel removes a delta from the revision history.  This
       command is here for ATT SCCS compatibility only, we prefer
       that you use stripdel.

OPTIONS
       -q       be quiet.
       -r<rev>  remove this revision.

SEE ALSO
       bk help stripdel

CATEGORY
       Compat

BitMover, Inc               2002/12/03                          1
$
help://rmdir
help://rmdir.1
help://bk-rmdir
help://bk-rmdir.1

bk rmdir(1)          BitKeeper User's Manual          bk rmdir(1)

NAME
       bk rmdir - remove a BitKeeper directory

SYNOPSIS
       bk rmdir <dir>

DESCRIPTION
       This  command  is  used  to delete entire subsections of a
       BitKeeper repository.

       To delete a directory called A, do this:

           $ bk rmdir A

       This will call bk rm on each of the files in that  subtree
       after verifying that there are no extra files, and no mod-
       ified files in that subtree.

       The files are recoverable, none of the BitKeeper  commands
       actually remove the files, they are just moved to the Bit-
       Keeper/deleted directory.

SEE ALSO
       bk help mvdir
       bk help rm

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://rmgone
help://rmgone.1
help://bk-rmgone
help://bk-rmgone.1

bk rmgone(1)         BitKeeper User's Manual         bk rmgone(1)

NAME
       bk rmgone - remove files having keys in the gone file

SYNOPSIS
       bk rmgone [<-n>] [<-p>] [<-q>]

DESCRIPTION
       The  rmgone  command  removes  the s-files and any g-files
       associated with the keys listed in the gone file.

       S-files may be removed and their keys added  to  the  gone
       file with the gone command.  When the ChangeSet containing
       changes to the gone file  is  pushed/pulled  from  another
       repository  BitKeeper  will issue warnings indicating that
       you have s-files matching things in the  gone  file.   The
       rmgone command may be used to remove the files in question
       and thus permanently stop the warnings.

OPTIONS
       -n Dry run.  Just  print  out  the  files  that  would  be
          removed.
       -p Prompt  before removing each file.  Entering 'y' or 'Y'
          will delete the file.
       -q Run quietly.

WARNING
       This command cannot be undone.

SEE ALSO
       bk help gone

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://root
help://root.1
help://bk-root
help://bk-root.1

bk root(1)           BitKeeper User's Manual           bk root(1)

NAME
       bk  root  - print the path name to the root of the reposi-
       tory

SYNOPSIS
       bk root [<directory> | <file>]

DESCRIPTION
       This command prints the full pathname to the root  of  the
       repository.  The following commands are equivalent:

           bk root
           bk -R pwd

       If  a  directory or file is specified, bk root will try to
       find the project root of that file or directory.

CATEGORY
       Admin

BitMover, Inc               2002/09/17                          1
$
help://rset
help://rset.1
help://bk-rset
help://bk-rset.1

bk rset(1)           BitKeeper User's Manual           bk rset(1)

NAME
       bk rset - generate a ``release set''

SYNOPSIS
       bk rset [-ah] -r<rev>
       bk rset [-ah] -l<rev>

DESCRIPTION
       bk  rset  is used to generate a view of either the changes
       contained in a particular changeset, the changes contained
       in  a  sequence  of  changesets,  or  a view of the entire
       repository as of a particular changeset.

       To see the changes made by a particular change, try

           $ bk rset -r1.201
           ChangeSet|1.200..1.201
           src/gui/fmtool.tcl|1.17..1.21

       Note: the first revision listed in the 1.17..1.21  is  the
       revision of the last delta created before the start of the
       specified changeset.  It is done this way so that programs
       which  parse  this  output  know  where the last changeset
       stopped.  It is also worth noting that  BitKeeper  change-
       sets  can  contain  multiple  revisions  to the same file,
       which is why the end of the last changeset and  the  start
       of the requested changeset is listed in the output.

       This  program  is not normally run by users, the bk export
       command uses bk rset combined with bk gnupatch to generate
       traditional patches.

OPTIONS
       -a        show  deleted  files  which  are  normally  sur-
                 pressed.
       -h        show the ``historic'' paths of the file as  well
                 as the current path.  This makes the output look
                 like <current>@<starting>@<ending>@<rev>..<rev>.
                 The output has three file names, current, start-
                 ing, and ending, corresponding  to  the  current
                 pathname,  the pathname of the file at the start
                 of the first changeset listed, and the  pathname
                 of the file at the end of the last changeset.
       -l<rev>   list  the  entire  repository  as  of  changeset
                 <rev>.  Mutually exclusive with -r.
       -r<rev>   specify the changeset revision  to  show.   This
                 will  show all the files changed in this change-
                 set.
       -r<r1,r2> specify the changeset range to show.  This  will
                 show  all the files changed after changeset <r1>
                 up to and including changeset <r2>.

SEE ALSO
       bk help export
       bk help gnupatch
       bk help prs
       diff(1)
       patch(1)

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://sane
help://sane.1
help://bk-sane
help://bk-sane.1

bk sane(1)           BitKeeper User's Manual           bk sane(1)

NAME
       bk sane - check for various BitKeeper requirements

SYNOPSIS
       bk sane

DESCRIPTION
       Run this command from within a repository to check whether
       the repository is configured correctly.  Sane checks for a
       valid  hostname, username, permissions on various metadata
       directories, and the ability  to  lock  the  idcache.   If
       everything is sane, the command exits with a 0 exit status
       and no output.  If there are problems,  a  detailed  error
       message  is displayed on stderr and a non-zero exit status
       is returned.

       When submitting bugreports, please include the  output  of
       this command.

SEE ALSO
       bk help sendbug

CATEGORY
       Admin

BitMover, Inc               2002/09/17                          1
$
help://sccslog
help://sccslog.1
help://bk-sccslog
help://bk-sccslog.1

bk sccslog(1)        BitKeeper User's Manual        bk sccslog(1)

NAME
       bk sccslog - list deltas sorted by date across all files

SYNOPSIS
       bk   sccslog   [-ADfnpsv]   [-c<dates>]   [-i<d>]  [-r<r>]
       [<file> ... | -]

DESCRIPTION
       sccslog is used to get a time sorted  listing  of  changes
       over all of the specified or implied files.  It is similar
       to bk prs, with the difference  being  that  prs  respects
       file  boundaries, i.e., lists all changes in a file before
       going on, but sccslog sorts the changes  and  prints  each
       change  in  time  order,  ignoring file boundaries.  It is
       useful to go to a directory and type:

           bk sccslog -c-1M

       to see what has happened in all of the files there in  the
       last month.

       By default, bk sccslog runs the output through your pager,
       which can be controlled with $PAGER.

OPTIONS
       -A        Select all uncommitted deltas in a file.
       -c<dates> Cut off dates.  See Range Specifications (below)
                 or bk help range for details.
       -D        factor  out  duplicate  comments  and  print the
                 results as

                     libdiff.c, gnupatch.c:
                       add --minimal to calls to diff(1).

       -d<dspec> Format output according to the  data  specifica-
                 tion  string.   See  bk  prs  documentation  for
                 information on data specifications.
       -f        print the changes in forwards order  (oldest  to
                 newest).  The default is backwards order.
       -n        add  a newline to each printed record (sometimes
                 useful with -d).
       -p        Show basenames instead of full pathnames.
       -r<r>     Specify a revision or a range.
       -s        produce sorted output  for  post  processing  in
                 ``filename|rev'' format.
       -v        Be verbose about errors and processing.

       Note  that  <date> may be a symbol, which implies the date
       of the delta which matches the symbol.

       Range or date specifications:

       -r+            prints the most recent delta
       -r1.3..1.6     prints all deltas 1.3 through 1.6
       -c9207..92     prints all deltas from July 1 '92 to Dec 31
                      '92
       -c92..92       prints  all deltas from Jan 1 '92 to Dec 31
                      '92

CATEGORY
       File

SEE ALSO
       bk help changes
       bk help prs
       bk help range

BitMover, Inc               2002/09/17                          1
$
help://send
help://send.1
help://bk-send
help://bk-send.1

bk send(1)           BitKeeper User's Manual           bk send(1)

NAME
       bk send - send a BitKeeper patch

SYNOPSIS
       bk send [-dfq] [-w[<wr>]] [-r<revs>] [-u<URL>] <u@h.ca>| -

DESCRIPTION
       The send interface may be used  to  send  changes  through
       electronic  mail.   In general, the bk push/bk pull inter-
       faces are the easiest way to keep  two  repositories  syn-
       chronized, but bk send requires only an email transport.

       To send the whole repository, do:

           $ bk send user@host.com

       BitKeeper  will  generate  the (huge) patch and mail it to
       user@host.com.

       If you happen to know that you want  to  send  a  specific
       change  (and  you  know  that the other repository has the
       changes leading up to the change you want  to  send),  you
       can do this:

           $ bk send -rbeta.. user@host.com

       or

           $ bk send -r1.10.. user@host.com

       Send   remembers  the  changesets  it  has  sent  in  Bit-
       Keeper/log/send-<address>   where   <address>   is    like
       user@host.com.   When  you don't specify a list of change-
       sets to send, "send" will look in the log  file  and  send
       only the new changesets.  So the easiest thing to do is to
       always use the same email address and just say:

           $ bk send user@host.com

       If you lose the log file and you want to seed it with  the
       changes  you  know  have been sent, the command to do that
       is:

           $ cd BitKeeper/log
           $ bk prs -h -r<revs> -d:KEY: ChangeSet > send-user@host.com

       An alternative to the log file approach, which may only be
       used if you have connectivity to the remote repository, is
       to talk to the remote repository to find out what needs to
       be sent.  The following will send all the changes you have
       that the remote does not have:

           $ bk send -ubk://thunk.org:5000 tytso@mit.edu

       You may wrap patches so that they do not get corrupted  by
       mailers.   We  currently  support  wrapping with uuencode.
       The following (contrived) command sends  a  wrapped  patch
       and applies it in /tmp/foo (which must exist):

           $ bk send -wuu -r..1.5 - | bk receive /tmp/foo

OPTIONS
       -d        Prepend  the  patch with unified diffs.  This is
                 because some people like looking at the diffs to
                 decide if they want the patch or not.
       -f        send  the  patch  even if BitKeeper believes the
                 remote repository is up to date.
       -q        Be quiet.
       -r<revs>  Specify the list of changesets to send.
       -u<URL>   Instead of consulting the send log,  connect  to
                 the remote repository specified by the URL, fig-
                 ure out what needs to be sent, and  send  it  to
                 the specified email address.
       -w<WR>    Wrap the patch with <WR> before sending it.  The
                 current set of wrappers are:
                 b64wrap - base 64 encoding
                 gzip_b64wrap - gzip and base 64 encoding
                 gzip_uuwrap - gzip and uuencode
                 uuwrap - uuencode

SEE ALSO
       bk help ranges
       bk help receive
       bk help wrap

CATEGORY
       File

BitMover, Inc               2003/06/04                          1
$
help://sendbug
help://sendbug.1
help://bk-sendbug
help://bk-sendbug.1

bk sendbug(1)        BitKeeper User's Manual        bk sendbug(1)

NAME
       bk sendbug - file a bug report

SYNOPSIS
       bk sendbug [-t] [<email@host>]

DESCRIPTION
       File a bug or request for enhancement (RFE) against a pro-
       ject.

       The default behavior is to display the  graphical  version
       of  sendbug  when  the DISPLAY environment variable is set
       (UNIX) or if it is run on a Windows operating system.   To
       use  a text editor rather than the gui, use the -t option.

       If email address is specified, the bug  will  be  sent  to
       that email address.

       This  command  should  be used to file a bug report rather
       then sending mail to one of the developers.

       The BitKeeper bug database is  online  at  http://www.bit-
       keeper.com/bugs

       The  bug database is also available via email, consult the
       web page for more information.

OPTIONS
       -t     Use a text editor rather than the default graphical
              tool to fill out a bug report.

EXAMPLE
       An example text template looks like this:

       Bug/RFE:
               [bug is obvious, RFE is request for enhancement]

       Severity:
               [5 - no big deal, 1 - can't use BitKeeper until this is fixed]

       Priority:
               [5 - fix whenever, 1 - fix RIGHT NOW]

       Program:
               [cset, co, delta, etc.  If you know which caused the problem]

       Release:
               beta10-pre1

       OS:
               [Linux, IRIX, NT, etc]
       Etc.

       and the filled out report should look like this (note that
       the data goes after the tags, not on the same line):

       Bug/RFE:
               bug

       Severity:
               1

       Priority:
               1

       Program:
               sendbug

       Release:
               pre-2.0-2

       OS:
               All
       Etc.

CATEGORY
       Admin

BitMover, Inc               2002/09/17                          1
$
help://set
help://set.1
help://bk-set
help://bk-set.1

bk set(1)            BitKeeper User's Manual            bk set(1)

NAME
       bk set - set operations

SYNOPSIS
       bk set [-adeklnosx] [ -r<rev>] [-t[<type>]] [file]

DESCRIPTION
       The  bk set command performs set operations on a BitKeeper
       file.  This command provides the following set operations:
       union,  intersection, difference and symmetric difference.
       It also provides the member function (is  this  element  a
       member of the set?) as well as the list function (list all
       sets which contain this member).

       If the file is not specified, it defaults to the ChangeSet
       file.

OUTPUT OPTIONS
       The  default  output is a list of revisions, one per line.
       The output may be restricted to only tagged revisions, and
       may  be  forced  into  revision, tag, or key format.  Note
       that only the ChangeSet file may have  tags,  which  means
       that  combining  tag output format with a regular file has
       unexpected results.

       -k     list all answers as keys, not as tags or revisions.
       -n     prefix  each  output  line with the filename, i.e.,
              ChangeSet|1.3, so that the output  may  be  fed  to
              other programs, such as bk prs.
       -t     list all answers as tags where possible, else revi-
              sions.
       -tt    list only those answers which are tagged  and  list
              those as the tag not the revision.
       -tr    list  only  those answers which are tagged but list
              those as revisions.
       -tk    list only those answers which are tagged  but  list
              those as keys.

SPECIFYING SETS
       If  a revision is specified for a set argument, the set is
       the set of deltas which make up that revision.  For  exam-
       ple,  in  a  simple history without branches, revision 1.5
       implies the set {1.1, 1.2, 1.3, 1.4, 1.5}.  A revision may
       be  specified  as a dotted number pair, as a symbolic tag,
       or as a BitKeeper key.  It may also be specified as a "-",
       for  the  second set only, in which case it expects a list
       of revisions (or keys) on stdin, one per line.

SET OPERATIONS
   UNION (A | B)
       bk set [output opts] -o <set A> <set B> [file]

       The union operation, familiar to programmers as a "bitwise
       or", lists all members which occur in either set.

   INTERSECTION (A & B)
       bk  set [output opts] -a <set A> <set B> [file] The inter-
       section operator, familiar to programmers  as  a  "bitwise
       and", lists all members which occur in both sets.

   DIFFERENCE (~A & B)
       bk set [output opts] -d <set A> <set B> [file]

       The  difference  operator lists all members in set B which
       are not in set A.  This is the  most  useful  of  the  set
       operations, see the examples below.

   SYMMETRIC DIFFERENCE (A ^ B)
       bk set [output opts] -x <set A> <set B> [file]

       The symmetric difference operator, familiar to programmers
       as an "exclusive or", lists all  members  which  occur  in
       only one of the two sets.

   ELEMENT
       bk set [output opts] -e -r<rev><set B> [file]

       The  element  operator  treats the specified revision as a
       single element, not as an implied set, and lists the  ele-
       ment if it is in the set.

   LIST
       bk set -l -r<rev>[file]

       The  list operator treats the specified revision as a sin-
       gle element, not as an implied set, and lists all sets (as
       revisions) which contain the element as part of their set.
       It is typically used to see if a bug fix is in a  particu-
       lar  release.   If  the changeset has been excluded from a
       later changeset, the later changeset and its'  descendants
       will not be listed.

   SET
       bk set -s -r<rev>[file]

       The  set  operator treats the specified revision as a set,
       and lists all elements of that set.

EXAMPLES
       A good use of this command is the  generation  of  release
       notes.   To do so, pick the starting and ending points and
       do this:

           $ bk set -d -rbk-2.0 -rbk-2.0.1 | bk changes -
           ChangeSet@1.1425.5.19, 2001-10-12 15:18:06, lm@work
             utils.c:
               Remove debugging.
               Sleep 50 milliseconds when waiting for the lock.

           ChangeSet@1.1425.5.20, 2001-10-15 15:57:42, lm@disks
             A weekend's worth of testing of locking over NFS
             turned into this cset.

           ChangeSet@1.1425.5.21, 2001-10-16 08:35:26, lm@disks
             The cset lock was too fine grained.
             This is a short term fix,
             the longer term fix is the per file locking
             Andrew is working on.
             TAG: bk-2.0.1

       To see the tagged releases which contain bk-2.0.3:

           $ bk set -l -tt -rbk-2.0.3
           bk-2.0.3
           bk-2.0.4
           bk-2.0.4b
           bk-2.1.2
           bk-2.1.3
           bk-3par_merge
           bk-3par_merge2

SEE ALSO
       bk help changes
       bk help prs

CATEGORY
       Utility

BitMover, Inc               2002/03/18                          1
$
help://setup
help://setup.1
help://bk-setup
help://bk-setup.1

bk setup(1)          BitKeeper User's Manual          bk setup(1)

NAME
       bk setup - create a new BitKeeper package repository

SYNOPSIS
       bk setup [-f] [-c[<config_file>]] <directory>

DESCRIPTION
       Before setting up a BitKeeper repository, you need to read
       the license.  BitKeeper is not  traditional  Open  Source.
       Please  see  bk  help license and make sure that you agree
       with the terms.

       To set up a BitKeeper package, you need to create and pop-
       ulate  a  package tree.  The setup command will create the
       package tree.  That is, it creates a top  level  directory
       with  the same name as the repository name as well as sev-
       eral files and directories that are used  for  administra-
       tive purposes.

       The setup command will prompt you for a description of the
       package. In addition, you will be asked to edit a configu-
       ration  file containing information about your new reposi-
       tory.

       A system wide  default  config  file  may  be  created  in
       /etc/BitKeeper/etc/config.template.    If   this  file  is
       detected when bk setup is run, without the -c  option,  it
       will  be  used  as  the  default BitKeeper/etc/config file
       automatically.

OPTIONS
       -c[<config_file>] Use <config_file> as  the  configuration
                         file to setup the repository.
       -f                Don't ask for confirmation.

EXAMPLES
       When  creating  a  repository called "mypackage", you type
       the following command:

           $ bk setup ~/mypackage

       The following shows the directory structure of a new pack-
       age.

       mypackage/
          ChangeSet        Index  of  all  changes to the reposi-
                           tory.
          BitKeeper/       Directory where  administrative  files
                           are kept.
                 etc/      Config  files,  in  the future, policy
                           files.
                 log/      Mail and command logs, parent pointer.
                 deleted/  Deleted  files are archived here (like
                           CVS Attic).
                 tmp/      Scratch area.
                 readers/  Transient directory for reader  locks.
                 writer/   Transient directory for writer lock.
                 triggers/ Executable   trigger  programs  stored
                           here.
                 linked/   Directory for keeping track of  linked
                           files (i.e.  two files which are logi-
                           cally one).

       Once the repository is created, you should make a  hierar-
       chy  to  store  your  source files. For example, you could
       create the following tree:

       mypackage/
             src/   source code
             man/   manual pages
             doc/   user guides, papers, docs...

       At this point, if you are  creating  a  new  package  from
       scratch,  cd  to ~/mypackage/src and start creating files.
       See bk help Basics-Overview and bk  help  Howto-setup  for
       more info.

       If  you have an existing set of files that you want to add
       to the repository, see bk import.

SEE ALSO
       bk help Howto
       bk help Howto-setup
       bk help import
       bk help config-etc

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://setuptool
help://setuptool.1
help://bk-setuptool
help://bk-setuptool.1

bk setuptool(1)      BitKeeper User's Manual      bk setuptool(1)

NAME
       bk  setuptool - graphical front-end to the BitKeeper setup
       command

SYNOPSIS
       bk setuptool [<directory>]

DESCRIPTION
       The setuptool command is a graphical interface for  creat-
       ing new BitKeeper repositories.

       The  purpose  of  the tool is to help you enter all of the
       information needed to create a repository by stepping  you
       through a series of input forms and prompts.

       Before  you  can  create  a  repository  you must read and
       accept  the  appropriate  BitKeeper  license.  The   exact
       license you must accept depends on the type of the reposi-
       tory you are creating.  Setuptool will prompt you for  the
       type of repository and give you an opportunity to read and
       accept the license.  If  you  choose  to  not  accept  the
       license you will not be able to create the repository. See
       bk help setup, bk help licensing and bk  help  openlogging
       for more information.

       After  you  have  accepted  a particular license, the next
       time you run setuptool you will not be required to  accept
       the same license again.

       Once  you have defined the type of repository and accepted
       the appropriate license you will  be  prompted  for  addi-
       tional  information that will be stored in the config file
       for the repository. Different types of  repositories  will
       require  slightly  different  sets of data. For example, a
       repository that uses a  commercial  license  will  require
       that you enter the license key and signatures.

       After  all  information  has  been entered you will have a
       chance to review the information that will be put into the
       config  file  before  the  repository is created. When the
       repository is created, the config file is stored as a nor-
       mal  revision  controlled file so that you may go back and
       edit the file at a later date.

       If you will be creating several repositories that will use
       the same configuration information (such as contact infor-
       mation) you may create a system-wide default  config  file
       in  /etc/BitKeeper/etc/config.template.  This has the same
       format as a regular config file.  Setuptool will look  for
       this  file  and, if found, use the data in the file to set
       the default values when creating a new repository.

LICENSE KEYS
       If you have a commercial license key you may enter  it  by
       hand when prompted.  Setuptool also allows you to load the
       license key and signatures from a file. This is  the  most
       accurate way to enter the licensing information.

       This  file  may have other information besides the license
       key as long as the key and signatures are embedded in  the
       text  somewhere.  So, for example, if you receive an email
       that includes your license key you can save that email  to
       a file and select that file from within setuptool.

EXAMPLES
       To create a repostory named /projects/helloworld, you type
       the following command:

           bk setuptool /projects/helloworld

       This will prompt you for information to place in the  con-
       fig  file  and  then  create a project hierarchy rooted at
       /projects/helloworld. The config file with  the  data  you
       entered is in /projects/helloworld/BitKeeper/etc/config.

       You  do not need to include the name of a directory on the
       command line. If  you  do  not  include  it  you  will  be
       required  to  enter a name during one of the configuration
       steps.

BINDINGS
       Enter          Perform the default action, which is either
                      to  go  to  the  next  step,  or create the
                      repository if on the final step.

       Tab            Moves between input fields.

       You may also use your system's cut, copy and paste keys in
       the input fields.

SEE ALSO
       bk help config-etc
       bk help setup
       bk help openlogging
       bk help licensing

BitMover, Inc               2002/09/17                          1
$
help://sfiles
help://sfiles.1
help://bk-sfiles
help://bk-sfiles.1

bk sfiles(1)         BitKeeper User's Manual         bk sfiles(1)

NAME
       bk sfiles - generates lists of revision control files

SYNOPSIS
       bk [-r] sfiles [-acdDeEgijlnrSuUvx] [-o<file>] [-p[<A|C>]]
       [<dirs>]

DESCRIPTION
       bk sfiles is used to generate lists  of  revision  control
       files,  files  related to revision control files, directo-
       ries related (or not) to revision  control  files,  and/or
       files  not under revision control.  In other words, if you
       need a list of files, you've come to the right place.

       bk sfiles without any arguments finds all  s.files  in  or
       below   the  current  working  directory.   This  is  what
       bk -r <command> uses to generate the list of files to feed
       to <command>.

       If a directory and/or file list is specified, then each of
       the items in the list is processed; directories  are  pro-
       cessed recursively.

OPTIONS
       When  examining the options, bear in mind that if you want
       a list of files in one particular state,  do  not  combine
       the  option  which specifies that state with options which
       specify different states; you'll get one  list  with  both
       kinds of files if you do.

       If  you  want  a  one  pass  with different sorts of files
       listed, look at the -e/E/i/v options.

       -a       examine  all  files,  even  if  listed  in   Bit-
                Keeper/etc/ignore.
       -c       List changed files (locked and modified).
       -d       List  directories  under  BitKeeper control (SCCS
                subdir exists).
       -D       List directories with no (or empty) SCCS subdirs.
       -e       shorthand for -jluvx
       -E       shorthand for -cjlnuvxp
       -g       List the gfile name, not the sfile name.
       -i       shorthand  for -cjlvxp aka the interesting state.
       -j       List junk files, i.e., files in SCCS  subdirecto-
                ries which are not metadata.
       -l       List locked files (p.file and/or z.file).
       -n       list  s.files  that  are not in the correct loca-
                tion.  (Must be run from repository root,  bk  -r
                sfiles -n.)
       -o<file> send output to <file> and progress information to
                stdout.
       -p[<A|C>]
                list files with pending deltas.  If -pC then list
                leaves  which  are not in a changeset as file|1.3
                If -pA, that implies -pC,  and  lists  all  revi-
                sions, not just the tip.
       -P       Like  -p,  but  don't  trust the d.file.  Use the
                s.file for verification and create or delete  the
                d.file to match the status of the s.file.
       -S       produce  a  summary  listing only, typically com-
                bined with -E.
       -u       List unlocked files.
       -U       list user files only, skipping all files  in  the
                BitKeeper/  subdirectory as well as the ChangeSet
                file.
       -v       Prefix the  output  with  information  about  the
                state  of  the s.file.  The information is in a 4
                character field, followed by a space,  then  fol-
                lowed  by  the filename.  Each of the columns are
                described below:
                l???   the file is locked
                u???   the file is unlocked
                jjjj   the file is junk
                xxxx   the file is an extra
                ?c??   the file is modified (changed)
                ??p?   the file has pending deltas
       -x       List files which have no revision control  files.

NOTES
       bk  sfiles  will not descend into directories containing a
       .bk_skip file.  This allows you to prune  entire  subtrees
       from processing.

       Files  under  BitKeeper/{log,readers,writers}/  are always
       ignored.

       Revision  control  files  must  look  like  SCCS/s.*,  not
       foo/bar/blech/s.*

BUGS
       The  -d/-D  options  do not combine with the other listing
       options, they are done by a different program.  This  will
       be fixed soon.

SEE ALSO
       bk help history
       bk help ignore
       bk help new

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://sfio
help://sfio.1
help://bk-sfio
help://bk-sfio.1

bk sfio(1)           BitKeeper User's Manual           bk sfio(1)

NAME
       bk sfio - BitKeeper file archiver

SYNOPSIS
       bk sfio [-qm] -i < <archive.sfio>
       bk sfio [-m] -p < <archive.sfio>
       bk sfio [-qm] -o < <filelist>

DESCRIPTION
       The  bk  sfio  command  is  similar to cpio(1).  It exists
       because we were unable to find a single CPIO format  which
       was portable across all of our supported platforms.

       bk  sfio  is used to transfer data during bk import and bk
       clone commands.

       There are three ways to run sfio, as  listed  above.   The
       first  creates files from an archive, the second lists the
       contents of an archive, and the third creates  an  archive
       from the specified list of files.

OPTIONS
       -i     Extract all files from the archive.
       -m     Transfer file modes (default not to do so).  If the
              archive  was  created  with  -m  then  it  must  be
              extracted  with  -m.   We  will not turn this on by
              default, transferring the file modes is not  always
              the correct answer so we force it to be explicit.
       -o     Create an archive.
       -p     List contents of an archive.
       -q     Quiet  mode,  when  combined  with  the  create  or
              extract, does not list files as they are  added  or
              extracted.

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://smerge
help://smerge.1
help://bk-smerge
help://bk-smerge.1

bk smerge(1)         BitKeeper User's Manual         bk smerge(1)

NAME
       bk smerge - smart text-based 3-way file merge

SYNOPSIS
       bk   smerge   [-2efghn]  [-A<n>]  [-a<n>]  <file>  <local>
       <remote>

DESCRIPTION
       The bk smerge command compares the three versions  of  the
       file and identifies all changes by either the local or the
       remote version of the file compared to the greatest common
       ancestor (gca).  These groups of changes are known as con-
       flict regions and are bounded by a line that is  identical
       in  all  three  versions  at the beginning of the conflict
       region and at the end of the conflict  region.   For  each
       region,  one  or  more  of  the  automerge algorithms (see
       below) are run to see if the changes may be  merged  auto-
       matically.

       The  bk  smerge command does not use the traditional diff3
       merge.  There are a number of heuristics  in  the  default
       enabled  merge  algorithms  which  help  determine regions
       which are safe  to  automerge.   These  can  simplify  and
       resolve  many conflict regions that can not be resolved in
       the traditional diff3 merge.  Please note, smerge can only
       be run on SCCS files.

       In  some  scripts  users may want to call smerge directly.
       If so, an example for usage is:

           bk smerge -g slib.c 1.661 1.660.1.4 > slib.c.merged

       where 1.661 is the local revision  and  1.660.1.4  is  the
       remote revision, slib.c is the file name and slib.c.merged
       is the file to which merge output is redirected.

       The string for the local remote versions of the  file  can
       be expressed in the form "rev+includes-excludes" where rev
       is a normal revision number like "1.661" and includes  and
       excludes  are  a  comma  separated  list  if  revisions to
       include or exclude from the base  revision.  (The  include
       and/or exclude lists can be omitted if they are empty.)

MERGE ALGORITHMS
       Each of the automerge algorithms is described below.  Cur-
       rently, all of these are run  by  default,  but  that  may
       change in the future.  Any mix of these may be selectively
       enabled or disabled.

       1. Merge identical changes made by both sides
              If both the local and the remote files have made an
              identical  change  to  the  GCA, then this function
              will resolve the region and replace it with the new
              text.
       2. Merge when only one side changes
              This  code  finds  conflict  regions where only the
              local or the remote version has made  any  changes.
              In  this case the conflict is resolved and the side
              that made changes is kept.  This is the traditional
              diff3 type automerge algorithm.
       3. Merge adjacent, non-overlapping modifications on both
       sides
              This code attempts to find a conflict consisting of
              a  text  substitution  in both the local and remote
              versions of the file.  A substitution is a line  or
              group  of  lines  that is deleted and then replaced
              with zero or more lines.  If there  is  a  conflict
              region that contains lines substituted in the local
              file that are unmodified in the  remote  and  there
              are  lines  substituted in the remote file that are
              unmodified in the local file, then a merge  of  the
              two substitutions is performed.

                 Here  is an example of a conflict region (in the
                 -g output format) where this algorithm will suc-
                 cessfully resolve the conflict.

                     <<<<<<< local slib.c 1.642.1.6 vs 1.645
                          sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
                     -    assert(sc->tree);
                     -    sccs_sdelta(sc, sc->tree, file);
                     +    assert(HASGRAPH(sc));
                     +    sccs_sdelta(sc, sccs_ino(sc), file);
                     <<<<<<< remote slib.c 1.642.1.6 vs 1.642.2.1
                     -    sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
                     +    sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
                          assert(sc->tree);
                          sccs_sdelta(sc, sc->tree, file);
                     >>>>>>>

                 The block after the resolve will be:

                          sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
                          assert(HASGRAPH(sc));
                          sccs_sdelta(sc, sccs_ino(sc), file);

                 Multiple substitutions are not yet handled.
       4. Merge identical changes at the start of a conflict
              This  code  recognizes  one  or  more  lines at the
              beginning the local and remote versions of  a  con-
              flict  region  that  are  identical.  If there is a
              block of lines that are identical then  the  region
              is  split into two regions with the identical lines
              in a region by themselves.  This block  will  later
              be resolved by algorithm #1.
       5. Merge identical changes at the end of a conflict
              This  is  similar  to algorithm #4, except it looks
              for identical lines on both sides at the end of the
              conflict region.
       6. Merge identical deletions made by both sides
              If  both  the  local and remote version of a region
              have deleted the same non-zero block  of  lines  at
              the  end  of the region, then split the region into
              two with the deletions in a separate  region.   The
              deletions will then get autoresolved.

       When  a  conflict  regions is identified, then the enabled
       algorithms are run on the block repeatedly until the block
       is resolved or no further progress is made.

       Default conflict output format is as follows:

           <<<<<<< gca slib.c 1.642.1.6
                sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
                assert(sc->tree);
                sccs_sdelta(sc, sc->tree, file);
           <<<<<<< local slib.c 1.645
                sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, s->proj);
                assert(HASGRAPH(sc));
                sccs_sdelta(sc, sccs_ino(sc), file);
           <<<<<<< remote slib.c 1.642.2.1
                sc = sccs_init(file, INIT_NOCKSUM|INIT_SAVEPROJ, p);
                assert(sc->tree);
                sccs_sdelta(sc, sc->tree, file);
           >>>>>>>

       Lines with "<<<<<<<" indicate the file the conflict region
       is from in the form:  <<<<<<<  <label>  <file>  <revision>
       followed by the conflict lines from that file.  The end of
       the conflict region is indicated by  ">>>>>>>".   Examples
       of conflict output can be viewed by using the -e option.

OPTIONS
       -2        Enable the 2 way output format (like diff3)
       -g        Enable  'gca' output format that shows the local
                 and remote files like a unified diff between the
                 GCA and that file.  This is the recommended out-
                 put format, but not the default because it  con-
                 fuses people the first time they see it.
       -n        Enable  the  'newonly'  output format.  (like -2
                 except it marks added lines)
       -e        Print examples of  all  4  output  formats  from
                 smerge.
       -a<n>     Enable merge functions <n>, where <n> is a comma
                 separated list of automerge algorithms specified
                 by  number.   -a<all> will  enable all automerge
                 algorithms.  Use 'bk  smerge  -h'  to  find  the
                 algorithms enabled by default.
       -A<n>     Disable  merge  functions  <n>,  where  <n> is a
                 comma separated  list  of  automerge  algorithms
                 specified  by number.  -A<all> will turn off all
                 automerging.
       -f        Enable  fdiff  output.   (Used   internally   by
                 fm3tool)
       -h        Display  automerge algorithms by number that are
                 enabled by default.  If used in conjunction with
                 -a or -A, asterisks denote enabled algorithms.

EXIT STATUS
       0 for no conflicts, 1 for conflicts, 2 for errors.

SEE ALSO
       diff3(1)
       bk help merging
       bk help resolve
       bk help merge

CATEGORY
       Utility

BitMover, Inc               2001/08/28                          1
$
help://status
help://status.1
help://bk-status
help://bk-status.1

bk status(1)         BitKeeper User's Manual         bk status(1)

NAME
       bk status - show repository status

SYNOPSIS
       bk status [-v] [<repository>]

DESCRIPTION
       The  status  command  gives  a quick overview of the tree.
       The default output looks something like:

           Status for BitKeeper repository /u01/package/bk
           BitKeeper version is bk-beta-14.3 20000302045832 for x86-linux
           Built by: lm@work.bitmover.com
           Built on: Wed Mar  1 21:22:07 PST 2000
           Parent repository is bitmover.com:/home/bk/one
           Pending patches
               61 people have made deltas.
              600 files under revision control.
                3 files not under revision control.
                0 files modified and not checked in.
                0 files with checked in, but not committed, deltas.

OPTIONS
       -v     Verbose listing.   Lists  users,  files  not  under
              revision  control,  files  modified and not checked
              in, and files with checked in,  but  not  committed
              deltas, one per line.

SEE ALSO
       bk help sfiles

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://stripdel
help://stripdel.1
help://bk-stripdel
help://bk-stripdel.1

bk stripdel(1)       BitKeeper User's Manual       bk stripdel(1)

NAME
       bk stripdel - strip deltas out of an s.file

SYNOPSIS
       bk stripdel [-bCcdq] [-r<rev>] <filename>

DESCRIPTION
       The  bk  stripdel command is used to "strip" deltas from a
       revision history.  The  deltas,  once  stripped,  are  not
       recoverable.

       This command is typically called by the bk clone or the bk
       undo commands, and perhaps the bk import command.  It  can
       be  called  directly  if you wish to remove certain deltas
       from a file.

       The stripdel command will fail if the specified  revisions
       are  included in a changeset and the -C option is not pre-
       sent.

WARNING
       It is an extremely bad idea to use the -C option,  it  can
       corrupt  your repository.  Instead, consider the -x option
       of bk get.

OPTIONS
       -b        Strip all branch deltas.
       -C        Do not respect cset boundaries, used by bk undo.
       -c        Checks  if  the specified rev[s] can be stripped
                 but do not strip them.
       -d        Strip deltas which are part of a MONOTONIC file.
       -q        Run quietly.
       -r<rev>   Set of revisions to be removed.

SEE ALSO
       bk help admin
       bk help clone
       bk help get
       bk help undo

CATEGORY
       File

BitMover, Inc               2003/07/11                          1
$
help://superset
help://superset.1
help://bk-superset
help://bk-superset.1

bk superset(1)       BitKeeper User's Manual       bk superset(1)

NAME
       bk  superset  - check to see if the parent is ahead of the
       current repository

SYNOPSIS
       bk superset [-q] [<parent>]

DESCRIPTION
       superset does checks to see if removing the current repos-
       itory is a lossless event.  It checks that:

       => the  parent  has all changesets that are in the current
          repository
       => there are no pending deltas
       => there are no modified files
       => there are no extra files
       => there are no parked files

       Unless the -q option is present superset lists all  things
       which are not in the parent.

OPTIONS
       -q     Be quiet

EXIT STATUS
       superset  exits  0  if  the parent is a superset, 1 if the
       parent is not.

CATEGORY
       Repository

BitMover, Inc               2001/08/02                          1
$
help://tag
help://tag.1
help://bk-tag
help://bk-tag.1
help://tags
help://label
help://labels

bk tag(1)            BitKeeper User's Manual            bk tag(1)

NAME
       bk tag - tag the BitKeeper repository with a symbolic name

SYNOPSIS
       bk tag [-r<rev>] <symbol>

DESCRIPTION
       Symbols (aka tags or labels) are used  when  you  want  to
       record  the  state of a tree.  It is quite common to ``tag
       the tree'' with a release name when shipping a product  to
       customers.

       To  add  a  tag  to  the repository, make sure that you've
       checked everything in and created a  changeset.   You  can
       use  bk  status  to see what needs to be checked in and/or
       committed to a changeset. Tag the tree by typing:

           $ bk tag Alpha

       The Alpha symbol will be set on the most recent changeset.
       Or you can commit a changeset and tag the tree at the same
       time with the -S option to commit:

           $ bk commit -SAlpha

       If you want to recover the state of the world as of a tag,
       do this:

           $ bk clone -rAlpha source_repository Alpha

       which  will create a repository which has everything up to
       and including the Alpha changeset.

       If you discover that you should have  tagged  a  changeset
       after  more  changesets have been added to the repository,
       use the -r option to select the proper changeset.  You can
       find out which revision to tag by running bk changes.

       A frequent problem is that you tag a changeset with "Done"
       and then discover you aren't done.  You may update the tag
       to the later changeset by running the

           $ bk tag Done

       command  again.   If there are multiple tags with the same
       name, BitKeeper takes the most recently applied tag (which
       means  you can move a tag backwards by specifying an older
       revision of the cset file).

       Tagging individual files, while possible  with  the  admin
       command,  is  generally unnecessary.  However, if you want
       to tag all the files, you can do so like this:

           $ bk -r admin -SAlpha

       That will put the Alpha tag on top of trunk on all  files.

BUGS
       Need a way of setting a tag in citool.

SEE ALSO
       bk help admin
       bk help changes
       bk help commit
       bk help prs

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://takepatch
help://takepatch.1
help://bk-takepatch
help://bk-takepatch.1

bk takepatch(1)      BitKeeper User's Manual      bk takepatch(1)

NAME
       bk takepatch - apply a BitKeeper patch

SYNOPSIS
       bk takepatch [-acimStv] [-f[<file>]]

DESCRIPTION
       The  takepatch command is used to apply a BitKeeper patch.
       BitKeeper patches are how data is moved between  BitKeeper
       repositories.

       Users  do  not  normally invoke this command, it is called
       directly by bk pull, bk push, or bk receive.

OPTIONS
       -a        Apply the changes (call bk resolve.)
       -c        Do not accept conflicts with this patch.
       -f<file>  Take the patch from <file> and do not save it.
       -i        Initial patch, create a new repository.
       -m        List deltas as they are read in the patch.
       -S        Save RESYNC and or PENDING directories  even  if
                 errors.
       -t        Run in text only mode, do not talk to X11.
       -v        Verbose level, more is more verbose, -vv is sug-
                 gested.

SEE ALSO
       bk help pull
       bk help push
       bk help receive

CATEGORY
       Repository

BitMover, Inc               2003/06/04                          1
$
help://terms
help://terms.1
help://bk-terms
help://bk-terms.1

bk terms(1)          BitKeeper User's Manual          bk terms(1)

NAME
       bk terms - definitions of BitKeeper terms

DESCRIPTION
   BitKeeper definitions:
       package
         This  term  is used when a distinction needs to be drawn
         between two different repositories which do not  contain
         the  same  data,  i.e.  one  contains a compiler and the
         other contains a debugger.  To distinguish between them,
         refer  to  the compiler package or the debugger package.
         One way to think about it is that a package is a logical
         concept,  somewhat like an object, while a repository is
         an instance of that object.   Another  way  that  people
         sometimes  distinguish between packages is to talk about
         them having different root keys  (each  package  has  an
         internal identifier called the root key).
       repository
         A repository (also known as a work space, a clone, or an
         instance of a package) is where you  do  your  work.   A
         repository  is  an  instance of a package i.e.  there is
         one package, but there can be  many  instances  of  that
         package.   Unlike other systems, such as CVS, every user
         gets their own repository, complete with  revision  his-
         tory.
       sfile
         A   file   containing   the   revision   history,  e.g.,
         SCCS/s.foo.c
       gfile
         A file that is checked out, e.g., foo.c
       tag, symbol
         A symbolic name (or tag) which is given to a  particular
         revision of one or more files.  e.g., "Alpha1".
       delta
         A  delta (also known as a revision or version) is a spe-
         cific version of a  file,  or  one  change  to  a  file,
         depending on context.  When we mean the specific version
         of a file, we are talking about the entire  file  as  of
         that  version.   When we mean the changes made in a spe-
         cific delta, we are talking about the  differences  con-
         tained in that delta.
       rev argument
         Many  commands  take file revision numbers as arguments,
         usually to the -r option.  On the command line anytime a
         revision  number  is expected, the delta key can be used
         instead.  Or after an @ sign, a changeset revision, tag,
         or  changeset key can be used.  So -r@1.4 finds the ver-
         sion number as of changeset revision 1.4. So the follow-
         ing are all legal:

             -r1.23
             -r3dcc5f35PWiRWg8wiP7Dehy51Pk7DA
             -r'amy@bitmover.com|man/man1/bk-terms.1|20020714011327|59990'
             -r@1.233.2
             -r@bk-3.0-pre3
             -r@'lm@disks.bitmover.com|ChangeSet|20020912140445|17593'

       ChangeSet
         The  file  used  to  record the repositories' history of
         changes.
       cset, changeset
         A particular change to a repository consisting of one or
         more changes to one or more files.
       changeset number
         Revision  number for a changeset.  These numbers fluctu-
         ate,  but  stabilize,  over  time.   If  you   want   an
         immutable,  unique  reference  for  a changeset, use the
         changeset key.
       key
         A unique, unchanging identifier for a version of a  file
         which  may  be  used  anywhere  a normal revision number
         and/or symbolic tag is used.  A particular  key  may  be
         extracted  with the following, the first form produces a
         longer key which is human readable, the second form pro-
         duces a shorter key which is not human readable.

             bk -R prs -hr<rev> -nd:KEY: ChangeSet
             bk -R prs -hr<rev> -nd:MD5KEY: ChangeSet

       package identity
         Each  BitKeeper  package  has  a  unique  identity.  All
         instances (repositories) of the package  have  the  same
         package indentity.
       repository identity
         Each repository has a unique identifier which is differ-
         ent across all repositories, regardless of the  package.
       pending
         Deltas  which  have been checked into a file but not yet
         committed to a changeset.
       patch
         Formally, this is one or more changesets wrapped up  for
         transmission to someone else.  It is similar to what you
         may be used to thinking of as a patch (a list of all the
         changes  between  two versions of an entire package) but
         carries more information: who made  the  changes,  when,
         and why.
       Trunk
         Main  line source base.  In BitKeeper revtool, the trunk
         is the X.Y in the graph,  branches  are  X.Y.Q.Z,  which
         always get merged into the trunk.
       Tip, Top of Trunk (TOT)
         The latest revision on the trunk.

NOTES
       We  attempt to list all of the BitKeeper definitions here,
       but send us a message at "docs@bitkeeper.com" if you  have
       suggestions for definitions we may have missed.

CATEGORY
       Overview

BitMover, Inc               2002/11/20                          1
$
help://treediff
help://treediff.1
help://bk-treediff
help://bk-treediff.1

bk treediff(1)       BitKeeper User's Manual       bk treediff(1)

NAME
       bk treediff - compare two directory trees

SYNOPSIS
       bk treediff [<dirA>] [<dirB>]

DESCRIPTION
       The treediff command compares two trees using diff and can
       be used to generate patches suitable  for  import  into  a
       repository.

       The  two arguments must be, at a minimum, directories, but
       may be full repositories.  The  treediff  command  invokes
       the  diff command excluding the names SCCS, BitKeeper, and
       ChangeSet.

EXAMPLE
       You have a BitKeeper repository of  the  linux  kernel  at
       2.4.0 to which you have applied some public patch (call it
       the foo patch).  This represents point A  and  we'll  call
       this repository linux.

       You  have  another  directory  tree of the linux kernel at
       2.4.1 to which you apply  the  new  foo  patch  for  2.4.1
       (using  stuff you've downloaded).  This represents point B
       and we'll call this directory linux-new.

       You now run

           bk treediff linux linux-new > patch-2.4.0-to-2.4.1

       You can now

           bk import -tpatch patch-2.4.0-to-2.4.1 linux

       to bring the linux repository from point A to point B.

       Since your linux repository is updated, you can erase your
       linux-new  tree.  (You can run treediff again, by way of a
       test, and there should be no output.  You may have to do a

           bk -r get

       in  your  linux  repository  after the import depending on
       what your checkout config is.)

BUGS
       The treediff command makes no assumptions or  examinations
       of  its  arguments.   If  either  argument contains binary
       files, or other artifacts of a build  process  the  output
       will  not be suitable for import as described in the exam-
       ple.  It is recommended that you only compare clean trees.

SEE ALSO
       bk help config-etc
       bk help import

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://triggers
help://triggers.1
help://bk-triggers
help://bk-triggers.1

bk triggers(1)       BitKeeper User's Manual       bk triggers(1)

NAME
       bk triggers - using BitKeeper event triggers

DESCRIPTION
       BitKeeper  supports a variety of trigger types.   Triggers
       are simple programs, usually shell scripts, which  may  be
       called  before and/or after certain events, such as a com-
       mit, pull, push, resolve, etc.  Triggers can be  used  for
       event  notification  and/or  to implement control over the
       events themselves.

       When a trigger is called, it is called  with  the  current
       working  directory  set  to  the  root of the  repository.
       Note that in the case of incoming data, the  root  of  the
       repository is defined as the RESYNC directory.

       If  an  incoming  changeset adds or updates a trigger, the
       incoming trigger is not the trigger fired, with the excep-
       tion  of  the  post-incoming trigger.  The trigger already
       present in the repository, if any, is  the  trigger  used.
       This arrangement is for security reasons; incoming changes
       could be malicious or ill advised and a prudent repository
       manager  may have developed triggers to look for problems.
       If the incoming data contained a new or modified  trigger,
       and  that  trigger  was run, triggers could not be used to
       implement security or other  policies  at  the  repository
       boundary.

       Triggers  only  occur  when  events happen which (may) add
       changes.  The removal of changes via bk undo,  bk  unpull,
       etc, does not result in any triggers being run.

   TRIGGER NAMES
       When  an  event  occurs,  if  there  exists  a  file  Bit-
       Keeper/triggers/<event_class> in the repository root  that
       corresponds  to  the  event,  BitKeeper  will execute that
       trigger.  For example, if there is a push from  repository
       B going into repository A and repository A has a file Bit-
       Keeper/triggers/pre-incoming, the pre-incoming script will
       be run before the push event applies to repository A.

       All triggers for a particular class must be named with the
       class name and prefix,  for  example  pre-incoming.   More
       than  one trigger per event class is allowed; each trigger
       program has the class name and prefix and a suffix of your
       choosing.   The trigger programs are sorted and run alpha-
       betically (C locale sort order).  Files ending  in  ~  are
       ignored  to  avoid editor backup files.  In order to avoid
       name space conflicts, the typical approach is to  use  the
       reason for the trigger as the suffix, i.e.,

           post-incoming.mail
           post-incoming.regression-test

   TRIGGER CLASSES
       There  are  four  event  classes  which activate triggers:
       incoming events, outgoing  events,  deltas,  and  commits.
       The  incoming event is broken into multiple events: incom-
       ing, resolve, and apply.

       Most events may have  triggers  which  run  before  and/or
       after  the  event.   The difference between pre- and post-
       event triggers is that pre-triggers may  cause  events  to
       fail, but post-triggers are strictly informational.

       Not  all  triggers  have both pre- and post- versions, the
       set of supported triggers are as follows:

       pre-commit
       => called before a changeset is committed.
       => exit 0 allows the commit.
       => exit 1 fails the commit. If the  commit  was  initiated
          from citool, citool will not exit. This allows the user
          to try the commit again.  See example below.
       => exit 2 Reserved for  future  use  (see  pre-delta)  and
          should not be used.

       post-commit
       => called  after  a changeset is committed or attempted to
          be committed.
       => typically used for notification.

       pre-delta
       => called before a delta is created. Can be use for  trig-
          gers that check code style
       => exit 0 allows the delta.
       => exit  2 indicates that the trigger called delta itself,
          upon which the calling delta command  treats  it  as  a
          successful delta.
       => Other  than 2, all other non-zero exit values will fail
          the delta.

       pre-incoming
       => called before an incoming push/pull is started.
       => non-zero exit status fails the incoming event.
       => typically used for locking down a repository.
       => may be used to fail the event  based  on  remote  user,
          host, directory, and/or BitKeeper version.

       pre-resolve
       => called  after  the data has been union-ed in the RESYNC
          directory.
       => called in  the  RESYNC  directory,  not  the  enclosing
          repository.
       => exit 0 allows the pull/push.
       => exit 1 fails the entire pull/push.
       => exit  2 fails the entire pull/push but leaves the patch
          in PENDING.
       => typically used to examine changes before taking them.

       pre-apply
       => called after the data has been  merged  in  the  RESYNC
          directory  but  before it is applied to the tree.  Last
          chance to say  no,  allows  examination  of  the  merge
          changes.
       => called  in  the  RESYNC  directory,  not  the enclosing
          repository.
       => exit 0 allows the pull/push.
       => exit 1 fails the entire pull/push.
       => exit 2 fails the pull/push  but  leaves  the  patch  in
          PENDING.
       => exit  3  fails  the  pull/push  but leaves the patch in
          PENDING and the RESYNC tree in PENDING/RESYNC-<date>.
       => typically used to examine changes before taking them.

       post-incoming
       => called after the data has been applied to the tree.
       => typically used for notification.

       pre-outgoing
       => called before an outgoing pull/push/clone event.
       => non-zero exit status fails the outgoing event.
       => typically used for locking down a repository.

       post-outgoing
       => called after the outgoing event.
       => typically used for notification.

   TRIGGER SECURITY ISSUES
       Because triggers can propagate and because they can do bad
       things like

           rm -rf .

       it  is  a  wise  idea to put a paranoid trigger like so in
       your tree:

           cat > BitKeeper/triggers/pre-apply.paranoid <<EOF
           #!/bin/sh

           # This is running in the RESYNC tree, we're looking for any new
           # triggers and/or changes to triggers.
           # Done after the resolve stage because
           # they could be sneaky and create
           # the file in an earlier changeset and
           # then move it.
           test `bk sfiles BitKeeper/triggers | wc -l` -gt 0 && {
                echo Changes delayed until they are reviewed
                mail -s 'Review the triggers' bk-admin < /dev/null
                exit 3
           }
           exit 0
           EOF

   TRIGGER ENVIRONMENT VARIABLES
       Information which might be useful to the trigger is passed
       in  environment  variables.  There are variables for user,
       host,  location,  BitKeeper  version,  repository   level,
       amongst  others.   There  are  two  classes  of variables,
       client side variables (BK_*)  and  server  side  variables
       (BKD_*).   The  client  side variables are associated with
       the user who initiated the command.  The server side vari-
       ables, if present, are associated with the "other" reposi-
       tory.  For example, if a user on host  "to"  does  a  pull
       from  host  "from", then BK_HOST=to and BKD_HOST=from.  In
       the list of variables which follow,  BKD_*  variables  are
       not present unless the command has two end points, such as
       a pull, push,  or  clone.   The  BKD_  variables  are  not
       defined  for  commit,  resolve,  and apply events.  In all
       other cases, the  variable  is  present  in  all  triggers
       unless otherwise stated.

       BK_CSETLIST If set, contains the name of a file which con-
                   tains the list of changesets  being  received.
                   Valid  in  pre-outgoing,  post-outgoing,  pre-
                   resolve, pre-apply,  and  post-incoming  trig-
                   gers.
       BK_CSETS    If  set, contains the list of changesets being
                   sent.  Valid only in  pre-outgoing  and  post-
                   outgoing clone events.
       BK_COMMENTFILE
                   Location  of  the comment file for the change-
                   set. Useful when writing triggers that need to
                   parse  the  changeset  comments.  See  example
                   below.
       BK_EVENT    The event from the point of view of the  trig-
                   ger.   The  full list of values for this vari-
                   able is commit, delta, outgoing clone,  incom-
                   ing push, outgoing push, incoming pull, outgo-
                   ing pull, resolve and apply.
       BK_FILE     Valid only in the pre-delta trigger, and  con-
                   tains  the  filename  of  the file about to be
                   delta-ed.
       BK_HOST     The hostname of the client side host.
       BKD_HOST    The hostname of the server side host.
       BK_LEVEL    The "level" of the client side repository.
       BKD_LEVEL   The "level" of the server side repository.
       BK_LOCALCSETS
                   The number of changesets (and/or  tags)  which
                   are  not  present in the remote repository but
                   are present in  the  local  repository.   Note
                   that  this  variable does not have a BKD_ ver-
                   sion because it is valid only on the  outgoing
                   end  of  a pull or a push.  The other variable
                   is BK_REMOTECSETS.  Both variables  are  valid
                   in  pre-outgoing  and  post-outgoing  triggers
                   only.
       BK_PATCH    Valid only in  the  pre-resolve  trigger,  and
                   contains  the  full  pathname of the file con-
                   taining the patch being resolved.
       BK_PENDING  Contains the name of a file which contains the
                   list of files with pending deltas.  Valid only
                   in pre-commit.
       BK_REMOTECSETS
                   The number of remote changesets (and/or  tags)
                   which  are not present in the local repository
                   but are  present  in  the  remote  repository.
                   Goes  with  BK_LOCALCSETS and is valid only in
                   pre-outgoing and post-outgoing triggers.
       BK_ROOT     The full path name to the root of  the  client
                   side repository.
       BKD_ROOT    The  full  path name to the root of the server
                   side repository.
       BK_SIDE     If the trigger is part of a  two-sided  opera-
                   tion  (i.e.,  pull, push), then this is set to
                   "server" if the  trigger  is  running  on  the
                   server  repository.   Otherwise this is set to
                   "client".
       BK_STATUS   The status of the command, if  known.   Values
                   may include:
                   NOTHING
                          There was nothing to pull or push.
                   FAILED The command did not complete because of
                          an error.
                   DRYRUN The command did not complete because it
                          was  a  "dry  run",  i.e., a pull -n to
                          look to see if  there  is  anything  to
                          pull.
                   CONFLICTS
                          The  command  did  not complete because
                          there were conflicts (parallel work).
                   SIGNALED
                          The command did not complete because it
                          received a signal.
                   OK     The command completed successfully.
                   UNKNOWN
                          Unknown status.
       BK_TIME_T   The Unix style timestamp of the client side BK
                   binary.
       BKD_TIME_T  The Unix style timestamp of the server side BK
                   binary.
       BK_TRIGGER  The basename name of the trigger program.
       BK_USER     The  user name of the user who ran the command
                   on the client.
       BKD_USER    The user name of the user who ran the  command
                   on the server.
       BK_UTC      The  time  stamp  of the client side BK binary
                   expressed as YYYYMMDDHHMMSS.
       BKD_UTC     The time stamp of the server  side  BK  binary
                   expressed as YYYYMMDDHHMMSS.
       BK_VERSION  The  version  of  the client side BK binary as
                   the symbolic name or the UTC.
       BKD_VERSION The version of the server side  BK  binary  as
                   the symbolic name or the UTC.

   LOCKING
       When  a  post  trigger  is  called, the repository is read
       locked.  A read lock will allow the trigger to do outgoing
       events,  such as a push, but will prevent incoming events.
       Pre-incoming and pre-commit triggers will be called with a
       write locked repository.

EXAMPLE 1
       #!/bin/sh

       # Display info about incoming and outgoing csets.

       if [ X$BK_STATUS = XDRYRUN -o X$BK_STATUS = XNOTHING ]
       then exit 0
       fi
       if [ $BK_SIDE = server ]
       then U=$BKD_USER
            H=$BKD_HOST
            R=$BKD_ROOT
       else U=$BK_USER
            H=$BK_HOST
            R=$BK_ROOT
       fi
       (
       if [ X$BKD_ROOT != X ]
       then printf '%-10s%-20s%-20s\n' VAR CLIENT SERVER
            printf '%-10s%-20s%-20s\n' === ====== ======
            printf '%-10s%-20s%-20s\n' USER $BK_USER $BKD_USER
            printf '%-10s%-20s%-20s\n' HOST $BK_HOST $BKD_HOST
            printf '%-10s%-20s%-20s\n' ROOT $BK_ROOT $BKD_ROOT
            printf '%-10s%-20s%-20s\n' LEVEL $BK_LEVEL $BKD_LEVEL
            printf '%-10s%-20s%-20s\n' TIME_T $BK_TIME_T $BKD_TIME_T
            printf '%-10s%-20s%-20s\n' UTC $BK_UTC $BKD_UTC
            printf '%-10s%-20s%-20s\n' VERSION $BK_VERSION $BKD_VERSION
            echo
       fi
       echo ${U}@${H} fired the $BK_TRIGGER trigger in $R
       case $BK_TRIGGER in
           pre-outgoing)   VERB=Sending;;
           post-outgoing)  VERB=Sent;;
           pre-incoming)   VERB=Receiving;;
           post-incoming)  VERB=Received;;
           pre-resolve)    VERB=Resolving;;
           pre-commit)          VERB=Committing;;
           post-commit)    VERB=Committed;;
           pre-apply)      VERB=Applying;;
       esac
       if [ X$BK_PENDING != X ]
       then (
            echo $VERB the following deltas
            echo
            bk prs - < $BK_PENDING
            ) | sed 's/^/    /'
       fi
       if [ X$BK_CSETLIST != X ]
       then (
            echo $VERB the following changesets
            echo
            bk changes -v - < $BK_CSETLIST
            ) | sed 's/^/    /'
       fi
       if [ X$BK_CSETS != X ]
       then (
            echo $VERB the following changesets
            echo
            bk changes -v -r$BK_CSETS
            ) | sed 's/^/    /'
       fi
       ) | mail -s "$BK_EVENT in ${H}:${R}" notify@bitmover.com

EXAMPLE 2
       #!/bin/sh
       #
       # Using pre-commit trigger to verify changeset comment
       # BitKeeper/trigger/pre-commit.cset_comments
       #

       grep -q 'BUGID:' $BK_COMMENTFILE && exit 0

       msg="A 'BUGID:' field is needed in the checkin comments"

       # Bring up an external program to browse bugs so that the
       # engineer can add a valid bugid to the changeset comments.

       #/opt/bugtrack/bin/bugviewer 'http://server.host.com/bugs?status=open' &

       # Ask user if he needs to enter a bugid.  returning a non-zero exit
       # code from the trigger will allow user to retry the commit from
       # within citool.
       bk prompt -y"Reenter bugid" -n"No bugid is required" "$msg" && exit 1

       exit 0

SEE ALSO
       bk help prompt

CATEGORY
       Repository

BitMover, Inc               2003/06/27                          1
$
help://undo
help://undo.1
help://bk-undo
help://bk-undo.1

bk undo(1)           BitKeeper User's Manual           bk undo(1)

NAME
       bk undo - Undo a changeset or set of changesets

SYNOPSIS
       bk undo [-fqs] -a[<rev>] | -r[<revs>]

DESCRIPTION
       The  undo  command  can be used to remove any changeset or
       set of changesets.   There are options to select  specific
       changesets  or  all  changesets after some point (which is
       what bk clone -r uses.)

       To undo a bk pull use bk unpull.

WARNING
       You can not undo an undo.  If the data was only present in
       your repository, when you undo it, it is gone for good.

OPTIONS
       -a<rev>   Remove   all  changesets  which  occurred  after
                 <rev>.  If <rev> is what you want to have be top
                 of trunk, use this option.
       -f        Force the undo to complete if it can.  Normally,
                 undo will prompt with a  list  of  deltas  which
                 will be removed.
       -q        Run quietly; do not list files.
       -s        Do not save undone changes as a patch.
       -r<revs>  Remove  the  list  of  changesets  specified  by
                 <revs>.  <revs> must be of  the  form  r1,r2,r3,
                 etc.  and  can be either the changeset number or
                 the changeset key.  See bk help terms  for  more
                 information.

SEE ALSO
       bk help makepatch
       bk help stripdel
       bk help takepatch
       bk help terms
       bk help unpull

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://undos
help://undos.1
help://bk-undos
help://bk-undos.1

bk undos(1)          BitKeeper User's Manual          bk undos(1)

NAME
       bk undos - convert DOS files to UNIX files

SYNOPSIS
       bk undos [-n] [<file> ...]

DESCRIPTION
       The  bk  undos command reads the specified file and trans-
       lates each \r\n into \n.

OPTIONS
       -n     automatically add a trailing newline  if  the  file
              does not already have one.

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://unedit
help://unedit.1
help://bk-unedit
help://bk-unedit.1
help://unget

bk unget(1)          BitKeeper User's Manual          bk unget(1)

NAME
       bk  unedit - destroy any unchecked in changes to specified
       files

SYNOPSIS
       bk unedit [-q] [<file> ...]
       bk unget [-q] [<file> ...]

DESCRIPTION
       If you wish to discard any modifications you have made  to
       a  file,  you can use the unedit command.  For each listed
       file, unedit will discard the write lock and  discard  the
       checked  out  file  and  ANY  CHANGES YOU HAVE MADE TO THE
       FILE.  Use this command only when you have made changes to
       a  file that you want to throw away.  If you want to clean
       up only those files without changes, use the bk clean com-
       mand.

       The  unedit command will not autoexpand the file list, you
       must explicitly name each file you want to unedit.

       unget is an alias for unedit; unget is the ATT  SCCS  com-
       patible name.

OPTIONS
       -q     be quiet.

SEE ALSO
       bk help clean
       bk help edit
       bk help unlock

CATEGORY
       File

BitMover, Inc               2002/12/03                          1
$
help://unlock
help://unlock.1
help://bk-unlock
help://bk-unlock.1
help://Repository/locks
help://Repository/repo
help://Repository/unlocking

bk unlock(1)         BitKeeper User's Manual         bk unlock(1)

NAME
       bk unlock - remove BitKeeper file locks

SYNOPSIS
       bk unlock [-rsw] [directory]
       bk unlock [-fpxz] [<file> ...]

DESCRIPTION
       The  unlock command can be used to remove locks which have
       been  left  behind  for  some  reason.   In  general,  you
       shouldn't  need  this command, if you do it indicates that
       either you are removing files without unediting them or it
       indicates  that  BitKeeper  is  leaving lock files that it
       should not.  If it is the second case,  please  tell  sup-
       port@bitmover.com so we can fix that problem.

       There  are two sorts of locks in BitKeeper, file locks and
       repository locks.  The  unlock  command  can  unlock  both
       kinds.

REPOSITORY UNLOCKING
       The  unlock command can be used to remove repository level
       locks.  This can be necessary if a remote process has left
       behind  a lock (local stale locks are detected and cleaned
       automatically).  A stale lock is one which has  been  cre-
       ated locally but the process is no longer present.

       Note:  a  repository can have two write locks: the regular
       lock file and  the  existence  of  the  RESYNC  directory.
       Removing the write lock does not imply removing the RESYNC
       directory, see bk help abort for that.

REPOSITORY UNLOCK OPTIONS
       -r     Remove all read locks, stale or not.
       -s     Remove both read and write locks, but only if  they
              are stale.
       -w     Remove  the  write  lock,  stale  or not.  Does not
              remove the RESYNC directory.

FILE UNLOCKING
       Sometimes you need to explicitly unlock files.   The  most
       common  reason for wanting to do this comes from doing the
       following:

               $ bk edit user.c
               $ rm user.c
               $ bk edit user.c
               get: can't plock user.c
               get of SCCS/s.user.c failed, skipping it.

       In other words, the checked out file has been removed  but
       the lock file still exists.  See the clean and unedit com-
       mands for ways to avoid this in the future.

       The unlock command will fix the problem described above by
       removing  what  is  called  the  ``p.file'',  in this case
       SCCS/p.user.c.

       The options listed above explain how  to  use  the  unlock
       command to remove other kinds of locks as well.

       By  default,  unlock  removes the p.file lock.  The z.file
       will normally time out and be discarded unless it was cre-
       ated on a different host (via NFS or SMB).

       The  default  behavior  of  unlock is to remove the p.file
       only if the checked out file does not  exist,  i.e.,  like
       the scenario described above.

FILE UNLOCK OPTIONS
       -f     Force  the unlink of the p.file even if the checked
              out file exists.
       -p     Removes the p.file lock  which  is  created  by  bk
              edit.
       -x     Removes  the  x.file lock which is created during a
              check-in. x.file contains the new s.file.  Use with
              care,  the  presence  of  this  file  means that an
              update in progress failed.
       -z     Removes the z.file lock which is created to prevent
              check-in and edit races.

BUGS
       The  unlock  interface is overload for both file level and
       repository level operations and that is confusing.

SEE ALSO
       bk help unedit
       bk help clean
       bk help lock
       bk help abort

CATEGORY
       File
       Repository

BitMover, Inc               2002/09/17                          1
$
help://unpull
help://unpull.1
help://bk-unpull
help://bk-unpull.1

bk unpull(1)         BitKeeper User's Manual         bk unpull(1)

NAME
       bk unpull - remove changesets added by bk pull

SYNOPSIS
       bk unpull [-fq]

DESCRIPTION
       bk  unpull will remove changesets added by the most recent
       bk pull command.  If a local changeset has been committed,
       bk  unpull  can  not  be  executed until that changeset is
       removed by bk undo.

OPTIONS
       -f     Force unpull.
       -q     Quiet mode.

SEE ALSO
       bk help pull
       bk help undo

CATEGORY
       Repository

BitMover, Inc               2002/09/17                          1
$
help://unrm
help://unrm.1
help://bk-unrm
help://bk-unrm.1

bk unrm(1)           BitKeeper User's Manual           bk unrm(1)

NAME
       bk unrm - resurrect a removed BitKeeper file

SYNOPSIS
       bk unrm <file>

DESCRIPTION
       Use  unrm  to resurrect a file that has been deleted using
       bk rm.  Please note that unrm can not resurrect files that
       have been removed from the source tree using bk gone.

       If  you  know  the  path to the original file, for example
       src/Makefile, then to resurrect:

           cd ~/projects/myproject/src
           bk unrm Makefile

       If you do not know the directory run unrm from the root of
       the repository:

           cd ~/projects/myproject
           bk unrm Makefile

       There  will  be  an  interactive  interface  for  choosing
       whether or not to resurrect the file.  Type "y" to  resur-
       rect the file, "n" to do nothing or go to the next option,
       or "q" to quit.  If there are more than one files with the
       same name, choose "y" if the pathname shown is the one you
       want, or choose "n" until the correct file is shown.

SEE ALSO
       bk help gone
       bk help rm
       bk help rmdir

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://unwrap
help://unwrap.1
help://bk-unwrap
help://bk-unwrap.1

bk unwrap(1)         BitKeeper User's Manual         bk unwrap(1)

NAME
       bk unwrap - unwrap patches

SYNOPSIS
       bk unwrap < <patch> > <patch.unwrapped>

DESCRIPTION
       Normally  you  do  not  use  this command as it is invoked
       automatically as part of the bk  receive  command.    How-
       ever,  you  may  want to use this command to peek inside a
       wrapped patch.

SEE ALSO
       bk help receive
       bk help send
       bk help wrap

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://url
help://url.1
help://bk-url
help://bk-url.1
help://remote
help://naming

bk url(1)            BitKeeper User's Manual            bk url(1)

NAME
       bk url - methods of accessing BitKeeper repositories

DESCRIPTION
       BitKeeper  supports many ways to access a repository.  The
       selection of the access method is determined  by  how  the
       repository   is   referenced.    Each  reference  form  is
       described below with an explanation of how the  repository
       is accessed following each form.

ACCESS METHODS
   LOCAL
       <pathname>
           Access is all local, through the local file system.
       <host>:<pathname>
           Normally  a remote repository unless <host> is what bk
           gethost returns or is localhost.  In either  of  those
           cases, this form is the same as the above form.
       file://<pathname>
           Access is through the local file system.

   RSH
       rsh://<host>:<pathname>
       rsh://<user>@<host>:<pathname>
           Uses rsh to access <host>, and starts a temporary bkd.

   SSH
       <host>:<pathname>
       <user>@<host>:<pathname>
           Uses ssh (by default) to access <host>, and  starts  a
           temporary  bkd.   If  $BK_RSH is set, then use that to
           talk to the host (allows  proxying).   If  no  ssh  is
           found then falls back to rsh.
       ssh://<host>:<pathname>
       ssh://<user>@<host>:<pathname>
           Uses ssh to access <host>, and starts a temporary bkd.
       bk://<user>@<host>
           Connects to <host> using ssh, assumes that bkd is  the
           login shell.  The home directory of <user> must be the
           root of the repository.
       bk://<user>@<host>:<pathname>
           Connects to <host> using ssh, assumes that bkd is  the
           login  shell.   Changes  directories  to the specified
           pathname, which may be relative to the home  directory
           or absolute.

   BKD
       bk://<host>
           Connects  to  an existing bkd on the default bkd port.
           The bkd must be at the root of the repository.
       bk://<host>/<rel>/<path> OR bk//<host>/<rel>/<path>
           Connects to an existing bkd on the default  bkd  port,
           changes  to  <rel>/<path>,  then  runs command.  Where
           <rel>/<path> is the path relative to the root  of  the
           repository.
       bk://<host>//<full>/<path> OR bk//<host>//<full>/<path>
           Connects  to  an existing bkd on the default bkd port,
           changes to <full>/<path>, then  runs  command.   Where
           <full>/<path> is the absolute path.
       bk://<host>:<port>
           Connects  to  an  existing  bkd on the specified port.
           bkd must be at the root of the repository.
       bk://<host>:<port>/<pathname>
           Connects to an existing bkd  on  the  specified  port,
           changes to <pathname>, then runs command.

   HTTPD
       http://<host>:<port>/<relative>/<path>
           Connects  to  the  specified  port  via  the hypertext
           transfer protocol, changes to pathname, then runs  the
           command.  Where <relative>/<path> is the relative path
           from the root of the repository.
       http://<host>:<port>//<full>/<path>
           Connects to  the  specified  port  via  the  hypertext
           transfer  protocol, changes to pathname, then runs the
           command.  Where <full>/<path> is the absolute path.
       http://<host>:<port>
           Same as above, except that it assumes that the pwd  of
           the bkd is the root of the source repository.

PROXIES
       BitKeeper supports http proxy via environment variables on
       Unix systems and via the registry on win32 systems.

       The following are the Unix  environment  variable  options
       available for use.

           HTTP_PROXY_HOST=<host_name>
           HTTP_PROXY_PORT=<port_number>

           http_proxy=http://<host>:<port>
           http_proxy=http://[<user>:<pass>@]<host>:<port>/
           no_proxy=<comma,seperated,list,of,hosts,to,not,proxy>

           SOCKS_HOST=<host_name>
           SOCKS_PORT=<port_number>

           SOCKS_SERVER=<host>:<port>

       Note: if HTTP_PROXY_HOST is set, HTTP_PROXY_PORT must also
       be set.  Likewise for SOCKS_HOST and SOCKS_PORT.   If  you
       are  not  sure  if  you  should set environment variables,
       please consult your system administrator.

CATEGORY
       Repository
       Overview

BitMover, Inc               2003/02/21                          1
$
help://users
help://users.1
help://bk-users
help://bk-users.1

bk users(1)          BitKeeper User's Manual          bk users(1)

NAME
       bk users - list users of a repository

SYNOPSIS
       bk users -cr [<repository>]

DESCRIPTION
       The  users  command  lists  the email addresses of all the
       people who have made modifications  to  the  tree.   Alias
       names  are  converted to the canonical user name before it
       is printed. The output looks like this:

           $ bk users
           preacher@bitmover.com
           maya@bitmover.com
           digger@bitmover.com
           fussy@bitmover.com

OPTIONS
       -c     print the user count
       -r     print the raw  user  list  (i.e  ignore  the  alias
              database)

CATEGORY
       Admin

BitMover, Inc               2002/09/17                          1
$
help://version
help://version.1
help://bk-version
help://bk-version.1

bk version(1)        BitKeeper User's Manual        bk version(1)

NAME
       bk version - print BitKeeper version

SYNOPSIS
       bk version

DESCRIPTION
       The  version  command  shows what version of BitKeeper you
       are running.  If the version is symbolically  named  (most
       are), the version will look like:

           BitKeeper version is BETA-1 for x86-linux
           Built by: lm@work.bitmover.com
           Built on: Wed Feb 23 20:20:03 PST 2000

       The version output for a development snapshot looks like:

           BitKeeper version is 20000224020659 for x86-linux
           Built by: lm@work.bitmover.com
           Built on: Wed Feb 23 20:20:03 PST 2000

       The timestamp value in the snapshot release is the time of
       the most recent file  modification  within  the  BitKeeper
       source code.

NOTE
       BitMover,  Inc  provides  support  for symbolically-tagged
       version only.  The snapshot versions are completely unsup-
       ported.

CATEGORY
       Admin
       Common

BitMover, Inc               2002/09/17                          1
$
help://what
help://what.1
help://bk-what
help://bk-what.1

bk what(1)           BitKeeper User's Manual           bk what(1)

NAME
       bk what - look for SCCS what strings

SYNOPSIS
       bk what [<file> ...]

DESCRIPTION
       The  bk  what  command looks through the specified list of
       file[s] for strings  which  start  with  the  SCCS  "what"
       string  "@(#)",  which  can  be  stated as %Z% in a source
       file, and prints the entire string.

       If a C program contains

           char sccsid[] = "@(#)some ident info";

       and the program is compiled to yield a program a.out, then
       the command

           what a.out

       will produce

           a.out:
               some ident info

SEE ALSO
       bk help keywords

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://wrap
help://wrap.1
help://bk-wrap
help://bk-wrap.1

bk wrap(1)           BitKeeper User's Manual           bk wrap(1)

NAME
       bk wrap - using BitKeeper wrappers

DESCRIPTION
       For various reasons, you may wish to wrap a patch which is
       transmitted through email.  The typical reason is that the
       patch  is going through some mailer which chops long lines
       or performs some  other  unwanted  transformation  on  the
       data.   Wrapping  is typically done via the bk send inter-
       face with the -w option.

       The following two commands produce identical data:

           $ ls -1 | bk uuwrap | bk unuuwrap
           $ ls -1

       The current set of wrappers are:

           b64wrap - wrap data using base 64 encoding
           gzip_b64wrap - gzip the data and then base 64 encode the zipped data
           gzip_uuwrap - gzip the data and then uuencode the zipped data
           uuwrap - wrap the data using uuencode

SEE ALSO
       bk help base64
       bk help send
       bk help receive

CATEGORY
       File

BitMover, Inc               2002/11/19                          1
$
help://xflags
help://xflags.1
help://bk-xflags
help://bk-xflags.1

bk xflags(1)         BitKeeper User's Manual         bk xflags(1)

NAME
       bk xflags - check or fix BitKeeper flags

SYNOPSIS
       bk -r xflags [-ns] [<file> ...]

DESCRIPTION
       Xflags  is  an administrative command used to check and/or
       fix BitKeeper flags.  These flags control things  such  as
       what sort of keywords are expanded.

       This  command should not be typically needed, it exists to
       fix older repositories which  did  not  properly  maintain
       these flags.  If bk check yields output like

           src/utils/Makefile@@1.12 should have EXPAND1 flag
           src/utils/README@@1.3 should have SCCS flag
           src/DOCS: missing required flag[s]: BITKEEPER

       bk xflags needs to be run.

       With  no  options,  bk xflags will fix the flags in all of
       the specified files.  To fix all files, run

           bk -r xflags

OPTIONS
       -n     Do not change any files,  just  list  any  problems
              found.
       -s     Do  not  change  any files, do not list any status,
              just exit 0 if no problems were found,  exit  1  if
              problems were found.

SEE ALSO
       bk help admin
       bk help check

CATEGORY
       File

BitMover, Inc               2002/09/17                          1
$
help://zone
help://zone.1
help://bk-zone
help://bk-zone.1

bk zone(1)           BitKeeper User's Manual           bk zone(1)

NAME
       bk zone - print BitKeeper's view of the timezone

SYNOPSIS
       bk zone

DESCRIPTION
       Prints  the  timezone  as an offset from GMT, i.e., PST is
       -08:00, PDT is -07:00.

CATEGORY
       Utility

BitMover, Inc               2002/09/17                          1
$
help://diff
help://diff.1

DIFF(1)                     GNU Tools                     DIFF(1)

NAME
       diff - find differences between two files

SYNOPSIS
       diff [options] from-file to-file

DESCRIPTION
       In  the  simplest  case, diff compares the contents of the
       two files from-file and to-file.  A file name of -  stands
       for text read from the standard input.  As a special case,
       diff - - compares a copy of standard input to itself.

       If from-file is a directory and to-file is not, diff  com-
       pares the file in from-file whose file name is that of to-
       file, and vice versa.  The non-directory file must not  be
       -.

       If  both  from-file and to-file are directories, diff com-
       pares corresponding files in both directories,  in  alpha-
       betical order; this comparison is not recursive unless the
       -r or --recursive option is given.   diff  never  compares
       the  actual  contents of a directory as if it were a file.
       The file that is  fully  specified  may  not  be  standard
       input,  because  standard input is nameless and the notion
       of ``file with the same name'' does not apply.

       diff options begin with -, so normally from-file  and  to-
       file  may not begin with -.  However, -- as an argument by
       itself treats the remaining arguments as file  names  even
       if they begin with -.

   Options
       Below  is  a  summary  of all of the options that GNU diff
       accepts.  Most options have two equivalent names,  one  of
       which  is  a single letter preceded by -, and the other of
       which is a long name preceded by --.  Multiple single let-
       ter options (unless they take an argument) can be combined
       into a single command line word: -ac is equivalent  to  -a
       -c.   Long  named options can be abbreviated to any unique
       prefix of their name.  Brackets ([ and ]) indicate that an
       option takes an optional argument.

       -lines Show  lines  (an  integer)  lines of context.  This
              option does not specify an output format by itself;
              it  has  no effect unless it is combined with -c or
              -u.  This option is obsolete.   For  proper  opera-
              tion,  patch  typically needs at least two lines of
              context.

       -a     Treat all files as text and compare  them  line-by-
              line, even if they do not seem to be text.

       -b     Ignore changes in amount of white space.

       -B     Ignore  changes  that  just  insert or delete blank
              lines.

       --brief
              Report only  whether  the  files  differ,  not  the
              details of the differences.

       -c     Use the context output format.

       -C lines
       --context[=lines]
              Use  the  context  output format, showing lines (an
              integer) lines of context, or three if lines is not
              given.  For proper operation, patch typically needs
              at least two lines of context.

       --changed-group-format=format
              Use format to output a line group  containing  dif-
              fering  lines  from both files in if-then-else for-
              mat.

       -d     Change the algorithm to perhaps find a smaller  set
              of changes.  This makes diff slower (sometimes much
              slower).

       -D name
              Make merged if-then-else format output, conditional
              on the preprocessor macro name.

       -e
       --ed   Make output that is a valid ed script.

       --exclude=pattern
              When comparing directories, ignore files and subdi-
              rectories whose basenames match pattern.

       --exclude-from=file
              When comparing directories, ignore files and subdi-
              rectories  whose  basenames  match any pattern con-
              tained in file.

       --expand-tabs
              Expand tabs to spaces in the  output,  to  preserve
              the alignment of tabs in the input files.

       -f     Make  output  that  looks vaguely like an ed script
              but has changes in the order  they  appear  in  the
              file.

       -F regexp
              In  context  and  unified  format, for each hunk of
              differences, show some of the last  preceding  line
              that matches regexp.

       --forward-ed
              Make  output  that  looks vaguely like an ed script
              but has changes in the order  they  appear  in  the
              file.

       -h     This  option currently has no effect; it is present
              for Unix compatibility.

       -H     Use heuristics to speed  handling  of  large  files
              that have numerous scattered small changes.

       --horizon-lines=lines
              Do  not  discard the last lines lines of the common
              prefix and the first lines lines of the common suf-
              fix.

       -i     Ignore  changes in case; consider upper- and lower-
              case letters equivalent.

       -I regexp
              Ignore changes that just  insert  or  delete  lines
              that match regexp.

       --ifdef=name
              Make merged if-then-else format output, conditional
              on the preprocessor macro name.

       --ignore-all-space
              Ignore white space when comparing lines.

       --ignore-blank-lines
              Ignore changes that just  insert  or  delete  blank
              lines.

       --ignore-case
              Ignore  changes in case; consider upper- and lower-
              case to be the same.

       --ignore-matching-lines=regexp
              Ignore changes that just  insert  or  delete  lines
              that match regexp.

       --ignore-space-change
              Ignore changes in amount of white space.

       --initial-tab
              Output a tab rather than a space before the text of
              a line in normal or context  format.   This  causes
              the alignment of tabs in the line to look normal.

       -l     Pass the output through pr to paginate it.

       -L label
       --label=label
              Use  label  instead of the file name in the context
              format and unified format headers.

       --left-column
              Print only the left column of two common  lines  in
              side by side format.

       --line-format=format
              Use  format  to  output all input lines in in-then-
              else format.

       --minimal
              Change the algorithm to perhaps find a smaller  set
              of changes.  This makes diff slower (sometimes much
              slower).

       -n     Output RCS-format diffs; like -f except  that  each
              command specifies the number of lines affected.

       -N
       --new-file
              In directory comparison, if a file is found in only
              one directory, treat it as present but empty in the
              other directory.

       --new-group-format=format
              Use  format  to  output a group of lines taken from
              just the second file in if-then-else format.

       --new-line-format=format
              Use format to output a line  taken  from  just  the
              second file in if-then-else format.

       --old-group-format=format
              Use  format  to  output a group of lines taken from
              just the first file in if-then-else format.

       --old-line-format=format
              Use format to output a line  taken  from  just  the
              first file in if-then-else format.

       -p     Show which C function each change is in.

       -P     When  comparing directories, if a file appears only
              in the second directory of the  two,  treat  it  as
              present but empty in the other.

       --paginate
              Pass the output through pr to paginate it.

       -q     Report  only  whether  the  files  differ,  not the
              details of the differences.

       -r     When comparing directories, recursively compare any
              subdirectories found.

       --rcs  Output  RCS-format  diffs; like -f except that each
              command specifies the number of lines affected.

       --recursive
              When comparing directories, recursively compare any
              subdirectories found.

       --report-identical-files
       -s     Report when two files are the same.

       -S file
              When  comparing  directories,  start  with the file
              file.  This is used for resuming an aborted compar-
              ison.

       --from-file=file
              Compare file to all operands.  file can be a direc-
              tory.

       --to-file=file
              Compare all operands to file. file can be a  direc-
              tory.

       --sdiff-merge-assist
              Print  extra information to help sdiff.  sdiff uses
              this option when it runs diff.  This option is  not
              intended for users to use directly.

       --show-c-function
              Show which C function each change is in.

       --show-function-line=regexp
              In  context  and  unified  format, for each hunk of
              differences, show some of the last  preceding  line
              that matches regexp.

       --side-by-side
              Use the side by side output format.

       --speed-large-files
              Use  heuristics  to  speed  handling of large files
              that have numerous scattered small changes.

       --starting-file=file
              When comparing directories,  start  with  the  file
              file.  This is used for resuming an aborted compar-
              ison.

       --suppress-common-lines
              Do not print common lines in side by side format.

       -t     Expand tabs to spaces in the  output,  to  preserve
              the alignment of tabs in the input files.

       -T     Output a tab rather than a space before the text of
              a line in normal or context  format.   This  causes
              the alignment of tabs in the line to look normal.

       --text Treat  all  files as text and compare them line-by-
              line, even if they do not appear to be text.

       -u     Use the unified output format.

       --unchanged-group-format=format
              Use format to output a group of common lines  taken
              from both files in if-then-else format.

       --unchanged-line-format=format
              Use format to output a line common to both files in
              if-then-else format.

       --unidirectional-new-file
              When comparing directories, if a file appears  only
              in  the  second  directory  of the two, treat it as
              present but empty in the other.

       -U lines
       --unified[=lines]
              Use the unified output format,  showing  lines  (an
              integer) lines of context, or three if lines is not
              given.  For proper operation, patch typically needs
              at least two lines of context.

       -v
       --version
              Output the version number of diff.

       -w     Ignore white space when comparing lines.

       -W columns
       --width=columns
              Use an output width of columns in side by side for-
              mat.

       -x pattern
              When comparing directories, ignore files and subdi-
              rectories whose basenames match pattern.

       -X file
              When comparing directories, ignore files and subdi-
              rectories whose basenames match  any  pattern  con-
              tained in file.

       -y     Use the side by side output format.

SOURCE
       The  source  code for the versions of GNU tools shipped by
       BitMover is available at ftp://ftp.bitmover.com/gnu.

SEE ALSO
       bk help gpl
       cmp(1),  comm(1),  diff3(1),   ed(1),   patch(1),   pr(1),
       sdiff(1).

DIAGNOSTICS
       An  exit  status  of  0 means no differences were found, 1
       means some differences were found, and 2 means trouble.

GNU Tools                   22sep1993                           1
$
help://gpl
help://gpl.1

GPL(1)                         GPL                         GPL(1)

NAME
       gpl - GNU GENERAL PUBLIC LICENSE Version 2, June 1991

WHY
       The  GPL text is included with BitKeeper because BitKeeper
       includes the GNU packages diffutils and patch.  These pro-
       grams,  and  these programs only, are the only part of the
       BitKeeper system covered by the GPL.

GPL
                     GNU GENERAL PUBLIC LICENSE
                        Version 2, June 1991

        Copyright (C) 1989, 1991 Free Software Foundation, Inc.
        59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
        Everyone is permitted to copy and distribute verbatim copies
        of this license document, but changing it is not allowed.

                          Preamble

       The licenses for most software are designed to take away your
       freedom to share and change it.  By contrast, the GNU General Public
       License is intended to guarantee your freedom to share and change free
       software--to make sure the software is free for all its users.  This
       General Public License applies to most of the Free Software
       Foundation's software and to any other program whose authors commit to
       using it.  (Some other Free Software Foundation software is covered by
       the GNU Library General Public License instead.)  You can apply it to
       your programs, too.

       When we speak of free software, we are referring to freedom, not
       price.  Our General Public Licenses are designed to make sure that you
       have the freedom to distribute copies of free software (and charge for
       this service if you wish), that you receive source code or can get it
       if you want it, that you can change the software or use pieces of it
       in new free programs; and that you know you can do these things.

       To protect your rights, we need to make restrictions that forbid
       anyone to deny you these rights or to ask you to surrender the rights.
       These restrictions translate to certain responsibilities for you if you
       distribute copies of the software, or if you modify it.

       For example, if you distribute copies of such a program, whether
       gratis or for a fee, you must give the recipients all the rights that
       you have.  You must make sure that they, too, receive or can get the
       source code.  And you must show them these terms so they know their
       rights.

       We protect your rights with two steps: (1) copyright the software, and
       (2) offer you this license which gives you legal permission to copy,
       distribute and/or modify the software.

       Also, for each author's protection and ours, we want to make certain
       that everyone understands that there is no warranty for this free
       software.  If the software is modified by someone else and passed on, we
       want its recipients to know that what they have is not the original, so
       that any problems introduced by others will not reflect on the original
       authors' reputations.

       Finally, any free program is threatened constantly by software
       patents.  We wish to avoid the danger that redistributors of a free
       program will individually obtain patent licenses, in effect making the
       program proprietary.  To prevent this, we have made it clear that any
       patent must be licensed for everyone's free use or not licensed at all.

       The precise terms and conditions for copying, distribution and
       modification follow.

                     GNU GENERAL PUBLIC LICENSE
          TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

       0. This License applies to any program or other work which contains
       a notice placed by the copyright holder saying it may be distributed
       under the terms of this General Public License.  The "Program", below,
       refers to any such program or work, and a "work based on the Program"
       means either the Program or any derivative work under copyright law:
       that is to say, a work containing the Program or a portion of it,
       either verbatim or with modifications and/or translated into another
       language.  (Hereinafter, translation is included without limitation in
       the term "modification".)  Each licensee is addressed as "you".

       Activities other than copying, distribution and modification are not
       covered by this License; they are outside its scope.  The act of
       running the Program is not restricted, and the output from the Program
       is covered only if its contents constitute a work based on the
       Program (independent of having been made by running the Program).
       Whether that is true depends on what the Program does.

       1. You may copy and distribute verbatim copies of the Program's
       source code as you receive it, in any medium, provided that you
       conspicuously and appropriately publish on each copy an appropriate
       copyright notice and disclaimer of warranty; keep intact all the
       notices that refer to this License and to the absence of any warranty;
       and give any other recipients of the Program a copy of this License
       along with the Program.

       You may charge a fee for the physical act of transferring a copy, and
       you may at your option offer warranty protection in exchange for a fee.

       2. You may modify your copy or copies of the Program or any portion
       of it, thus forming a work based on the Program, and copy and
       distribute such modifications or work under the terms of Section 1
       above, provided that you also meet all of these conditions:

           a) You must cause the modified files to carry prominent notices
           stating that you changed the files and the date of any change.

           b) You must cause any work that you distribute or publish, that in
           whole or in part contains or is derived from the Program or any
           part thereof, to be licensed as a whole at no charge to all third
           parties under the terms of this License.

           c) If the modified program normally reads commands interactively
           when run, you must cause it, when started running for such
           interactive use in the most ordinary way, to print or display an
           announcement including an appropriate copyright notice and a
           notice that there is no warranty (or else, saying that you provide
           a warranty) and that users may redistribute the program under
           these conditions, and telling the user how to view a copy of this
           License.  (Exception: if the Program itself is interactive but
           does not normally print such an announcement, your work based on
           the Program is not required to print an announcement.)

       These requirements apply to the modified work as a whole.  If
       identifiable sections of that work are not derived from the Program,
       and can be reasonably considered independent and separate works in
       themselves, then this License, and its terms, do not apply to those
       sections when you distribute them as separate works.  But when you
       distribute the same sections as part of a whole which is a work based
       on the Program, the distribution of the whole must be on the terms of
       this License, whose permissions for other licensees extend to the
       entire whole, and thus to each and every part regardless of who wrote it.

       Thus, it is not the intent of this section to claim rights or contest
       your rights to work written entirely by you; rather, the intent is to
       exercise the right to control the distribution of derivative or
       collective works based on the Program.

       In addition, mere aggregation of another work not based on the Program
       with the Program (or with a work based on the Program) on a volume of
       a storage or distribution medium does not bring the other work under
       the scope of this License.

       3. You may copy and distribute the Program (or a work based on it,
       under Section 2) in object code or executable form under the terms of
       Sections 1 and 2 above provided that you also do one of the following:

           a) Accompany it with the complete corresponding machine-readable
           source code, which must be distributed under the terms of Sections
           1 and 2 above on a medium customarily used for software interchange; or,

           b) Accompany it with a written offer, valid for at least three
           years, to give any third party, for a charge no more than your
           cost of physically performing source distribution, a complete
           machine-readable copy of the corresponding source code, to be
           distributed under the terms of Sections 1 and 2 above on a medium
           customarily used for software interchange; or,

           c) Accompany it with the information you received as to the offer
           to distribute corresponding source code.  (This alternative is
           allowed only for noncommercial distribution and only if you
           received the program in object code or executable form with such
           an offer, in accord with Subsection b above.)

       The source code for a work means the preferred form of the work for
       making modifications to it.  For an executable work, complete source
       code means all the source code for all modules it contains, plus any
       associated interface definition files, plus the scripts used to
       control compilation and installation of the executable.  However, as a
       special exception, the source code distributed need not include
       anything that is normally distributed (in either source or binary
       form) with the major components (compiler, kernel, and so on) of the
       operating system on which the executable runs, unless that component
       itself accompanies the executable.

       If distribution of executable or object code is made by offering
       access to copy from a designated place, then offering equivalent
       access to copy the source code from the same place counts as
       distribution of the source code, even though third parties are not
       compelled to copy the source along with the object code.

       4. You may not copy, modify, sublicense, or distribute the Program
       except as expressly provided under this License.  Any attempt
       otherwise to copy, modify, sublicense or distribute the Program is
       void, and will automatically terminate your rights under this License.
       However, parties who have received copies, or rights, from you under
       this License will not have their licenses terminated so long as such
       parties remain in full compliance.

       5. You are not required to accept this License, since you have not
       signed it.  However, nothing else grants you permission to modify or
       distribute the Program or its derivative works.  These actions are
       prohibited by law if you do not accept this License.  Therefore, by
       modifying or distributing the Program (or any work based on the
       Program), you indicate your acceptance of this License to do so, and
       all its terms and conditions for copying, distributing or modifying
       the Program or works based on it.

       6. Each time you redistribute the Program (or any work based on the
       Program), the recipient automatically receives a license from the
       original licensor to copy, distribute or modify the Program subject to
       these terms and conditions.  You may not impose any further
       restrictions on the recipients' exercise of the rights granted herein.
       You are not responsible for enforcing compliance by third parties to
       this License.

       7. If, as a consequence of a court judgment or allegation of patent
       infringement or for any other reason (not limited to patent issues),
       conditions are imposed on you (whether by court order, agreement or
       otherwise) that contradict the conditions of this License, they do not
       excuse you from the conditions of this License.  If you cannot
       distribute so as to satisfy simultaneously your obligations under this
       License and any other pertinent obligations, then as a consequence you
       may not distribute the Program at all.  For example, if a patent
       license would not permit royalty-free redistribution of the Program by
       all those who receive copies directly or indirectly through you, then
       the only way you could satisfy both it and this License would be to
       refrain entirely from distribution of the Program.

       If any portion of this section is held invalid or unenforceable under
       any particular circumstance, the balance of the section is intended to
       apply and the section as a whole is intended to apply in other
       circumstances.

       It is not the purpose of this section to induce you to infringe any
       patents or other property right claims or to contest validity of any
       such claims; this section has the sole purpose of protecting the
       integrity of the free software distribution system, which is
       implemented by public license practices.  Many people have made
       generous contributions to the wide range of software distributed
       through that system in reliance on consistent application of that
       system; it is up to the author/donor to decide if he or she is willing
       to distribute software through any other system and a licensee cannot
       impose that choice.

       This section is intended to make thoroughly clear what is believed to
       be a consequence of the rest of this License.

       8. If the distribution and/or use of the Program is restricted in
       certain countries either by patents or by copyrighted interfaces, the
       original copyright holder who places the Program under this License
       may add an explicit geographical distribution limitation excluding
       those countries, so that distribution is permitted only in or among
       countries not thus excluded.  In such case, this License incorporates
       the limitation as if written in the body of this License.

       9. The Free Software Foundation may publish revised and/or new versions
       of the General Public License from time to time.  Such new versions will
       be similar in spirit to the present version, but may differ in detail to
       address new problems or concerns.

       Each version is given a distinguishing version number.  If the Program
       specifies a version number of this License which applies to it and "any
       later version", you have the option of following the terms and conditions
       either of that version or of any later version published by the Free
       Software Foundation.  If the Program does not specify a version number of
       this License, you may choose any version ever published by the Free Software
       Foundation.

       10. If you wish to incorporate parts of the Program into other free
       programs whose distribution conditions are different, write to the author
       to ask for permission.  For software which is copyrighted by the Free
       Software Foundation, write to the Free Software Foundation; we sometimes
       make exceptions for this.  Our decision will be guided by the two goals
       of preserving the free status of all derivatives of our free software and
       of promoting the sharing and reuse of software generally.

                          NO WARRANTY

       11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
       FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
       OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
       PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
       OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
       MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
       TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
       PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
       REPAIR OR CORRECTION.

       12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
       WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
       REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
       INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
       OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
       TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
       YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
       PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
       POSSIBILITY OF SUCH DAMAGES.

                      END OF TERMS AND CONDITIONS

            How to Apply These Terms to Your New Programs

       If you develop a new program, and you want it to be of the greatest
       possible use to the public, the best way to achieve this is to make it
       free software which everyone can redistribute and change under these terms.

       To do so, attach the following notices to the program.  It is safest
       to attach them to the start of each source file to most effectively
       convey the exclusion of warranty; and each file should have at least
       the "copyright" line and a pointer to where the full notice is found.

           <one line to give the program's name and a brief idea of what it does.>
           Copyright (C) 19yy  <name of author>

           This program is free software; you can redistribute it and/or modify
           it under the terms of the GNU General Public License as published by
           the Free Software Foundation; either version 2 of the License, or
           (at your option) any later version.

           This program is distributed in the hope that it will be useful,
           but WITHOUT ANY WARRANTY; without even the implied warranty of
           MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
           GNU General Public License for more details.

           You should have received a copy of the GNU General Public License
           along with this program; if not, write to the Free Software
           Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

       Also add information on how to contact you by electronic and paper mail.

       If the program is interactive, make it output a short notice like this
       when it starts in an interactive mode:

           Gnomovision version 69, Copyright (C) 19yy name of author
           Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
           This is free software, and you are welcome to redistribute it
           under certain conditions; type `show c' for details.

       The hypothetical commands `show w' and `show c' should show the appropriate
       parts of the General Public License.  Of course, the commands you use may
       be called something other than `show w' and `show c'; they could even be
       mouse-clicks or menu items--whatever suits your program.

       You should also get your employer (if you work as a programmer) or your
       school, if any, to sign a "copyright disclaimer" for the program, if
       necessary.  Here is a sample; alter the names:

         Yoyodyne, Inc., hereby disclaims all copyright interest in the program
         `Gnomovision' (which makes passes at compilers) written by James Hacker.

         <signature of Ty Coon>, 1 April 1989
         Ty Coon, President of Vice

       This General Public License does not permit incorporating your program into
       proprietary programs.  If your program is a subroutine library, you may
       consider it more useful to permit linking proprietary applications with the
       library.  If this is what you want to do, use the GNU Library General
       Public License instead of this License.

SOURCE
       The source code for the versions of GNU tools  shipped  by
       BitMover is available at ftp://ftp.bitmover.com/gnu.

CATEGORY
       Licensing

GPL                         2002/09/17                          1
$
help://patch
help://patch.1

PATCH(1)                                                 PATCH(1)

NAME
       patch - apply a diff file to an original

SYNOPSIS
       patch [options] [originalfile [patchfile]]

       but usually just

       patch -pnum <patchfile

DESCRIPTION
       patch takes a patch file patchfile containing a difference
       listing produced by the diff  program  and  applies  those
       differences  to  one  or  more  original  files, producing
       patched versions.  Normally the patched versions  are  put
       in  place  of the originals.  Backups can be made; see the
       -b or --backup option.  The  names  of  the  files  to  be
       patched  are  usually  taken  from  the patch file, but if
       there's just one file to be patched it  can  specified  on
       the command line as originalfile.

       Upon  startup, patch attempts to determine the type of the
       diff listing, unless overruled by  a  -c  (--context),  -e
       (--ed),  -n (--normal), or -u (--unified) option.  Context
       diffs (old-style, new-style, and unified) and normal diffs
       are  applied  by  the patch program itself, while ed diffs
       are simply fed to the ed(1) editor via a pipe.

       patch tries to skip any leading garbage, apply  the  diff,
       and  then  skip any trailing garbage.  Thus you could feed
       an article or message containing a diff listing to  patch,
       and  it  should work.  If the entire diff is indented by a
       consistent amount, or if a  context  diff  contains  lines
       ending  in  CRLF  or  is encapsulated one or more times by
       prepending "- " to lines starting with "-" as specified by
       Internet RFC 934, this is taken into account.

       With  context  diffs,  and  to a lesser extent with normal
       diffs, patch can detect when the line numbers mentioned in
       the  patch are incorrect, and attempts to find the correct
       place to apply each hunk of the patch.  As a first  guess,
       it  takes  the line number mentioned for the hunk, plus or
       minus any offset used in applying the previous  hunk.   If
       that  is  not the correct place, patch scans both forwards
       and backwards for a set  of  lines  matching  the  context
       given  in  the  hunk.  First patch looks for a place where
       all lines of the context  match.   If  no  such  place  is
       found,  and it's a context diff, and the maximum fuzz fac-
       tor is set to 1 or more, then  another  scan  takes  place
       ignoring  the  first  and  last  line of context.  If that
       fails, and the maximum fuzz factor is set to  2  or  more,
       the  first  two and last two lines of context are ignored,
       and another scan is made.  (The default maximum fuzz  fac-
       tor  is  2.)  If patch cannot find a place to install that
       hunk of the patch, it puts the hunk out to a reject  file,
       which  normally is the name of the output file plus a .rej
       suffix, or # if .rej would generate a file  name  that  is
       too  long  (if even appending the single character # makes
       the file name too long, then # replaces  the  file  name's
       last character).  (The rejected hunk comes out in ordinary
       context diff form regardless of the  input  patch's  form.
       If  the  input was a normal diff, many of the contexts are
       simply null.)  The line numbers on the hunks in the reject
       file may be different than in the patch file: they reflect
       the approximate location patch  thinks  the  failed  hunks
       belong in the new file rather than the old one.

       As  each  hunk  is  completed,  you  are  told if the hunk
       failed, and if so which  line  (in  the  new  file)  patch
       thought  the  hunk should go on.  If the hunk is installed
       at a different line from the line number specified in  the
       diff  you  are told the offset.  A single large offset may
       indicate that a hunk was installed  in  the  wrong  place.
       You  are  also  told if a fuzz factor was used to make the
       match, in which case you should also  be  slightly  suspi-
       cious.   If  the  --verbose  option is given, you are also
       told about hunks that match exactly.

       If no original file origfile is specified on  the  command
       line,  patch  tries to figure out from the leading garbage
       what the name of the file to edit is, using the  following
       rules.

       First, patch takes an ordered list of candidate file names
       as follows:

        +o If the header is that of a context  diff,  patch  takes
          the  old  and  new file names in the header.  A name is
          ignored if it does not have enough slashes  to  satisfy
          the -pnum or --strip=num option.  The name /dev/null is
          also ignored.

        +o If there is an Index: line in the leading  garbage  and
          if  either  the old and new names are both absent or if
          patch is conforming to POSIX, patch takes the  name  in
          the Index: line.

        +o For  the  purpose of the following rules, the candidate
          file names are considered to be in the order (old, new,
          index), regardless of the order that they appear in the
          header.

       Then patch selects a file name from the candidate list  as
       follows:

        +o If  some  of  the  named files exist, patch selects the
          first name if conforming to POSIX, and  the  best  name
          otherwise.

        +o If  patch is not ignoring RCS, ClearCase, and SCCS (see
          the -g num or --get=num option),  and  no  named  files
          exist  but  an RCS, ClearCase, or SCCS master is found,
          patch  selects  the  first  named  file  with  an  RCS,
          ClearCase, or SCCS master.

        +o If  no  named  files  exist, no RCS, ClearCase, or SCCS
          master was found, some names are given,  patch  is  not
          conforming  to POSIX, and the patch appears to create a
          file, patch selects the best name  requiring  the  cre-
          ation of the fewest directories.

        +o If  no file name results from the above heuristics, you
          are asked for the name of the file to patch, and  patch
          selects that name.

       To  determine  the  best of a nonempty list of file names,
       patch first takes all the names with the fewest path  name
       components; of those, it then takes all the names with the
       shortest basename; of those, it then takes all the  short-
       est names; finally, it takes the first remaining name.

       Additionally,  if  the  leading garbage contains a Prereq:
       line, patch takes the first word  from  the  prerequisites
       line  (normally  a version number) and checks the original
       file to see if that word can be found.  If not, patch asks
       for confirmation before proceeding.

       The  upshot of all this is that you should be able to say,
       while in a news interface, something like the following:

          | patch -d /usr/src/local/blurfl

       and patch a file in the blurfl directory directly from the
       article containing the patch.

       If  the  patch  file  contains  more than one patch, patch
       tries to apply each of them as if they came from  separate
       patch  files.   This means, among other things, that it is
       assumed that the name of the file to patch must be  deter-
       mined  for  each diff listing, and that the garbage before
       each diff listing contains interesting things such as file
       names and revision level, as mentioned previously.

OPTIONS
       -b  or  --backup
          Make  backup  files.   That  is,  when patching a file,
          rename or copy the original  instead  of  removing  it.
          When  backing  up a file that does not exist, an empty,
          unreadable backup file is created as a  placeholder  to
          represent  the  nonexistent file.  See the -V or --ver-
          sion-control option for details about how  backup  file
          names are determined.

       --backup-if-mismatch
          Back  up  a  file  if the patch does not match the file
          exactly and if backups  are  not  otherwise  requested.
          This  is  the  default  unless  patch  is conforming to
          POSIX.

       --no-backup-if-mismatch
          Do not back up a file if the patch does not  match  the
          file   exactly   and   if  backups  are  not  otherwise
          requested.  This is the default if patch is  conforming
          to POSIX.

       -B pref  or  --prefix=pref
          Prefix  pref  to a file name when generating its simple
          backup file name.  For example, with -B /junk/ the sim-
          ple   backup   file   name   for   src/patch/util.c  is
          /junk/src/patch/util.c.

       --binary
          Read and write all files in  binary  mode,  except  for
          standard  output  and  /dev/tty.   This  option  has no
          effect on POSIX-conforming systems.   On  systems  like
          DOS  where  this  option  makes a difference, the patch
          should be generated by diff -a --binary.

       -c  or  --context
          Interpret the patch file as a ordinary context diff.

       -d dir  or  --directory=dir
          Change to the directory dir immediately,  before  doing
          anything else.

       -D define  or  --ifdef=define
          Use  the  #ifdef  ... #endif construct to mark changes,
          with define as the differentiating symbol.

       --dry-run
          Print the results of applying the patches without actu-
          ally changing any files.

       -e  or  --ed
          Interpret the patch file as an ed script.

       -E  or  --remove-empty-files
          Remove  output  files  that are empty after the patches
          have been applied.  Normally this  option  is  unneces-
          sary,  since  patch  can examine the time stamps on the
          header to determine whether a file should  exist  after
          patching.   However, if the input is not a context diff
          or if patch is conforming  to  POSIX,  patch  does  not
          remove empty patched files unless this option is given.
          When patch removes a file, it also attempts  to  remove
          any empty ancestor directories.

       -f  or  --force
          Assume  that  the  user knows exactly what he or she is
          doing, and do not  ask  any  questions.   Skip  patches
          whose  headers  do not say which file is to be patched;
          patch files even though they have the wrong version for
          the  Prereq: line in the patch; and assume that patches
          are not reversed even if they look like they are.  This
          option does not suppress commentary; use -s for that.

       -F num  or  --fuzz=num
          Set  the maximum fuzz factor.  This option only applies
          to diffs that have context, and causes patch to  ignore
          up  to that many lines in looking for places to install
          a hunk.  Note that a larger fuzz factor  increases  the
          odds  of a faulty patch.  The default fuzz factor is 2,
          and it may not be set to more than the number of  lines
          of context in the context diff, ordinarily 3.

       -g num  or  --get=num
          This  option  controls  patch's  actions when a file is
          under RCS or SCCS control, and does  not  exist  or  is
          read-only  and  matches  the default version, or when a
          file is under ClearCase control and does not exist.  If
          num  is  positive,  patch gets (or checks out) the file
          from  the  revision  control  system;  if  zero,  patch
          ignores  RCS,  ClearCase, and SCCS and does not get the
          file; and if negative, patch asks the user  whether  to
          get  the  file.   The  default  value of this option is
          given by the value of the PATCH_GET  environment  vari-
          able if it is set; if not, the default value is zero if
          patch is conforming to POSIX, negative otherwise.

       --help
          Print a summary of options and exit.

       -i patchfile  or  --input=patchfile
          Read the patch from patchfile.  If patchfile is -, read
          from standard input, the default.

       -l  or  --ignore-whitespace
          Match  patterns  loosely,  in  case tabs or spaces have
          been munged in your files.  Any sequence of one or more
          blanks  in  the  patch file matches any sequence in the
          original file, and sequences of blanks at the  ends  of
          lines  are ignored.  Normal characters must still match
          exactly.  Each line of the context must still  match  a
          line in the original file.

       -n  or  --normal
          Interpret the patch file as a normal diff.

       -N  or  --forward
          Ignore  patches  that  seem  to  be reversed or already
          applied.  See also -R.

       -o outfile  or  --output=outfile
          Send output to outfile instead  of  patching  files  in
          place.

       -pnum  or  --strip=num
          Strip   the  smallest  prefix  containing  num  leading
          slashes from each file name found in the patch file.  A
          sequence  of one or more adjacent slashes is counted as
          a single slash.  This controls how file names found  in
          the patch file are treated, in case you keep your files
          in a different directory than the person who  sent  out
          the patch.  For example, supposing the file name in the
          patch file was

             /u/howard/src/blurfl/blurfl.c

          setting -p0 gives the entire file name unmodified,  -p1
          gives

             u/howard/src/blurfl/blurfl.c

          without the leading slash, -p4 gives

             blurfl/blurfl.c

          and  not  specifying -p at all just gives you blurfl.c.
          Whatever you end up with is looked for  either  in  the
          current directory, or the directory specified by the -d
          option.

       --posix
          Conform more strictly to the POSIX  standard,  as  fol-
          lows.

           +o Take  the  first  existing  file from the list (old,
             new, index) when  intuiting  file  names  from  diff
             headers.

           +o Do not remove files that are empty after patching.

           +o Do not ask whether to get files from RCS, ClearCase,
             or SCCS.

           +o Require that all options precede the  files  in  the
             command line.

           +o Do not backup files when there is a mismatch.

       --quoting-style=word
          Use  style word to quote output names.  The word should
          be one of the following:

          literal
                 Output names as-is.

          shell  Quote names for the shell if they contain  shell
                 metacharacters  or would cause ambiguous output.

          shell-always
                 Quote names for the shell, even  if  they  would
                 normally not require quoting.

          c      Quote names as for a C language string.

          escape Quote as with c except omit the surrounding dou-
                 ble-quote characters.

          You can  specify  the  default  value  of  the  --quot-
          ing-style  option  with  the environment variable QUOT-
          ING_STYLE.  If that environment variable  is  not  set,
          the default value is shell.

       -r rejectfile  or  --reject-file=rejectfile
          Put rejects into rejectfile instead of the default .rej
          file.

       -R  or  --reverse
          Assume that this patch was created with the old and new
          files swapped.  (Yes, I'm afraid that does happen occa-
          sionally,  human  nature  being  what  it  is.)   patch
          attempts  to  swap each hunk around before applying it.
          Rejects come out in the swapped format.  The -R  option
          does not work with ed diff scripts because there is too
          little information to reconstruct  the  reverse  opera-
          tion.

          If  the first hunk of a patch fails, patch reverses the
          hunk to see if it can be applied that way.  If it  can,
          you  are  asked  if you want to have the -R option set.
          If it can't, the patch continues  to  be  applied  nor-
          mally.   (Note:  this  method  cannot detect a reversed
          patch if it is a normal diff and if the  first  command
          is  an append (i.e. it should have been a delete) since
          appends always succeed, due to the  fact  that  a  null
          context matches anywhere.  Luckily, most patches add or
          change lines rather than delete them, so most  reversed
          normal diffs begin with a delete, which fails, trigger-
          ing the heuristic.)

       -s  or  --silent  or  --quiet
          Work silently, unless an error occurs.

       -t  or  --batch
          Suppress questions like -f,  but  make  some  different
          assumptions:  skip patches whose headers do not contain
          file names (the same as -f); skip patches for which the
          file  has the wrong version for the Prereq: line in the
          patch; and assume that patches  are  reversed  if  they
          look like they are.

       -T  or  --set-time
          Set  the modification and access times of patched files
          from time stamps given in context diff headers,  assum-
          ing that the context diff headers use local time.  This
          option is not recommended, because patches using  local
          time  cannot  easily  be  used  by people in other time
          zones, and because local time stamps are ambiguous when
          local clocks move backwards during daylight-saving time
          adjustments.  Instead of using  this  option,  generate
          patches  with  UTC  and  use the -Z or --set-utc option
          instead.

       -u  or  --unified
          Interpret the patch file as a unified context diff.

       -v  or  --version
          Print out patch's revision header and patch level,  and
          exit.

       -V method  or  --version-control=method
          Use  method to determine backup file names.  The method
          can also be given by the PATCH_VERSION_CONTROL (or,  if
          that's  not set, the VERSION_CONTROL) environment vari-
          able, which is overridden by this option.   The  method
          does  not  affect  whether  backup  files  are made; it
          affects only the names of any  backup  files  that  are
          made.

          The value of method is like the GNU Emacs `version-con-
          trol' variable; patch also recognizes synonyms that are
          more  descriptive.   The  valid  values  for method are
          (unique abbreviations are accepted):

          existing  or  nil
             Make numbered backups of  files  that  already  have
             them,   otherwise   simple  backups.   This  is  the
             default.

          numbered  or  t
             Make numbered backups.   The  numbered  backup  file
             name for F is F.~N~ where N is the version number.

          simple  or  never
             Make  simple  backups.   The  -B  or --prefix, -Y or
             --basename-prefix, and -z or --suffix options  spec-
             ify  the  simple backup file name.  If none of these
             options are given, then a simple  backup  suffix  is
             used;  it  is  the value of the SIMPLE_BACKUP_SUFFIX
             environment variable if set, and is .orig otherwise.

          With  numbered  or  simple  backups, if the backup file
          name is too long, the backup suffix ~ is used  instead;
          if  even appending ~ would make the name too long, then
          ~ replaces the last character of the file name.

       --verbose
          Output extra information about the work being done.

       -x num  or  --debug=num
          Set internal debugging flags of interest only to  patch
          patchers.

       -Y pref  or  --basename-prefix=pref
          Prefix  pref to the basename of a file name when gener-
          ating its simple backup file name.  For  example,  with
          -Y .del/    the    simple    backup   file   name   for
          src/patch/util.c is src/patch/.del/util.c.

       -z suffix  or  --suffix=suffix
          Use suffix as the simple backup suffix.   For  example,
          with   -z -   the   simple   backup   file   name   for
          src/patch/util.c is src/patch/util.c-.  The backup suf-
          fix  may  also be specified by the SIMPLE_BACKUP_SUFFIX
          environment  variable,  which  is  overridden  by  this
          option.

       -Z  or  --set-utc
          Set  the modification and access times of patched files
          from time stamps given in context diff headers,  assum-
          ing  that the context diff headers use Coordinated Uni-
          versal Time (UTC, often known as GMT).  Also see the -T
          or --set-time option.

          The  -Z  or --set-utc and -T or --set-time options nor-
          mally refrain from setting a file's time if the  file's
          original  time  does  not  match  the time given in the
          patch header, or if its contents do not match the patch
          exactly.   However,  if  the  -f  or  --force option is
          given, the file time is set regardless.

          Due to the limitations of  diff  output  format,  these
          options cannot update the times of files whose contents
          have not changed.  Also, if you use these options,  you
          should  remove  (e.g.  with  make clean) all files that
          depend on the patched files, so that later  invocations
          of  make  do  not  get  confused  by the patched files'
          times.

ENVIRONMENT
       PATCH_GET
          This specifies whether patch gets missing or  read-only
          files  from RCS, ClearCase, or SCCS by default; see the
          -g or --get option.

       POSIXLY_CORRECT
          If set, patch conforms more strictly to the POSIX stan-
          dard by default: see the --posix option.

       QUOTING_STYLE
          Default value of the --quoting-style option.

       SIMPLE_BACKUP_SUFFIX
          Extension  to  use for simple backup file names instead
          of .orig.

       TMPDIR, TMP, TEMP
          Directory to put temporary files  in;  patch  uses  the
          first  environment  variable  in this list that is set.
          If none are set, the default is system-dependent; it is
          normally /tmp on Unix hosts.

       VERSION_CONTROL or PATCH_VERSION_CONTROL
          Selects  version  control  style;  see the -v or --ver-
          sion-control option.

FILES
       $TMPDIR/p*
          temporary files

       /dev/tty
          controlling terminal; used to get answers to  questions
          asked of the user

SEE ALSO
       diff(1), ed(1), bk help gpl

       Marshall T. Rose and Einar A. Stefferud, Proposed Standard
       for    Message    Encapsulation,    Internet    RFC    934
       <URL:ftp://ftp.isi.edu/in-notes/rfc934.txt> (1985-01).

NOTES FOR PATCH SENDERS
       There  are  several  things you should bear in mind if you
       are going to be sending out patches.

       Create your patch systematically.  A good  method  is  the
       command  diff -Naur old new where old and new identify the
       old and new directories.  The names old and new should not
       contain  any  slashes.   The diff command's headers should
       have dates and times in Universal Time  using  traditional
       Unix  format,  so  that patch recipients can use the -Z or
       --set-utc option.   Here  is  an  example  command,  using
       Bourne shell syntax:

          LC_ALL=C TZ=UTC0 diff -Naur gcc-2.7 gcc-2.8

       Tell  your  recipients  how  to apply the patch by telling
       them which directory to cd to, and which patch options  to
       use.   The  option  string -Np1 is recommended.  Test your
       procedure by pretending to be  a  recipient  and  applying
       your patch to a copy of the original files.

       You  can  save  people  a lot of grief by keeping a patch-
       level.h file which is patched to increment the patch level
       as  the first diff in the patch file you send out.  If you
       put a Prereq: line in with the patch, it  won't  let  them
       apply patches out of order without some warning.

       You  can create a file by sending out a diff that compares
       /dev/null or an empty file  dated  the  Epoch  (1970-01-01
       00:00:00  UTC)  to the file you want to create.  This only
       works if the file you want to create doesn't exist already
       in  the  target  directory.   Conversely, you can remove a
       file by sending out a context diff that compares the  file
       to  be  deleted  with  an empty file dated the Epoch.  The
       file will be removed unless patch is conforming  to  POSIX
       and  the  -E  or --remove-empty-files option is not given.
       An easy way to generate patches  that  create  and  remove
       files is to use GNU diff's -N or --new-file option.

       If the recipient is supposed to use the -pN option, do not
       send output that looks like this:

          diff -Naur v2.0.29/prog/README prog/README
          --- v2.0.29/prog/README   Mon Mar 10 15:13:12 1997
          +++ prog/README   Mon Mar 17 14:58:22 1997

       because the two  file  names  have  different  numbers  of
       slashes,  and  different  versions  of patch interpret the
       file names differently.  To avoid confusion,  send  output
       that looks like this instead:

          diff -Naur v2.0.29/prog/README v2.0.30/prog/README
          --- v2.0.29/prog/README   Mon Mar 10 15:13:12 1997
          +++ v2.0.30/prog/README   Mon Mar 17 14:58:22 1997

       Avoid  sending patches that compare backup file names like
       README.orig, since this might confuse patch into  patching
       a  backup  file  instead  of the real file.  Instead, send
       patches that compare the same base file names in different
       directories, e.g. old/README and new/README.

       Take care not to send out reversed patches, since it makes
       people wonder whether they already applied the patch.

       Try not to have your patch modify derived files (e.g.  the
       file  configure  where  there is a line configure: config-
       ure.in in your makefile), since the  recipient  should  be
       able  to regenerate the derived files anyway.  If you must
       send diffs of derived files, generate the diffs using UTC,
       have  the  recipients  apply  the  patch  with  the  -Z or
       --set-utc option, and have them remove any unpatched files
       that depend on patched files (e.g. with make clean).

       While  you  may  be able to get away with putting 582 diff
       listings into one file, it may be wiser to  group  related
       patches  into  separate  files in case something goes hay-
       wire.

DIAGNOSTICS
       Diagnostics generally indicate that patch  couldn't  parse
       your patch file.

       If the --verbose option is given, the message Hmm... indi-
       cates that there is unprocessed text in the patch file and
       that  patch  is  attempting  to  intuit whether there is a
       patch in that text and, if so, what kind of patch it is.

       patch's exit status is 0 if all hunks are applied success-
       fully,  1  if some hunks cannot be applied, and 2 if there
       is more serious trouble.  When applying a set  of  patches
       in a loop it behooves you to check this exit status so you
       don't apply a later patch to a partially patched file.

CAVEATS
       Context diffs cannot reliably represent  the  creation  or
       deletion  of  empty  files,  empty directories, or special
       files such as symbolic  links.   Nor  can  they  represent
       changes  to  file metadata like ownership, permissions, or
       whether one file is a hard link to  another.   If  changes
       like  these are also required, separate instructions (e.g.
       a shell script) to accomplish them  should  accompany  the
       patch.

       patch  cannot  tell  if  the line numbers are off in an ed
       script, and can detect bad line numbers in a  normal  diff
       only  when  it finds a change or deletion.  A context diff
       using fuzz factor 3 may have the same  problem.   Until  a
       suitable interactive interface is added, you should proba-
       bly do a context diff in these cases to see if the changes
       made  sense.   Of  course,  compiling  without errors is a
       pretty good indication that  the  patch  worked,  but  not
       always.

       patch  usually  produces the correct results, even when it
       has to do a lot of guessing.   However,  the  results  are
       guaranteed to be correct only when the patch is applied to
       exactly the same version of the file that  the  patch  was
       generated from.

COMPATIBILITY ISSUES
       The  POSIX  standard  specifies behavior that differs from
       patch's traditional behavior.   You  should  be  aware  of
       these differences if you must interoperate with patch ver-
       sions 2.1 and earlier, which do not conform to POSIX.

        +o In traditional  patch,  the  -p  option's  operand  was
          optional,  and a bare -p was equivalent to -p0.  The -p
          option now requires an operand, and -p 0 is now equiva-
          lent  to  -p0.   For maximum compatibility, use options
          like -p0 and -p1.

          Also, traditional patch  simply  counted  slashes  when
          stripping path prefixes; patch now counts pathname com-
          ponents.  That is, a sequence of one or  more  adjacent
          slashes  now  counts  as  a  single slash.  For maximum
          portability, avoid sending  patches  containing  //  in
          file names.

        +o In  traditional patch, backups were enabled by default.
          This behavior is now enabled with the  -b  or  --backup
          option.

          Conversely,  in  POSIX  patch,  backups are never made,
          even when there is a  mismatch.   In  GNU  patch,  this
          behavior  is  enabled  with the --no-backup-if-mismatch
          option, or by conforming  to  POSIX  with  the  --posix
          option  or  by  setting the POSIXLY_CORRECT environment
          variable.

          The -b suffix option of traditional patch is equivalent
          to the -b -z suffix options of GNU patch.

        +o Traditional  patch used a complicated (and incompletely
          documented) method to intuit the name of the file to be
          patched  from  the  patch  header.  This method did not
          conform to POSIX, and had a  few  gotchas.   Now  patch
          uses a different, equally complicated (but better docu-
          mented) method that is optionally POSIX-conforming;  we
          hope it has fewer gotchas.  The two methods are compat-
          ible if the file names in the context diff  header  and
          the  Index:  line are all identical after prefix-strip-
          ping.   Your  patch  is  normally  compatible  if  each
          header's  file  names  all  contain  the same number of
          slashes.

        +o When traditional patch asked the user  a  question,  it
          sent  the  question to standard error and looked for an
          answer from the first file in the following  list  that
          was   a  terminal:  standard  error,  standard  output,
          /dev/tty, and standard input.  Now  patch  sends  ques-
          tions   to   standard  output  and  gets  answers  from
          /dev/tty.  Defaults for some answers have been  changed
          so  that  patch  never  goes into an infinite loop when
          using default answers.

        +o Traditional patch  exited  with  a  status  value  that
          counted  the  number  of bad hunks, or with status 1 if
          there was real trouble.  Now patch exits with status  1
          if some hunks failed, or with 2 if there was real trou-
          ble.

        +o Limit yourself to the following  options  when  sending
          instructions meant to be executed by anyone running GNU
          patch, traditional patch, or a patch that  conforms  to
          POSIX.   Spaces  are significant in the following list,
          and operands are required.

             -c
             -d dir
             -D define
             -e
             -l
             -n
             -N
             -o outfile
             -pnum
             -R
             -r rejectfile

BUGS
       Please report bugs via email to <bug-gnu-utils@gnu.org>.

       patch could be smarter about partial matches,  excessively
       deviant  offsets  and swapped code, but that would take an
       extra pass.

       If code has been duplicated (for instance with #ifdef OLD-
       CODE ... #else ... #endif), patch is incapable of patching
       both versions, and, if it works at all, will likely  patch
       the wrong one, and tell you that it succeeded to boot.

       If  you apply a patch you've already applied, patch thinks
       it is a reversed patch, and offers to un-apply the  patch.
       This could be construed as a feature.

COPYING
       Copyright 1984, 1985, 1986, 1988 Larry Wall.
       Copyright  1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996,
       1997, 1998 Free Software Foundation, Inc.

       Permission is granted  to  make  and  distribute  verbatim
       copies  of  this  manual provided the copyright notice and
       this permission notice are preserved on all copies.

       Permission is granted to copy and distribute modified ver-
       sions  of  this  manual  under the conditions for verbatim
       copying, provided that the entire resulting  derived  work
       is  distributed  under  the  terms  of a permission notice
       identical to this one.

       Permission is granted to copy and distribute  translations
       of this manual into another language, under the above con-
       ditions for modified versions, except that this permission
       notice  may  be  included  in translations approved by the
       copyright holders instead of in the original English.

SOURCE
       The source code for the versions of GNU tools  shipped  by
       BitMover is available at ftp://ftp.bitmover.com/gnu.

AUTHORS
       Larry  Wall  wrote  the  original  version of patch.  Paul
       Eggert removed patch's arbitrary limits; added support for
       binary  files, setting file times, and deleting files; and
       made it  conform  better  to  POSIX.   Other  contributors
       include  Wayne  Davison,  who  added  unidiff support, and
       David MacKenzie, who added configuration and  backup  sup-
       port.

GNU                         1998/03/21                          1
$
