Museum

Home

Lab Overview

Retrotechnology Articles

Online Manuals

⇒ (1) — OSF1 1.0

Media Vault

Software Library

Restoration Projects

Artifacts Sought

Related Articles

bcs(1)

bco(1)

bsubmit(1)

branchmerge(1)

rcsci(1)

rcs(1)

rcsintro(1)



bci(1)              UNIX Programmer's Manual               bci(1)



NAME
     bci - check in branch revisions

SYNOPSIS
     bci [-nolog -defunct -xlog -xblog ]
         [bcs_options] [file_options] [rcsci_options] [file...]

     bcs_options:
                 [ -auto -fast -debug -quiet -rc -sb -set -newset
                 -newconfig -path -newpath ]

     file_options:
                 [ -all -wall -nowall -allb -wallb -nowallb -find
                 -wfind -nowfind]

     rcsci_options:
                 [ -f -s -m -l ]

FLAGS
     -nolog
          Specifies that HISTORY and $Log...$ lines are not
          present in file

     -defunct
          Used to set the state of file to "defunct".  Implies
          -nolog.

     -xlog rev[,rev...]
          Log messages are obtained for file by extracting all
          RCS-style log messages from the comma separated list of
          revisions.

     -xblog
          Log messages are obtained for file by extracting RCS-
          style log messages from all revisions of file in this
          branch.


 bcs_options - Defaults may be modified and/or overridden with
the following switches.

     -auto
          Automatically choose the default answer to any question
          asked by a command.  If the default answer requires
          manual intervention of some sort (e.g. to edit a file),
          then revert to interactive mode for the duration of the
          remaining operations for the current file and only
          return to automatic mode after proceeding to the next
          file in the list.

     -fast
          Always choose the default answer to any question asked



Printed 1/23/91              4/25/90                            1





bci(1)              UNIX Programmer's Manual               bci(1)



          by a command.  If the default answer requires manual
          intervention of some sort (e.g. to edit a file), then
          abort the operation on the current file instead and
          proceed to the next file in the list.

     -debug
          Enable debugging code.

     -quiet, -q
          Be less verbose about actions taken.

     -rc sandbox_rc_file
          Specifies an alternate sandbox rc file.  The defaults
          is $HOME/.sandboxrc.

     -sb sandbox_name
          Name of the sandbox to use.  If this option is not
          used, the sandbox will be determined by the environment
          variable SANDBOX or, if that is not set,  by the user's
          default sandbox as specified in the sandbox rc file.

     -sb_rc sandbox-rcfile
          Provides the path and name of the sandbox's rc file to
          use instaed of the default file sandbox/rc_files/local.
          If this option is not used, the default sandbox rc file
          will be used.

     -set set_name
          Performs operation on set_name instead of the  current
          default set.

     -path path
          Use path as the current directory within the shadow
          source area.  Used in conjunction with the -newpath
          option.

     -newpath
          Create and/or update the ./.BCSpath-<user_set_name> to
          contain the current relative path within the shadow
          source area.  This file is used by workon to chdir
          within to the same subdirectory when working on a set
          over an extended period of time.

 file_options - These options cause the list of affected file
names supplied on the command line to be extended.

     -all All files in the current set are operated on.  If this
          option is not chosen, the user must list the files to
          use.  The files in the set are listed in the sandbox's
          source directory in the file .BCSset- user_setname.

     -wall



Printed 1/23/91              4/25/90                            2





bci(1)              UNIX Programmer's Manual               bci(1)



          The same as -all. but only operates on the files in the
          set that are also writable.

     -nowall
          The same as -all. but only operates on the files in the
          set that are not writable.

     -alls user_set_name
          The same as -all -set user_set_name.

     -walls user_set_name
          The same as -wall -set user_set_name.

     -nowalls user_set_name
          The same as -nowall -set user_set_name.

     -find pattern
          First use all files found recursively with find(1)
          beginning at the current directory that match pattern,
          then use those on the command line.

     -wfind pattern
          The same as -find except use only writable files.

     -nowfind pattern
          The same as -find except use only non-writable files.
          pattern (with any trailing ",v" suffix stripped from
          all names), then use those on the command line.

rcsi_options - A number of the regular RCS switches are also sup-
ported.

     -f[rev]
          forces the checkin of a file even if it has not
          changed.

     -sstate
          sets the state of the checked in revision to state

     -mmsg
          use the string msg as the log message for all files
          checked in.

     -l   after the checkin, check the file backout again and
          lock it.


DESCRIPTION
     The BCS commands implement a branch management facility
     using the underlying set of regular RCS commands.  Bci acts
     as a front-end to the regular rcsci command.




Printed 1/23/91              4/25/90                            3





