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

[Martin Pool]

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.

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.

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.

> > 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.

> The problem with split and join is that they change the location of the
> root directory.  From a subtree point of view, "join" moves the subtree
> root into a subdirectory, and adds a bunch of files above it, and
> "split" is the reverse.
>
> Revert and merge will not handle root-moves properly.  I'm not sure
> whether that's a good enough reason to disable "split" and "join".

Well, you may be best placed to decide.  If you think they are not
ripe, and will hurt more than they benefit then let's hide them.

-- 
Martin