ensuring commit has enough tests...

[Robert Collins]

Ian expressed to me the thought that with the overhaul needed of commit,
it would be good to expand test coverage there. So this is some notes on
what full coverage at the API layer probably means - to generate a full
set of permutations (possibly programmatically) and be sure they are
covered (at the Tree.commit api level - so each tree type will have this
tested). In future Commit is possibly best seen as an interaction
between Tree and Branch, so we may want an inter_tree_branch set of
tests which would be a final home for these tests.

So - variables:
history:
 - no parents (aka 'null:' left hand parent)
 - left hand parent
 - left hand parent and pending merge(s)
 - left hand parent that is a ghost
 - left hand parent and a pending merge that is a ghost

tree shape:
 - root only
 - root dir having contents - files, subdirs, symlinks, subtrees
 - two levels of directories
 - subtrees that have:
   - nothing
   - content

type of changes since basis:
 - added paths of each type
 - removed paths of each type
 - renames within a directory which sort:
   - the same order
   - earlier (e.g. the path that is renamed is now before other content)
   - later (the opposite of earlier)
 - renames across directories which sort
   - same, earlier, later
 - renames which:
  - preserve content (e.g. dirs have the same children, files the
content, symlinks the target)
  - alter content (for all content altering cases)
 - content altering:
   - change type (file -> dir, file -> link, etc)
   - change value (file content changes, file exec bit changes, symlink
target changes, directories have children added to them, removed from
them, altered within them, or renamed within them.)

user path selection:
 - whole tree
 - subtree that isn't modified though the subtrees before and after are.
 - subtree that is modified
 - subtree that includes renames (against basis)
   - into, lexically before and after
   - out of, lexically before and after
 - subtree that includes renames (against pending merge):
   - into, lexically before and after
   - out of, lexically before and after

This is a 4 dimensioned space - there are what, 5*5*7*27 combinations,
times some overhead for trivial variations to do full coverage. I'm not
sure full coverage is needed, but to avoid needing it probably need to
ensure that our layering is such that we can test these four dimensions
separately, giving us 5+5+7+27 times the small overhead - a much more
manageable number. We need to be sure though that such layering fits
with our analysis of the least work required of commit - and where it
doesn't, where we need to combine things to reduce double handling or
increase locality of reference, then we should bear this grid in mind.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070626/a4a66421/attachment.pgp