bci(1)              UNIX Programmer's Manual               bci(1)



     Bci stores new revisions of the files specified on the com-
     mand line into the corresponding RCS files.  An RCS file
     must already have been created using the bcreate command.

     The command requires that HISTORY and $Log...$ lines be
     present in file, unless -nolog has been specified or the
     comment leader for the file is "NONE".

     The regular RCS -f switch may be used to force the check-in
     of a revision which is identical to the previous revision.

     The regular RCS -s switch may be used to set the state of
     the checked-in revision. The -defunct option may be used to
     set the state to "defunct" and also implies -nolog (since
     such files are normally null and will of course contain no
     HISTORY or $Log...$ lines).

     An attempt is made to obtain the log message from file by
     extracting all lines beginning after a HISTORY line up to
     but not including a $Log...$ line. The first n (where n is
     the length of the RCS comment leader recorded for the file)
     characters of each extracted line are stripped away.  Any
     whist(1) style banner is compressed into a date and author
     stamp which is appended to the end of each extracted history
     message.

     If the -xlog option has been specified, an attempt is made
     to obtain the log message from file by extracting all RCS-
     style log messages from the comma separated list of branches
     beginning after a $Log...$ line up to but not including the
     first line which does not begin with the precise RCS comment
     leader recorded for the file (N.B. be careful with white
     space variants when manually editing such areas - most
     leaders end with a space and the text typically begins with
     a tab). The comment leader portion of each extracted line is
     stripped off along with any initial tab character.  The
     revision number, date/time, and author revision banner is
     compressed into a date/time and author stamp which is
     appended to the end of each extracted revision message.

     If the regular RCS -m option has been specified, this log
     message is used in the absence of any other.

     Opportunity is provided to interactively edit the tentative
     log message. If no log message was successfully extracted
     from file or supplied by -m, a draft log message is composed
     from the diff(1) listing between file and the previous revi-
     sion in RCS which can be edited into a more readable form as
     appropriate.  At this point, it is also possible to edit the
     copy of file which is about to be checked-in, or to compare
     this file with the previous version on the branch.  The text
     part of the log message is automatically padded with a



Printed 1/23/91              4/25/90                            4





bci(1)              UNIX Programmer's Manual               bci(1)



     leading tab at check-in time to better distinguish the revi-
     sion banner from its text and make the log are more read-
     able.

     The check-in operation is performed from a temporary copy of
     file (also the edited one) since it is not necessarily the
     case that the owner of the master RCS area has write permis-
     sion within the base directory.

     The checked-in revision is locked and the working file left
     writable if the -l switch is used, otherwise it is unlocked
     and the working file left non-writable. At the successful
     completion of each rcsci command, the temporary version is
     copied back to file (without changing the modification time
     but with the $Log...$ area updated when present), and a copy
     of the checked-in log message is also appended to the
     ./.BCSlog-<user_set_name> file.  At this time, file is added
     to the ./.BCSset-<user_set_name> file if necessary and
     deleted if the -rm switch was specified.  If the -rm switch
     was specified and the current branch refers to the trunk,
     then file is removed from ./.BCSset-<user_set_name> instead.

     This switch may not be used if a ./.BCSset-<user_set_name>
     file already exists for the named branch since this would
     allow files on the same branch to be based off of different
     points in time along the trunk.  Normally, any
     ./.BCSconfig-<user_set_name> file which contains only a date
     specification (which is the kind of file which this switch
     will generate) will be deleted along with the ./.BCSset-
     <user_set_name> and ./.BCSlog-<user_set_name> files when the
     set becomes empty.  If the ./.BCSconfig-<user_set_name> file
     contains other configuration directives, it will not be
     deleted and this switch can also be used to update the date
     in such special configuration files.



FILES
     ~/.sandboxrc
          rc file that specifies default sandbox

     rc_files/sets
          list of valid sets in sandbox

     .BCSconfig-<user_set_name>
          RCS configuration definition for branch (base direc-
          tory)

     .BCSpath-<user_set_name>
          relative directory for branch within shadow area

     .BCSset-<user_set_name>



Printed 1/23/91              4/25/90                            5





bci(1)              UNIX Programmer's Manual               bci(1)



          list of files in branch (base directory)

     .BCSlog-<user_set_name>
          record of log messages for branch (base directory)

     /tmp/b-$USER/*
          temporary files


SEE ALSO
     bcs(1), bco(1), bsubmit(1), branchmerge(1), rcsci(1),
     rcs(1), rcsintro(1),
     the RCS Cookbook.










































Printed 1/23/91              4/25/90                            6



Typewritten Software • bear@typewritten.org • Edmonds, WA 98026