nested trees design-approach : composite trees vs iter_changes

[Stephen J. Turnbull]

Martin Pool writes:

 > For those following along at home, the underlying design is described in
 > 
 >  http://bazaar-vcs.org/NestedTreesDesign

Is it reasonable to assume that Aaron is the (primary) author of
NestedTreesDesign?

 >  http://bazaar-vcs.org/NestedTreeSupport

Ditto, Robert?

-----

Both of these documents assume that a primary scenario for nested
trees involves treating the subtree as an integral, active part of the
main tree, and pushing changes back to the upstream.  I find this use
case to be pretty unlikely in my own usage.  Instead, I want the
subtree to be a passive firewall against gratuitous local changes, yet
make it convenient to upgrade to the vendor's recent code and make
*occasional* local changes to be submitted upstream.

The only time I've actually *used* such an external reference was in
an abortive attempt to replace the "native" image support in XEmacs
with libmagick.  The whole point of this effort was to delegate *all*
maintenance of imagery to the ImageMagick project; the code was used
for studying and staying ahead of distro binary releases, not for
modification.

Current plans for such a facility are in support of a long-time
bootstrap issue that XEmacs users face.  If you build the core, then
you should be able to pick and choose from the bundled packages, but
this requires the EFS and Dired packages, so you have to download and
install them by hand.  These packages are mature and (for this
purpose) extremely stable; again the nested tree is for reference (in
developing the source-with-bootstrap-packages mechanism) and for
packaging up in the release.

In these use-cases, I see no inconvenience whatsoever in cd'ing to the
nested tree and doing VCS operations on it directly.  I do want the
parent to be aware of the nested tree, and to keep track of the exact
content at the time of a commit.  I'm not sure how this would work in
bzr.  In git I would have a "hidden" branch in the nested tree that
keeps track of WIP at the time of a parent commit, but is not
"official" in the nested tree.  This would allow keeping the state of
the working tree (ie, perhaps modified) yet still allow replicating
the state of the whole tree exactly from the parent's revision.  I'm
not sure if this is what git actually does with a submodule, though.

What I would want to see in the log of the parent is

2009-05-06  Stephen J. Turnbull  <stephen at xemacs.org>

        * Upgrade EFS to r3.1.4.5.9.
          Upgrade Dired to r2.71.72.
          bzr pull --tree=boot-pkg-nested-tree

unless I specifically asked for change details of subtrees.  IOW, I
guess this would look a lot like a merge from the POV of the main
project, while it would be a pull from the POV of the subproject.