~bzr-pqm/bzr/bzr.dev

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
"use-case apis" - means not just the api called by the Command layer, but
also the stack going down.

top level - an atomic api - whole thing should either commit or not

needs to come back and interact with the user to get the commit message, if
not previously specified
 
hooks that will modify the wt before commit takes place;
line endings - actually not an issue for commit because we propose to always commit what's in the tree and just transform them when reading back out
 
problem with commit builder api - you need to build a whole tree in it.

takes contents of a workingtree, logically puts it into a branch and the
branch's repository
point is that it should only store the new things in the tree which are 
not already in the tree

* possibly updates the workingtree after the commit to tell it about the new
  basis revision

if you commit only a single file, you should only need to tell it about that 
single file.

if implemented with dirstate present, will still make good use of dirstate.

requirements wrt branches - bound branches do complicate it, so does bzr-svn. 

commit is an operation between the tree and the branch.

api should only be told about content changes by the tree.