bk resolve(7.3ce)           BitKeeper User's Manual          bk resolve(7.3ce)

NAME
       bk resolve - merge and/or apply new work after a pull

SYNOPSIS
       bk resolve [<options>] [<file> ...]

DESCRIPTION
       After  a  bk pull, use resolve to merge and/or apply new work.  Resolve
       is automatically run by the bk pull and bk push  commands  but  may  be
       rerun to finish a previously uncompleted resolve.

       In order to preview the new changesets before merging, run bk csets and
       that will run csettool on the list of changes (which may  be  found  in
       RESYNC/BitKeeper/etc/csets-in).

       Resolve  traverses all files in the repository (or the specified set of
       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
       => symbol  "conflicts"  (local  and  remote added the "alpha" symbol to
          different deltas)

       When there are no conflicts left to be merged, resolve groups any merge
       changes into a changeset and moves everything 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.


OPTIONS
       -a          Automerge.   This  will  run a diff3-like merge of all non-
                   overlapping lines.   If  there  are  overlapping  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 interactive 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 com-
                   pletes is immediately used and the resolver advances to the
                   next file.
       -c          No conflicts.  This option tells resolve to complete if and
                   only if new non-conflicting work appears in the patch.
       -l<log>     Log  operations  to  <log>  (or stderr if no destination is
                   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 ver-
                   sion 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.
       --batch     do not do interactive resolve of  any  conflicts,  do  only
                   whatever can be automerged and then exit. (This was the old
                   -s option).  Implies "-a".
       -T          Text-only. Enables the text-based resolve menu  when  doing
                   the final commit instead of using citool.
       -x<glob>    Exclude  (don't  resolve)  files  matching the glob pattern
                   specified.  This option may be  specified  multiple  times.
                   See RESOLVING SUBSETS section below.
       -y<comment> Use  <comment>  as  the  changeset  check-in message.  This
                   option is typically  set  by  the  calling  program,  i.e.,
                   bk pull.   If <comment> is not present, resolve will prompt
                   for one at commit time.

RESOLVING SUBSETS
       Include and/or exclude patterns may be used to control which files  are
       resolved.  This may be useful when unrelated changes by different engi-
       neers are being merged.  To see which files will need to be merged  run
       bk conflicts.

       There  may  be  multiple include and/or exclude patterns.  The patterns
       are a file glob the same as used by bk ignore.   Patterns  are  matched
       against  the  partial pathname from the root of the repository.  If the
       partial pathname matches any of the exclude patterns then the  file  is
       skipped.   If  there  are  one or more include patterns but the partial
       pathname does not match any of the include patterns then  the  file  is
       skipped.  Exclude processing takes precedence over include processing.

       If  there  are  renames  in the update and files which need renames are
       selected then the resolver will force the resolution of  those  renames
       first.   Currently, the include/exclude selection process is applied to
       the name used after the rename resolution, which can be confusing.   It
       may  be  easiest  to  run  the  rename resolution passes first with "bk
       resolve -12", list the conflicts with  bk  conflicts,  and  then  rerun
       resolve selecting the files to be resolved.

       bk  resolve  must  be run without specifying any subset of the files in
       order to fully complete.

PASSES
       The resolver currently has four passes (phases), each with a  different
       function.   A  given pass must be completed before the next pass can be
       started.  Using options listed below, the user can specify which passes
       are  to be run on a particular invocation of the resolver.  By default,
       the resolver attempts to complete all four passes.

       The first pass looks through both the incoming and local changes to see
       if  any  files  have  been  renamed.  If there are files that have been
       renamed, they are marked and put  in  a  special  BK-managed  namespace
       where they await rename processing.

       In  the second pass, the files marked and saved in pass 1 are inspected
       to see if there are any rename conflicts.   That  is,  if  a  file  was
       renamed  in  both  the  local  and remote repositories with a different
       pathname in each.  If this is the case, the user is prompted to resolve
       the  conflict.   In the other cases, the resolver can infer the correct
       pathname and relocates the file out of the special BK-managed namespace
       and  into  the  proper place in the resolver working directory (usually
       named RESYNC).

       The third pass examines all files looking for content conflicts.   Con-
       tent  conflicts  arise when either the contents, symbolic link destina-
       tion, or file modes have been changed both  in  the  local  and  remote
       repositories.  These changes can be automatically resolved without user
       input as long as the changes don't overlap.  In the  case  where  auto-
       matic  resolution  is unsuccessful, the user is prompted to resolve the
       conflict manually.

       After all the conflicts have been resolved, the fourth pass attempts to
       apply  the  changes  to the local repository by moving the files out of
       the resolver working directory and into the local repository.  If  this
       cannot  be  completed  for  some  reason (permission problems, modified
       files in the local repository, etc.), the operation  is  aborted.   Any
       changes  made  to  the  local  repository are removed, and the resolver
       working directory is left intact.  The user can then fix  the  problems
       that caused the error, then re-run the resolver to apply the changes to
       the local repository.

SEE ALSO
       bk conflicts
       bk csets
       bk pull
       bk push
       bk resolving

CATEGORY
       Repository

BitKeeper Inc                         1E1                    bk resolve(7.3ce)