/brz/remove-bazaar

 

3 - Before starting the commit proper, we prompt for a commit message

and in that commit message editor we show a list of the files that

basically the same as the list of changes we detect while storing the

commit, but because the user will sometimes change the tree after

opening the commit editor and expect the final state to be committed I

they don't seem to have substantial performance consequences.

 

If one wanted to optimize solely for the speed of commit I think

good.  Remarkably, it does not need to read the inventory for the

previous revision.  For each versioned file, we just need to get its

hash, either by reading the file or validating its stat data.  If that

     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

     the 2 parents).

 

3) **Automatic deletion of 'missing' files.** This is a point that we go

   default should abort if it finds a 'missing' file (in case that file was

   files and remove missing files automatically.

 

4) **sha1 for newly added files.** status doesn't really need this: it should

all the work to do really fast comparison and throw-away of unimportant

records.

 

ability as deep into the stack as I could get. Status has the property

that you don't care about most of the records, just like commit. So the

sooner you can stop evaluating the 99% that you don't care about, the

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.