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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Tue, 2007-07-03 at 13:07 -0400, Aaron Bentley wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Robert Collins wrote:
>>> This moves smart_add_tree as I discussed yesterday. Because its not
>>> fully refactored - it still uses inventory, and uses os specific
>>> functions not transport functions while it is on MutableTree (where i
>>> think it should be), its only functional on WorkingTree today.
>> In that case, I would expect MutableTree.smart_add_tree to raise
>> NotImplementedError, and WorkingTree to implement it.
> 
> I felt that that would just cause more churn when the next step is
> taken. I can move it there if you insist; my preference is to leave the
> location as is for now.

I guess it's okay temporarily.

>>> # Bazaar merge directive format 1
>>> # revision_id: robertc at robertcollins.net-20070703023836-\
>>> #   etkrpxm2rmbhqgaj
>>> # target_branch: http://bazaar-vcs.org/bzr/bzr.dev
>>> # testament_sha1: 78604b8a043e3386e4f782001f3118e92379c465
>>> # timestamp: 2007-07-03 12:39:32 +1000
>>> # source_branch: sftp://rookery/~/public_html/baz2.0/add
>> ^^^ could you please set the public branch to one I can use?
> 
> I haven't pushed at all; generally when I'm sending bundles I don't see
> any need to push?

Well, because the bundle had CRLF line endings, it wasn't recognized as
a bundle.  So bzr tried to merge from
sftp://rookery/~/public_html/baz2.0/add

>>> === modified file bzrlib/inventory.py // last-changed:robertc at robertcollins.net
>>> ... -20070703023332-jz0qdt2dwhzjuhlc
>>> --- bzrlib/inventory.py
>>> +++ bzrlib/inventory.py
>>> @@ -1047,6 +1047,10 @@
>>>                          child_dirs.append((child_relpath+'/', child_ie))
>>>              stack.extend(reversed(child_dirs))
>>>  
>>> +    def make_entry(self, kind, name, parent_id, file_id=None):
>>> +        """Simple thunk to bzrlib.inventory.make_entry."""
>>> +        return make_entry(kind, name, parent_id, file_id)
>> If you want it to be a method of Inventory, wouldn't it make sense to
>> migrate the code there?  bzrlib.inventory.make_entry can invoke
>> Inventory.make_entry if it's a static method.
> 
> The main reason I did that was to avoid importing inventory just to get
> at a function which really should have been a method on Inventory in the
> first place. As we're not trying to do a lot with Inventory today I
> didn't see any value in moving stuff around further.

Well, it's borderline.  I certainly hope we're not going to let
bzrlib.inventory deteriorate in readability.

>>> +        :param save: Save the inventory after completing the adds. If False
>>> +            this provides dry-run functionality by doing the add and not saving
>>> +            the inventory.  Note that the modified inventory is left in place,
>>> +            allowing further dry-run tasks to take place. To restore the
>>> +            original inventory call self.read_working_inventory().
>> ^^^ Retaining the modified inventory doesn't mesh well with dirstate
>> trees.  I think if we're introducing this as a new function, it would
>> make sense change this behavior.
> 
> Huh? Meshs well AFAICT - in what way doesn't it?

The interactions between inventory and dirstate mean that we have to
periodically sync them.  When we do that, doesn't it potentially hit disk?

My feeling was that ability to change the inventory without writing it
to disk, and without intending to ever write it to disk was an
unintentional feature, and not something to rely on.

>> It would be nice to use apply_inventory_delta instead.
> 
> That may be true; however for now this is an improvement ?

Sure.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGiv5m0F+nu1YWqI0RAlXTAJ90wOWUGaqiIv1yn1xyucPBOZrbtgCfRTpp
cRBAKplfNzmepmGaE1f3dWU=
=sV+U
-----END PGP SIGNATURE-----