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, push, or resync
  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 bin - show binary installation directory
  bk bk - BitKeeper source management system front end
  bk bkd - the BitKeeper daemon
  bk bkl - BitKeeper License version 1.37, 02/18/02
  bk bkscc - BitKeeper and SCC API
  bk bksrc - the BitKeeper Source License
  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 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 ignore - ignore shell glob patterns
  bk import - import a set of files into a BitKeeper package
  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 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 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 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 regression - execute regression tests for BitKeeper
  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 push/pull/resync
  bk resync - resync two BitKeeper repositories in the local filesystem
  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 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, push, or resync
  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 import - import a set of files into a BitKeeper package
  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 push/pull/resync
  bk resync - resync two BitKeeper repositories in the local filesystem
  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 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 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 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 bkl - BitKeeper License version 1.37, 02/18/02
  bk bksrc - the BitKeeper Source 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 bin - show binary installation directory
  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 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               2000/12/10                          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               2001/02/08                          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               2000/11/08                          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               2000/11/08                          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               2000/11/08                          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, push, or resync

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/bk push/bk resync) failed
       and there has been no manual resolve work done yet,  there
       is  no harm in aborting and trying again.  If manual reso-
       lution 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
       bk help resync

CATEGORY
       Repository

BitMover, Inc               2001/04/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.
       -B             make the landing pad bigger.
       -C[<csetfile>] set or remove the changeset file pointer in
                      the 1.0 delta (very rarely used, not recom-
                      mended).
       -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)
           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.
           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 termina-
                       tion.  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 fea-
              tures.
       -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<mode>
              set the mode of the file; <mode> is in the form -rwxrwxrwx.
       -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               2002/03/05                          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               2000/12/11                          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/01/09                          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               2002/01/30                          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> -s<dir>

       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<uid>   Run with effective group id <gid>(POSIX compati-
                 ble systems only).
       -u<uid>   Run with effective user id <uid>(POSIX  compati-
                 ble 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.
       -s<dir>   Specify the directory in which the bkd starts.

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

           #---------------------- cut here --------------------------
           /home/bk/LMbench -p5000 -xcd -xpush -u99
           /home/bk/bitcluster -p6000 -xcd -xpush -u99
           /home/bk/one -p7000 -xcd -xpush -u99
           #---------------------- 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
           #
           # bitkeeper    Start/stop the bitkeeper daemon.
           #         @(#)bitkeeper.init 1.1 Copyright (c) 2000 Larry McVoy

           # 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"
                     ;;
               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`
                          bk bkd -C -d $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}"
                     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.

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

CATEGORY
       Repository
       Admin

BitMover, Inc               2002/03/29                          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 - BitKeeper License version 1.37, 02/18/02

LICENSE
                BitKeeper License version 1.38, 03/28/02

       1.  DEFINITIONS

       BKL:  This license in its entirety, also known as the Bit-
             Keeper License.

       You: The licensee of the BitKeeper Software.

       BitMover: The licensor of the BitKeeper Software.

       BitKeeper Software: The complete set  of  executable  pro-
             grams and any accompanying files, such as documenta-
             tion, known as the BitKeeper Software.  The  set  of
             programs  and  files must include all files and pro-
             grams distributed by BitMover as part  of  the  Bit-
             Keeper Software.

       BitKeeper Package: A set of files managed by the same Bit-
             Keeper  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 Bit-
             Keeper 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 files contained in  the  top  level  BitKeeper
               directory  in  a  BitKeeper Package, in particular
               the  BitKeeper/html   directory   and   the   Bit-
               Keeper/etc/config file.

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

       Conforming Software: BitKeeper Software that:

       (i)   passes  all of the current,  unmodified,  regression
             tests for the BitKeeper Software;

       (ii)  performs  all licensing functions, such as Open Log-
             ging, identically to the current version of the Bit-
             Keeper Software as distributed by BitMover, Inc.

       2.  LICENSE GRANTS

       Licensees may freely install, use,  copy,  and  distribute
       Conforming Software.

       3.  LICENSEE OBLIGATIONS

       (a)  Maintaining  Open Logging Feature: You hereby warrant
            that you will not take any action to disable or  oth-
            erwise interfere with the Open Logging feature of the
            BitKeeper Software.  You hereby warrant that you will
            take  any  necessary  actions to ensure that the Bit-
            Keeper Software successfully transmits  the  Metadata
            to  an  Open Logging server within 7 days of the cre-
            ation of said Metadata.  By transmitting the Metadata
            to an Open Logging server, You hereby grant BitMover,
            or any other operator of an Open Logging server, per-
            mission  to  republish  the Metadata sent by the Bit-
            Keeper Software to the Open Logging server.

       (b)  Modifications: You may provide, at your option, modi-
            fications  to  BitMover.  By doing so, You grant Bit-
            Mover permission to distribute the modification under
            any license.  This provision survives any termination
            of your license.  In return, BitMover  promises  that
            future  versions  of the BitKeeper Software that con-
            tain your modification will be  available  under  the
            BKL.

       (c)  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  BitKeeper/etc/REPO LICENSE  file
            within  the  BitKeeper  Package  and/or  by   running
            bk repo license.

       (d)  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 capabil-
            ities  of  the BitKeeper Software, or, in the reason-
            able opinion of BitMover, competes with the BitKeeper
            Software.

       (e)  Inclusion  with  another product having source and/or
            configuration management features: Inclusion  of  the
            BitKeeper  Software for use with a system having sub-
            stantially  similar  capabilities  of  the  BitKeeper
            Software  requires prior written permission from Bit-
            Mover.

       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
       participating 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 BitKeeper 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 Bit-
       Mover, 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,  copying,  or distribution of non-conforming software
       is a violation of copyrights held by BitMover on the  Bit-
       Keeper  Software.   Damages for copyright infringement are
       the greater of actual damages or statutory damages,  which
       are currently 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  Bit-
       Mover.

       BitMover  reserves the right to terminate this license for
       any licensee or group of licensees whose usage  under  the
       terms  of  the BKL results in support costs to BitMover in
       excess of $20,000.

       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 LIM-
       ITATION, 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  POR-
       TION OF BITKEEPER SOFTWARE PROVE DEFECTIVE IN ANY RESPECT,
       YOU ASSUME THE COST OF ANY  RESULTING  DAMAGES,  NECESSARY
       SERVICING,  REPAIR  OR CORRECTION. THIS DISCLAIMER OF WAR-
       RANTY 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  ter-
         minate  automatically  if  you fail to comply with terms
         herein.   Provisions  which,  by  their  nature,  should
         remain  in effect beyond the termination of this License
         shall survive  including,  without  limitation,  Section
         3(b).

       + If  any of the licensing requirements, such as Open Log-
         ging, 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 litiga-
         tion against BitMover, Inc. with  respect  to  the  Bit-
         Keeper  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 BitKeeper Software.

       7.  LIMITATION OF LIABILITY

       TO  THE  FULL EXTENT ALLOWED BY APPLICABLE LAW, BITMOVER'S
       LIABILITY 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 HERE-
       UNDER 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),  HOWEVER IT ARISES AND ON ANY THEORY
       OF LIABILITY, WHETHER IN AN ACTION  FOR  CONTRACT,  STRICT
       LIABILITY  OR  TORT  (INCLUDING  NEGLIGENCE) OR OTHERWISE,
       WHETHER OR NOT SUCH PARTY HAS BEEN ADVISED OF  THE  POSSI-
       BILITY  OF  SUCH DAMAGE AND NOTWITHSTANDING THE FAILURE 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.

       8.2.  Assignment

       BitMover may assign this License, and its rights and obli-
       gations hereunder, at its sole discretion.

       8.3.  Severability

       If  any provision of this License is held to be unenforce-
       able, such provision shall be reformed only to the  extent
       necessary to make it enforceable.

       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.    Page 1

CATEGORY
       Licensing

BitMover, Inc               2002/03/28                          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   left click on Tools-> Version Control-> Main-
                    tenance-> Current Directory and type  in  the
                    root path of the BitKeeper repository.

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/02/26                          1
$
help://bksrc
help://bksrc.1
help://bk-bksrc
help://bk-bksrc.1

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

NAME
       bk bksrc - the BitKeeper Source License

LICENSE
                        BitKeeper Source License

       1.  DEFINITIONS

       You: The licensee of the BitKeeper Source.

       BitMover: The licensor of the BitKeeper Source.

       GPL:   The   Free  Software  Foundation's  General  Public
             License, version 2.

       BitKeeper Source: The complete set of source files,  known
             as the BitKeeper Source.

       BitKeeper Software: The complete set of binaries and asso-
             ciated files resulting from a build of the BitKeeper
             Source; this set of files may not include any of the
             BitKeeper Source in any form unless said  source  is
             also included in the current BitKeeper Software ver-
             sion released by BitMover.

       Conforming Software: BitKeeper Software that:

       (i)   passes all of the  current,  unmodified,  regression
             tests for the BitKeeper Software;

       (ii)  performs  all licensing functions, such as Open Log-
             ging, identically to the current version of the Bit-
             Keeper Software as distributed by BitMover, Inc.

       2.  LICENSE GRANTS

       (a)   Licensees  may build, use, and redistribute Conform-
             ing Software.

       (b)   Licensees may redistribute their changes to the Bit-
             Keeper  Source  to  other BitKeeper Source Licensees
             using the BitKeeper Software.

       3.  LICENSEE OBLIGATIONS

       (a)   Maintaining Licensing Features: You  hereby  warrant
             that you will not take any action to disable or oth-
             erwise interfere with any Licensing  features,  such
             as  the  Open Logging feature of the BitKeeper Soft-
             ware.

       (b)   Modifications: You may provide, at your option, mod-
             ifications to BitMover.  By doing so, You grant Bit-
             Mover  permission  to  distribute  the  modification
             under any license.  This provision survives any ter-
             mination of your license.

       (c)   Conformance: Prior to  redistribution  of  BitKeeper
             Software  built  by  You  from BitKeeper Source, you
             must provide your changes for regression testing  to
             regressions@bitkeeper.com.   BitMover  will  provide
             confirmation that the changes  pass  regressions  on
             all supported platforms with 48 hours.

       3.1.  Damages

       Use,  copying,  or distribution of non-conforming software
       is a violation of copyrights held by BitMover on the  Bit-
       Keeper  Software.   Damages for copyright infringement are
       the greater of actual damages or statutory damages,  which
       are currently up to $150,000 per infringement.

       Distribution  of the BitKeeper Source to parties without a
       BitKeeper Source License is a violation of copyrights held
       by  BitMover on the BitKeeper Software.  Damages for copy-
       right infringement are the greater of  actual  damages  or
       statutory  damages, which are currently up to $150,000 per
       infringement.

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

       4.  CONVERSION TO THE GPL

       The BitKeeper Software will be made  available  under  the
       terms  of  the  GPL  in  the  event  that all Open Logging
       servers cease to function for a continuous period  of  180
       days starting on or after January 1st 2002.

       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 LIM-
       ITATION, 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 POR-
       TION OF BITKEEPER SOFTWARE PROVE DEFECTIVE IN ANY RESPECT,
       YOU  ASSUME  THE  COST OF ANY RESULTING DAMAGES, NECESSARY
       SERVICING, REPAIR OR CORRECTION. THIS DISCLAIMER  OF  WAR-
       RANTY  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 ter-
         minate automatically if you fail to  comply  with  terms
         herein.   Provisions  which,  by  their  nature,  should
         remain in effect beyond the termination of this  License
         shall  survive  including,  without limitation, Sections
         3(a), 3(b).

       + If any part of this License is found  to  be  unenforce-
         able, then this License and the rights granted hereunder
         automatically terminates unless You continue  to  comply
         with the license.

       + Should  You  or  your  organization  choose to institute
         patent, copyright, and/or intellectual property  litiga-
         tion  against  BitMover,  Inc.  with respect to the Bit-
         Keeper  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 Source and all copies
         of the BitKeeper Software generated from  the  BitKeeper
         Source.

       7.  LIMITATION OF LIABILITY

       TO  THE  FULL EXTENT ALLOWED BY APPLICABLE LAW, BITMOVER'S
       LIABILITY 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 HERE-
       UNDER 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),  HOWEVER IT ARISES AND ON ANY THEORY
       OF LIABILITY, WHETHER IN AN ACTION  FOR  CONTRACT,  STRICT
       LIABILITY  OR  TORT  (INCLUDING  NEGLIGENCE) OR OTHERWISE,
       WHETHER OR NOT SUCH PARTY HAS BEEN ADVISED OF  THE  POSSI-
       BILITY  OF  SUCH DAMAGE AND NOTWITHSTANDING THE FAILURE OF
       ESSENTIAL PURPOSE OF ANY REMEDY.

       8.  MISCELLANEOUS

       8.1.  Merger

       This License represents the complete agreement between You
       and  BitMover  regarding  the  BitKeeper Source covered by
       this License.

       8.2.  Assignment

       BitMover may assign this License, and its rights and obli-
       gations hereunder, at its sole discretion.

       8.3.  Severability

       If  any provision of this License is held to be unenforce-
       able, such provision shall be reformed only to the  extent
       necessary to make it enforceable.

       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.

       BK/SRC    Copyright (C) 1999-2002 BitMover, Inc.    Page 1

CATEGORY
       Licensing

BitMover, Inc               2002/03/11                          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               2000/12/05                          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
       -/<pat>/[i]   List  only  those  changesets whose comments
                     contain the string <pat>.   If  there  is  a
                     trailing "i" then ignore case in the search.
       -a            List  all  deltas,  including  tag   deltas.
                     Implies -e.
       -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.   Implies  -a   which
                     implies  -e.   If you really do not want the
                     empty merge keys, another  -e  option  after
                     this option will turn off the listing of the
                     empty merge keys (the -e option is  inverted
                     from its previous value each time the option
                     is seen).
       -L            List only those changesets which are  unique
                     to  the  local repository; requires a BK url
                     or a valid repository parent.
       -m            Do not show any merge changesets.
       -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; requires a BK url
                     or a valid repository 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 sccslog
       bk help set
       bk help revtool

CATEGORY
       Repository

BitMover, Inc               2002/02/22                          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 [-acefgpRvw]

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.
       -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 character,
              LF
           Warnings will occur if any of the above do not check
           out cleanly.
       -f  Fix any fixable errors.
       -g  List  gone keys only, useful for feeding into the Bit-
           Keeper/etc/gone file.
       -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/03/02                          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/03/05                          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 <mode> <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, use bk chmod  command
       and not the system's chmod command.

       The  command  respects  whatever  syntax your native chmod
       command uses.  It does this by running chmod on  the  file
       and then copies the resulting modes into the revision his-
       tory.

SEE ALSO
       bk help admin
       chmod(1)

CATEGORY
       File

BitMover, Inc               2000/09/19                          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               2001/07/16                          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/03/14                          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               2000/11/07                          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>.
       -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 triggers
       bk help url

CATEGORY
       Repository
       Common

BitMover, Inc               2002/02/22                          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               2001/08/02                          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/03/21                          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.

       BUGS   Nota  bene: if the deltas being commented have been
              committed to a changeset and have been  pulled  out
              of  this  repository,  the comment changes will not
              propagate on the next bk pull.  It is strongly sug-
              gested 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/03/11                          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/03/04                          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               2001/04/23                          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               2001/03/06                          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 always take
       precedence over system level specifications,  meaning,  if
       both  BitKeeper/etc/config  and  /etc/BitKeeper/etc/config
       files exist, BitKeeper/etc/config values are augmented  by
       /etc/BitKeeper/etc/config values that do not exist in Bit-
       Keeper/etc/config.   BitKeeper/etc/config values will  not
       be replaced by values in /etc/BitKeeper/etc/config.

       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://bkgui
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 bkgui  for  the
       configuration  of the BitKeeper graphical tools.  The con-
       figuration file is used to modify colors, fonts, and  wid-
       get dimensions.

       On  UNIX  systems, this configuration file is searched for
       in $HOME/.bkgui where  $HOME  refers  to  the  users  home
       directory.

       On Microsoft Windows NT and Windows 98 systems,

           %SystemRoot%\Profiles\%User%\Application Data\BitKeeper\_bkgui

       is the location of the config file; this path is usually

           c:\winnt\Profiles\%User%\Application Data\BitKeeper\_bkgui

       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  advantage of being a program is that you
       can add custom tcl code to the config  file  in  order  to
       customize  the  gui  based  on  arbitrary  values  such as
       machine name, domain name, etc.

       The .bkgui file consists of lines that  set  configuration
       options.  A typical configuration line looks like this:

           set gc(BG) #f0f0f

       The items that make up a config line are as follows:

           set     tcl command used to assign values to variables
           gc(BG)  array value
           #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."

GUI CONFIGURATION
   GLOBAL VARIABLES
       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 helptool 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: lightblue
       oldColor
         Color of the older revision or diff.  Default: #d070ff
       noticeColor
         Color for warnings and messages.  Default: #b0b0e0
       searchColor
         Highlight color for search matches. Used in difftool and
         revtool.  Default: yellow
       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 widgets 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 standard X11 nota-
         tion.  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>

   TOOL SPECIFIC VARIABLES
       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 modify  many
          files  that  logically  belong  to separate changesets.
          This option then allows you to stay in citool and  cre-
          ate different changesets for the files without restart-
          ing citool each time. Default: 0
       cset.listHeight
          Number of lines in the list windows.  Default: 12
       diff.diffHeight
          Number of lines in the diff windows.  Default: 50
       diff.searchColor
          Highlight color for search matches.  Default: lightblue
       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 helptool. Default: 72
       help.exact
          Only return full word/phrase matches.  Default: 0,  set
          to 1 to enable.
       rename.listHeight
          Height  of  the  file  list  widget  in  renametool (in
          lines). Default: 8
       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 revision 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  annotated   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

AUTHOR
       The  GUI  configuration  was designed and is maintained by
       Aaron Kushner.

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               2000/11/08                          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://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>]
       [-S<sym>] [-x<list>] [-Y<file>] [-y<msg>]

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 TOL 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>.
       -S<sym>   Set  <sym>  to  be a symbolic tag for this revi-
                 sion.
       -x<list>  Create a new cset on TOL that excludes the csets
                 in <list>.
       -Y<file>  Sets  the  changeset  comment to the contents of
                 <file>.
       -y<msg>   Sets the changeset comment to <msg>.

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

CATEGORY
       Repository

BitMover, Inc               2002/01/31                          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 < 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.

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               2002/03/21                          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,  bk push,  or  bk resync.   This is useful for
       tracking down problems and/or doing a quick review.

SEE ALSO
       bk help csettool
       bk help pull
       bk help push
       bk help resync

CATEGORY
       Repository

BitMover, Inc               2000/09/19                          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
       PageDown        Scroll both files one screen down
       UpArrow         Scroll both files one line up
       DownArrow       Scroll both files one line down
       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/03/05                          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          Do  not  verify file checksum (slight perfor-
                    mance win).
        -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          Prompt  for  one comment, then use it for all
                    the files.
        -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 bk delta command does not yet use the SCCS/c.file com-
       ment caches created by bk citool.

       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               2002/03/25                          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] [-C<rev>] [-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 diffs -C<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>.
       -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               2002/01/31                          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/03/05                          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               2000/10/25                          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/03/05                          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               2000/09/19                          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 bkignore
       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/03/05                          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               2000/09/19                          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               2001/09/05                          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.

       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               2001/03/12                          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               2001/11/16                          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               2001/08/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 resync or a bk pull, your  repository  is  considered
       local  and  the  other  one is considered remote, and Bit-
       Keeper 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               2001/07/17                          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               2000/11/06                          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.
       -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/03/05                          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/02/28                          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

DESCRIPTION
       This  command  displays  BitKeeper's  idea of the caller's
       user name.

SEE ALSO
       bk help gethost

CATEGORY
       Utility

BitMover, Inc               2000/11/15                          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               2001/12/20                          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               2000/11/08                          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               2001/10/10                          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               2001/04/25                          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-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               2001/08/17                          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               2000/12/08                          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               2001/02/08                          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 a set of files into a BitKeeper package

SYNOPSIS
       bk import -tpatch [OPTIONS] <patch> <destination>
       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), SCCS files, and RCS and CVS files (in this document
       RCS will mean both RCS AND CVS) into a BitKeeper  package.
       bk import does its work outside of your original tree thus
       leaving the original files  intact  while  importing  them
       into a BitKeeper package.

       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 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 rcs2sccs
       bk help undos

CATEGORY
       Repository

BitMover, Inc               2002/03/26                          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               2000/09/19                          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               2000/11/06                          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               2001/03/06                          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               2000/10/27                          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  resync that causes a branch creation.  Use the %K% key-
       word when you need an identifier that is unique to a  spe-
       cific  revision-level of a file. The %K% keyword is useful
       when tracking customer bugs.  For  example,  a  technician
       might  ask the end-user to run the what command on an exe-
       cutable 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
       bk help resync

CATEGORY
       Repository

BitMover, Inc               2002/03/05                          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/02/11                          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/02/28                          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               2000/09/19                          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/03/05                          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  [-v]  [-c<range>]  [-e<range>]  [-d<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.
       -e<range> Like -r, except generate  only  metadata  diffs.
                 Used for logging only.
       -d<range> Do unified diffs for <range>.
       -r<range> Generate  a BitKeeper patch patch of the changes
                 in <range>.
       -v        Be more verbose for each instance.

FUTURE DIRECTIONS
       The bk makepatch command will be  evolved  to  send  empty
       patches  which just contain comments for logging purposes.

SEE ALSO
       bk help cset
       bk help export
       bk help gnupatch
       bk help rset

CATEGORY
       Repository

BitMover, Inc               2001/02/05                          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/03/05                          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               2001/02/21                          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/02/11                          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               2001/04/18                          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 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.

NOTES
       bk mv will not rename directories, please use bk mvdir for
       that.

       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 mvdir
       bk help names
       bk help pull
       bk help push
       bk help resync
       bk help rm
       bk help rmdir

AVAILABILITY
       =>Fully supported in BitKeeper Professional in all reposi-
       tories.
       =>Limited functionality in BitKeeper Basic.  bk mv  should
       only  be  used in the master repository since the resolver
       can not merge rename conflicts in  BitKeeper  Basic.   The
       actual  requirement is that it is only used in one reposi-
       tory, then all repositories must sync  with  that  reposi-
       tory.   The easiest way to accomplish this is to establish
       policy which says that bk mv may only be used in the  mas-
       ter repository.

CATEGORY
       File

BitMover, Inc               2002/03/05                          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
       To rename a directory <A> to <B>, do this:

           $ bk mvdir A B

SEE ALSO
       bk help mv
       bk help rmdir

CATEGORY
       File

BitMover, Inc               2001/07/16                          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  used to generate a new identity for a reposi-
       tory.  The identity of a repository is used  each  time  a
       repository  is  updated  from  another repository.  If the
       identities are not the same then  the  update  will  fail.
       Changing  a repository identity effectively creates a new,
       unique repository with all of the existing history.

SEE ALSO
       bk help clone
       bk help pull
       bk help push

CATEGORY
       Repository
       Admin

BitMover, Inc               2001/03/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               2001/04/18                          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 [-qr] [<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.
       -r     Remove the parent pointer.

SEE ALSO
       bk help bkd
       bk help clone
       bk help pull
       bk help push
       bk help resync
       bk help url

CATEGORY
       Repository

BitMover, Inc               2002/03/05                          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               2000/09/19                          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.
       -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, PATH, DEFAULT, SYMBOLS.

       If  a  multi-line  variable  is printed as one line, i.e.,
       without $each() (see below) providing a  prefix  and/or  a
       suffix,  then the lines are separated by spaces.  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 can 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)
       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 as three letter abbreviation (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
       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)
       LODKEY    D   the key of the start of D's LOD
       Ld        D   lines deleted in D
       Li        D   lines inserted in D
       Lu        D   lines unchanged in 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. DS doesn't account for holes that can occur when doing stripdels
       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
       SYMBOLS   D   symbolic tag portion of :DEFAULT:
       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
       TIME_T    D   D's date as GMT time_t, TZ and Fudge adjusted
       TIP       D   D's rev is D is a tip of a LOD
       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               2002/03/05                          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

AVAILABILITY
       =>BitKeeper  Professional  allows  communication  via ssh,
       rsh, and email as well as the bk daemon.
       =>BitKeeper Professional will retry the operation automat-
       ically if the remote host is busy.

CATEGORY
       Repository
       Common

BitMover, Inc               2002/02/12                          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

AVAILABILITY
       =>BitKeeper Professional  allows  communication  via  ssh,
       rsh, and email as well as the bk daemon.
       =>BitKeeper Professional will retry the operation automat-
       ically if the remote host is busy.

CATEGORY
       Repository
       Common

BitMover, Inc               2002/02/12                          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.

CATEGORY
       Utility

BitMover, Inc               2000/12/15                          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),  a symbolic name (in the  case  of  the
       ChangeSet file only), or a date (99/07/25).

       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/01/31                          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               2000/12/15                          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/03/05                          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  resync,  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               2001/02/16                          1
$
help://regression
help://regression.1
help://bk-regression
help://bk-regression.1

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

NAME
       bk regression - execute regression tests for BitKeeper

SYNOPSIS
       bk regression [-lrsvx] [<t.testname>]

DESCRIPTION
       BitKeeper  comes  with an extensive test suite designed to
       test basic functionality of commands.  The test suite  may
       be  run to make sure the system is installed and function-
       ing properly on your platform.

       The default is to run all tests found,  but  specifying  a
       test  name  will  run  only that test.  This is useful for
       debugging.

OPTIONS
       -l     Do  local  regression  tests  only  (this  is   the
              default)
       -r     Do remote tests
       -s     Use ssh rather than rsh for remote tests
       -v     have each command run verbosely instead of quietly
       -x     show each command in the test as it runs

WRITING TESTS
       Writing  tests  is  very  encouraged.  If you write a test
       which demonstrates a bug that we have not fixed,  BitMover
       will  give  your bug priority over all other bugs of equal
       severity with no test cases.  In other words,  test  cases
       get our attention more than bug reports.  We will add your
       test case to our test suite which will guarantee that  the
       problem will not reoccur.

       Each  test  is  self  contained.   There  are dependencies
       between tests, but these only matter if tests are failing,
       which is not typical.  Each test is run in a subdirectory,
       typically  something  like  /tmp/.regression-$USER;   this
       directory  created  before starting the test.  If the test
       succeeds the directory is removed; if the test fails  then
       the directory is left in place to aid in debugging.

       Tests  can  be, and usually are, very small.  To test that
       BitKeeper correctly checks in an reproduces a binary,  you
       might do this:

           cat > /usr/libexec/bitkeeper/t/t.my_bin_test
           echo $N Trying to check in some binary data .........................$NL
           cp /bin/ls DATA
           bk new $Q DATA
           bk co $Q DATA
           cmp -s DATA /bin/ls || {
                echo comparison failed
                exit 1
           }
           echo OK

       The  easiest  way  to  write  a  test is not to start from
       scratch.  Go to the t subdirectory, find a test  which  is
       close,  copy it, and use it as a basis.  It's very similar
       to writing device drivers, it's a waste of time  to  start
       from nothing, you use one that is close.

       Looking  at the example, there are a few things to notice.
       The test is bracketed by a starting line which  says  what
       it is doing, and an ending line which says it succeeded.

       The  $N  and $NL variables are to handle platform specific
       newline suppression.

       The $Q variable is set -q unless the test was run with -v.

       You  can  count on basic unix utilities such as diff, cmp,
       wc, etc.  We use them extensively throughout the tests and
       ship the ones we need.

       Please  write  tests, it makes BitKeeper a better tool for
       you and it is the best way that you  could  contribute  to
       its  enhancement.   If  there  is any interest in our test
       framework, we'll make it available under any  license  you
       want,  it's  trivial.   The main feature is that it allows
       small, self contained tests.

FILES
       /usr/libexec/bitkeeper/t/t.* - individual tests

BitMover, Inc               2002/03/05                          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> <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 <to> reposi-
       tory with a hardlink.

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/03/11                          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               2001/08/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               2001/08/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.

       We have started to integrate this command  into  LODs  but
       that integration is not yet complete.

OPTIONS
       -n     do not do anything, dry run.
       -q     be quiet.

CATEGORY
       Utility

BitMover, Inc               2002/03/05                          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
       push/pull/resync

SYNOPSIS
       bk resolve [-aAcdqrtv1234] [-l<log>] [-m<merge>]  [-y<com-
       ment>] [<package_root>]

DESCRIPTION
       After  a  bk push,  bk pull,  or bk resync, 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 manu-
       ally after a bk resync.

       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
       => LOD name 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
       bk help resync

CATEGORY
       Repository

BitMover, Inc               2001/10/03                          1
$
help://resync
help://resync.1
help://bk-resync
help://bk-resync.1

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

NAME
       bk resync - resync two BitKeeper repositories in the local
       filesystem

SYNOPSIS
       bk resync [-aclnqt] [-r<rev>] [<source> [<dest>]]

DESCRIPTION
       Resync updates the destination  repository  with  all  the
       changes  added  to  the  source  repository since the last
       resync.  If the destination does not  exist,  it  will  be
       created; this is the same as the bk clone operation.

       If  <dest>  is omitted, it defaults to the repository con-
       taining the current directory.  If <source> is omitted, it
       defaults  to  the  parent of the repository containing the
       current directory.

       While the source may be remote, the  destination  must  be
       local.

       By  default, after the resync completes, you still need to
       resolve the changes.  Resync does not change  anything  in
       the  destination  other than creating a PENDING and RESYNC
       directory.  The PENDING directory contains the  patch  and
       the  RESYNC  directory is a sparse copy of the destination
       with the patch applied.  The repository itself is not mod-
       ified until conflict resolution is finished.

OPTIONS
       -a        Automatically  call  resolve (this is similar to
                 pull).
       -c        Do not compress network traffic (if any).
       -l        Do a long list of the csets being sent (not  for
                 clone case).
       -n        Do  not  actually  execute  the resync; do a dry
                 run.
       -q        Be quiet.
       -r<rev>   As in the clone command, works only if  you  are
                 creating <dest>.
       -t        Pass -t to resolve (requires -a ).

SEE ALSO
       bk help bkd
       bk help resolve
       bk help clone
       bk help push
       bk help pull
       bk help triggers

CATEGORY
       Repository

BitMover, Inc               2000/09/19                          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/03/05                          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 resync.  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               2002/02/18                          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               2001/04/06                          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               2000/10/25                          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               2001/02/06                          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               2000/11/20                          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               2001/01/10                          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               2001/04/06                          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/03/05                          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,  figure  out  what needs to be sent, and
                    send it to the specified email address.
        -w<Wrapper> Wrap the patch with <Wrapper> before  sending
                    it.

SEE ALSO
       bk help ranges
       bk help receive
       bk help resync
       bk help wrap

CATEGORY
       File

BitMover, Inc               2002/03/05                          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/03/05                          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               2001/04/24                          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 -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  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               2001/08/16                          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               2000/11/15                          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);
                          sccs_sdelta(sc, sc->tree, file);
                          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 merge 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 merge 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/03/05                          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 [-bCcq] [-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.

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.
       -q        Run quietly.
       -r<rev>   Set of revisions to be removed.

SEE ALSO
       bk help clone
       bk help undo

CATEGORY
       File

BitMover, Inc               2002/03/05                          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               2001/12/07                          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, bk resync, 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
       bk help resync

CATEGORY
       Repository

BitMover, Inc               2002/03/02                          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:
       sfile
           A   file   containing   the  revision  history,  e.g.,
           SCCS/s.foo.c
       gfile
           A file that is checked out, e.g., foo.c
       package
           A package is a logical concept while the repository is
           the  physical  instance  of that concept. A package is
           created only once when the bk setup program is run.
       repository
           A directory tree that is populated with  the  revision
           control files.  A repository is an instance of a pack-
           age i.e. there is one package, but there can  be  many
           repositories belonging to that package.
       tag, symbol
           A  symbolic name (or tag) which is given to a particu-
           lar revision of one or more files.  e.g., "Alpha1".
       revision, delta
           One version of a particular file, or one change  to  a
           particular  file,  depending on context.  Sometimes we
           want to talk about the way the file is while sometimes
           we  want  to  talk about how it got there.  Files that
           have been checked out, edited,  and  not  yet  checked
           back  in  are  "modified" files.  When you check files
           in, the modifications become new deltas.
       cset, changeset
           One or more changes (deltas) to  one  or  more  files,
           grouped together into one logical change.  A changeset
           is the smallest thing which may be propagated  between
           repositories.   Deltas  that  aren't in changesets are
           called "uncommitted" or "pending" deltas.
       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 Latest revision on some branch, usually the trunk.
       Top of Trunk (TOT)
           The latest revision on the trunk.
       Line of Development (LOD)
           Another trunk in a repository.

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               2001/04/04                          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               2001/02/01                          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.
       => non-zero exit status fails the commit.
       => typically used for integrity checks.

       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.
       => 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_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 repository.
       BKD_LEVEL   The "level" of the other 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_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
       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
           #!/bin/sh

           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

AVAILABILITY
       Pull, push, resolve, and apply triggers are available with
       BitKeeper Professional only.

CATEGORY
       Repository

BitMover, Inc               2002/03/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.

SEE ALSO
       bk help makepatch
       bk help stripdel
       bk help takepatch
       bk help unpull

CATEGORY
       Repository

BitMover, Inc               2000/12/26                          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               2000/11/16                          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               2000/10/10                          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/02/28                          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               2001/04/04                          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/03/11                          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               2000/09/19                          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
           host returns or is  localhost.   In  either  of  those
           cases, this form is the same as the above form.

   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>

           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               2002/01/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               2000/09/19                          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               2000/10/25                          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               2000/10/10                          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.

       BitKeeper  provides  a  simple wrapper and unwrapper to do
       this.  The programs are small  shell  scripts  which  call
       uuencode  and  uudecode.  The files, which you can examine
       in the bin directory, are called uuwrap and unuuwrap.

       To use a different style of  wrapper  (base64,  encrypted,
       etc),  create two programs, one of which takes a stream of
       bytes on stdin and produces the wrapped stream  of  bytes,
       and another which takes a wrapped stream of bytes and pro-
       duces an unwrapped stream of bytes.

       These programs must be placed the BitKeeper bin  directory
       and have names of the form:

       <type>wrap
       un<type>wrap

       i.e., uuwrap and unuuwrap.

       If  the  programs  work  correctly, then the following two
       commands produce identical data:

           $ ls -1 | uuwrap | unuuwrap
           $ ls -1

       If you create new wrappers and place them  in  BitKeeper's
       bin  directory  on the sending and receiving machines, you
       can then invoke them when sending  patches.   Suppose  you
       created  simple  rotate-13  wrappers (shifts all character
       values 13 over, a common net news filter) and  you  called
       them rot13wrap and unrot13wrap.  Send patches by doing:

           $ bk send -wrot13 | mail user@where.ever.com

       The  user at the other end needs the rot13 wrapper scripts
       or they will not be able to apply the patch.

SEE ALSO
       bk help send
       bk help receive

CATEGORY
       File

BitMover, Inc               2000/10/18                          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               2001/04/04                          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               2000/09/16                          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/03/26                          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
$
