|
2513.1.1
by Martin Pool
(in progress) analysis of commit |
1 |
"use-case apis" - means not just the api called by the Command layer, but |
2 |
also the stack going down. |
|
3 |
||
4 |
top level - an atomic api - whole thing should either commit or not |
|
5 |
||
6 |
needs to come back and interact with the user to get the commit message, if |
|
7 |
not previously specified |
|
8 |
||
9 |
hooks that will modify the wt before commit takes place; |
|
10 |
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 |
|
11 |
||
12 |
problem with commit builder api - you need to build a whole tree in it. |
|
13 |
||
14 |
takes contents of a workingtree, logically puts it into a branch and the |
|
15 |
branch's repository |
|
16 |
point is that it should only store the new things in the tree which are |
|
17 |
not already in the tree |
|
18 |
* possibly updates the workingtree after the commit to tell it about the new |
|
19 |
basis revision |
|
20 |
||
21 |
if you commit only a single file, you should only need to tell it about that |
|
22 |
single file. |
|
23 |
||
24 |
if implemented with dirstate present, will still make good use of dirstate. |
|
25 |
||
26 |
requirements wrt branches - bound branches do complicate it, so does bzr-svn. |
|
27 |
||
28 |
commit is an operation between the tree and the branch. |
|
29 |
||
30 |
api should only be told about content changes by the tree. |