[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