~bzr-pqm/bzr/bzr.dev

Avoiding work: avoiding reading parent data

-------------------------------------------

 

We would like to avoid the work of reading any data about the parent

revisions.  We should at least try to avoid reading anything from the

repository; we can also consider whether it is possible or useful to hold

less parent information in the working tree.

 

When a commit of selected files is requested, the committed snapshot is a

composite of some directories from the parent revision and some from the

working tree.  In this case it is logically necessary to have the parent

inventory information.

 

If file last-change information or per-file graph information is stored

then it must be available from the parent trees.

 

If the Branch's storage method does delta compression at commit time it

may need to retrieve file or inventory texts from the repository.

 

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

Repository that avoids one roundtrip per file.  

 

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

so the committed tree would not be reconstructable.  We could check that

the parent revision is present in the inventory and rely on the invariant

that if a revision is present, everything to reconstruct it will be

present too.

 

Complications of commit

-----------------------

 

Bazaar (as of 0.17) does not support selective-file commit of a merge;

this could be done if we decide how it should be recorded - is this to be

stored as an overall merge revision; as a preliminary non-merge revisions;

or will the per-file graph diverge from the revision graph.

 

There are several checks that may cause the commit to be refused, which

may be activated or deactivated by options.

 

 * presence of conflicts in the tree

 

 * presence of unknown files

 

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

 

 * the local branch is up to date with the master branch, if there 

   is one and --local is not specified

 

 * an empty commit message is given, 

 

 * a hook flags an error

 

 * a "pointless" commit, with no inventory changes

 

Most of these require walking the tree and can be easily done while

recording the tree shape.  This does require that it be possible to abort

the commit after the tree changes have been recorded.  It could be ok to

either leave the unreachable partly-committed records in the repository,

or to roll back.

 

Other complications:

 

 * when automatically adding new files or deleting missing files during

   commit, they must be noted during commit and written into the working

   tree at some point

 

 * refuse "pointless" commits with no file changes - should be easy by

   just refusing to do the final step of storing a new overall inventory

   and revision object

 

 * heuristic detection of renames between add and delete (out of scope for

   this change)

 

 * pushing changes to a master branch if any

 

 * running hooks, pre and post commit

 

 * prompting for a commit message if necessary, including a list of the

   changes that have already been observed

 

 * 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

of commit or during the scan, include

 

 * Changes made to the tree shape, including automatic adds, renames or

   deletes

 

 * For trees (eg dirstate) that cache parent inventories, the old parent

   information must be removed and the new one inserted

 

 * The tree hashcache information should be updated to reflect the stat

   value at which the file was the same as the committed version, and the

   content hash it was observed to have.  This needs to be done carefully to

   prevent inconsistencies if the file is modified during or shortly after

   the commit.  Perhaps it would work to read the mtime of the file before we

   read its text to commit.

 

 

 

(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, ...)

 

Branch->Tree interface

----------------------

 

The Branch commit code needs to ask the Tree what should be committed, in

terms of changes from the parent revisions.  If the Tree holds all the

necessary parent tree information itself it can do it single handed;

otherwise it may need to ask the Repository for parent information.

 

This should be a streaming interface, probably like iter_changes returning

information per directory block.

 

The interface should not return a block for directories that are

recursively unchanged.

 

The tree's idea of what is possibly changed may be more conservative than that of the branch.  For example the tree may report on merges of files where the text is identical to the parents: this must be recorded for Bazaar branches that record per-file ancestry but is not necessary for all branches. 

If the tree is responsible for determining when directories have been recursively modified then it will report on all the parents of such files.

There are several implementation options:

 

1. Return all files and directories the branch might want to commit, even if the branch ends up taking no action on them.

2. When starting the iteration, the branch can specify what type of change is considered interesting.

 

Since these types of changes are probably (??) rare compared to files that are either completely unmodified or substantially modified, the first may be the best and simplest option.

 

 

Open question: per-file graphs

------------------------------

 

**XXX:** If we want to retain explicitly stored per-file graphs, it would

seem that we do need to record per-file parents.  We have not yet finally

settled that we do want to remove them or treat them as a cache.  This api

stack is still ok whether we do or not, but the internals of it may

change.