~bzr-pqm/bzr/bzr.dev

     happened several commits back. There are several edge cases to be

     handled here, like if both branches modified the same file, or if

     just one branch modified it.

  b) The trickier case is when a file appears unmodified since last

     commit, but it was modified versus one of the merged branches. I

     believe there are a few ways this can happen, like if a merged

It is desirable to avoid roundtrips to the Repository during commit,

particularly because it may be remote.  If the WorkingTree can determine

by itself that a text was in the parent and therefore should be in the

 

There is a possibility here that the parent revision is not stored, or not

correctly stored, in the repository the tree is being committed into, and

This creates a CommitBuilder object matched to the Branch, Repository and

Tree.  It can vary depending on model differences or by knowledge of what

is efficient with the Repository and Tree.  Model differences might

 

 

1. Ask the branch if it is ready to commit (up to date with master if

   any.)

 

* the working tree basis is up to date with the branch tip

 

  is one and --local is not specified

 

 

* a hook flags an error

 

* if there are tree references and recursing into them is enabled, then

  do so

 

 

 

Updates that need to be made in the working tree, either on conclusion

* or an indication that it should be read interactively from the ui object;

* a list of files to commit

* an option for a dry-run commit

* timestamp, timezone, committer, chosen revision id

* config (for what?)

* option for local-only commit on a bound branch

* option for strict commits (fail if there are unknown or missing files)

* option to allow "pointless" commits (with no tree changes)

(This is rather a lot of options to pass individually and just for code tidyness maybe some of them should be combine into objects.)

 

>>> Branch.commit(from_tree, message, files_to_commit, ...)

This needs to collect a list of added/changed/removed files, each of which

must have its text stored (if any) and containing directory updated.  This

can be done by calling Tree._iter_changes on the source tree, asking for

 

In the 0.17 model the commit operation needs to know the per-file parents

 

(In this and other operations we must avoid having multiple layers walk

over the tree separately.  For example, it is no good to have the Command

The main things the tree needs to tell the Branch about are:

 

* A file is modified from its parent revision (in text, permissions,

  Files should also be reported if they have more than one unique parent

  revision, for repositories that store per-file graphs or last-change

  revisions.  Perhaps this behaviour should be optional.

 

* The complete contents of a modified directory, so that its inventory

  text may be stored.  This should be done after all the contained files

 

 

  In a zoomed-in checkout the workingtree may not have all the shape data

  for the entire tree.

This might be construed as an enhanced version of ``set_parent_trees``.

We can avoid a stat on each file by using the value that was observed when

it was first read.

 

 

Selective commit

However, the tree walking code does probably need to know about selected

paths to avoid examining unselected files or directories.