Feedback on commit docs

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Here's some feedback on the commit performance doc.

> 1.0 - Store new file texts: if a versioned file contains a new text there is no avoiding storing it. To determine which ones have changed we must go over the workingtree and at least stat each file. If the file is modified since it was last hashed, it must be read in. Ideally we would read it only once, and either notice that it has not changed, or store it at that point.

Actually, other VCSes do avoid it.  It's more a policy thing that we
don't want users to have to notify bzr when something changes.

> 1.1 - Store a tree-shape description (ie inventory or similar.) This describes the non-file objects, and provides a reference from the Revision to the texts within it.

It's possible that the tree-shape description could be only a partial
description.

> 1.3 - Do delta-compression on the stored objects.

It's unclear whether we'll continue to do delta compression at commit time.

> 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 will be committed: basically the output of bzr status. 

Actually, this is deferred as late as possible.

> Specifically, the commit code has to read the files because it is going to add the text to the repository, and we want it to compute the sha1 at that time, so we are guaranteed to have the valid sha (rather than just whatever the last cached one was). So we want the code to return 'None' if it doesn't have an up-to-date sha1, rather than reading the file and computing it, just before it returns it to the parent.

This seems to imply that status needs to recalculate the sha1.  That is
rarely true; if the file size has changed, status can tell that the file
is modified from the stat value alone (and the generic implementation
works this way).

> 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

I think this is more of an implementation issue than a question of how
to record it.  See http://bazaar-vcs.org/BzrCherrypickMetadata

> The branch needs to build an inventory to commit, which must include unchanged files within changed directories. 

Again, it may be that we only need to record changes from the previous
revision, not the whole inventory.

Aaron

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGjA9e0F+nu1YWqI0RAkLHAJ9XOc0niMcB9JIbJF+hKWhYkGvXjwCbBIww
i1le4+ymazBbFzwxwlQF5xs=
=JvVv
-----END PGP SIGNATURE-----