[MERGE][0.15] Hide commands for nested trees.

[Robert Collins]

On Tue, 2007-03-13 at 18:11 +1100, Martin Pool wrote:
> On 13/03/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> > Martin Pool wrote:
> > > OK, well, given that we probably do need to do more than just disable
> > > the commands.  The current working tree will record tree references
> > > when it notices a subdirectory has a .bzr, which will tend to throw
> > > people in the deep end of tree references.
> >
> > This is news to me, and IMO a misfeature.  We shouldn't do by-reference
> > nesting unless the user requests it.

Uhm we discussed this on IRC a few days ago. (I'm replying to Aaron
here: I couldn't find Aarons mail in my folder). Specifically I noted
that 'add' would detect the kind correct, but that smart_add still will
skip subtrees. Also, note that without a knit3 backend, the kind
detection returns 'directory' rather than 'tree-reference', making it
identical to 0.14.

> OK, another reason to perhaps disable it for this release.
> 
> The reason for doing it this way was that dirstate generally likes to
> always trust what's on disk for the kind and other information - if
> something changes from being a plain file to a directory, we just
> accept that.  So Robert suggested we should do the same thing for
> subtrees.  Perhaps this really is different and an explicit action to
> add the reference should be needed.

I think there are two orthogonal issues here. One the one hand, I am
hugely pro reporting the actual disk status. It will let us fix up a big
chunk of commits indirections amongst other optimisations. On the other
hand I see the point that <perhaps> nested tree changes should require
explicit action. 

For the latter point though, I think its plain wrong to force a user to
go out of there way to manage this. The consequences of versioning a
subtree are no worse than adding and commiting an ISO, or other
potentially large dataset to the tree.

> Consider the case of developers who use nested trees, but at the
> moment construct them by hand.  Typically the directory containing the
> subtree will not be in the parent at all, but it might be added as
> empty.  If we use this heuristic then the first time they do a commit
> in a tree where this is active, the directory will become a reference,
> which might be confusing/surprising.

This is true. OTOH anytime we add support for something, it will
surprise people encountering it for the first time. I dont think that
surprise should prevent us from choosing the best UI for a feature, and
changing things to match. When its incompatible, warning is fine IMO. So
in this case, I'd do something like:
if the kind has changed, and its changed to 'tree-reference', warn
('Versioning nested tree %(path)s automatically').


> > > The easiest way is probably to split that kind-detection behaviour
> > > into a different workingtree class, which can remain experimental for
> > > this release.
> >
> > That would be okay.  I don't think I have time to do it before Thursday,
> > though.
> 
> I can do it if we agree it's what should be done.  I think Robert
> still wants to keep it as it is.

I think the kind logic is correct as it is, and quite clean. Changing it
would be ugly, and not help anyone IMO.

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/20070314/cdff36a3/attachment.pgp