[MERGE] move smart_add_tree to MutableTree, tested on WorkingTree..

Ian Clatworthy ian.clatworthy at internode.on.net
Wed Jul 4 05:19:49 BST 2007


Aaron Bentley wrote:
> Robert Collins wrote:
>> On Tue, 2007-07-03 at 23:23 -0400, Aaron Bentley wrote:
>>> We're now saying that the whole concept of inventory is bust, and that
>>> we'd like to make it merely an implementation detail of WorkingTree.  If
>>> that's so, I don't think we should be relying on this quirky inventory
>>> behavior.

At the risk of sounding like a BUFD guy, I'd dearly love to see a class
diagram of our key classes and have some of these debates around a
picture. That itch is growing stronger each day for me. We know the
AS-IS but I get the feeling that the TO-BE is far from final, at least
in the detail. There is always risk with lots of little domain
refactorings when the target model isn't clear in everyone's heads.

I could have a rant on the stability of object models grown via TDD vs
UCD vs DDD but I won't push my luck today so soon after getting Robert
excited about Lean SD yesterday. :-)

>> So how should --dry-run operations work - I presume we want
>> add
>> commit
>> merge
>> push
>> pull
>> revert
>> remove
> 
>> to all have --dry-run eventually, which should really indicate whether
>> the command will succeed or fail.

Yes, yes, yes. --dry-run is one of the nicest parts of our UI. I love it.

> Well, for the moment, add can work the way it already does, except that
> it should guarantee that after the dry-run, the WT.inventory will be
> unchanged.
> 
> For the future, these can all generate inventory deltas, and for
> dry-run, not apply them.
> 
> Revert, merge and pull can already be put through a dry run simply by
> calling "TreeTransform.finalize" instead of "TreeTransform.apply"

Nice.

Ian C.



More information about the bazaar mailing list