586
586
Currently we attempt to expand/interpret the request so that the user is not
587
587
required to understand all the internal constraints of the system: if they
588
request 'foo/bar' we automatically include foo. This works to an extent but on
589
review we are creating inconsistent deltas by the way we do this. We need to
590
avoid all the known causes of inconsistency in our delta creation logic.
588
request 'foo/bar' we automatically include foo. This works but can surprise
589
the user sometimes when things they didn't explicitly request are committed.
591
Different trees can use different algorithms to expand the request as long as
592
they produce consistent deltas. As part of getting a consistent UI we require
593
that all trees expand the paths requested downwards. Beyond that as long as
594
the delta is consistent it is up to the tree.
596
Given two trees, source and target, and a set of selected file ids to check for
597
changes and if changed in a delta between them, we have to expand that set by
598
the following rules, to get consistent deltas. The test for consistency is that
599
if the resulting delta is applied to source, to create a third tree 'output',
600
and the paths in the delta match the paths in source and output, only one file
601
id is at each path in output, and no file ids are missing parents, then the
604
Firstly, the parent ids to the root for all of the file ids that have actually
605
changed must be considered. Unless they are all examined the paths in the delta
608
Secondly, when an item included in the delta has a new path which is the same
609
as a path in source, the fileid of that path in source must be included.
610
Failing to do this leads to multiple ids tryin to share a path in output.
612
Thirdly, when an item changes its kind from 'directory' to anything else in the
613
delta, all of the direct children of the directory in source must be included.
added
removed
doc/developers/inventory.txt
