[RFC] proposed user doc for nested trees

[Vincent Ladeuil]

>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:

<snip/>

    jam> Or as Stephen hinted, we could add a property to the revision, to
    jam> indicate whether they were combined or not...

I'd rather add that to the CB revision.

<snip/>

    jam> Anyway, you can argue the atomicity is because of the containing tree,
    jam> but there is at least an argument that you want to maintain the version
    jam> of 2 subtrees in some form of 'lock-step'

But then the uncommit scenario strikes again. Back to square one.

<snip/>

    jam> I think you are missing the fact that if you 'commit in the plugin', and
    jam> then 'commit in the CB', the same change shows up "in the delta
    jam> associated with the CB revision", as if you did a recursive commit.

You're right, we need some additional info. As mentioned above
that can be specified in the CB revision by differentiating the
commits created during a recursive commit from the CB and the
commits created explicitly in the NT. I don't really like the
distinction, but if it's needed for uncommit, so be it.

    >> 
    >> Now, do the nested trees share a repository or not ?
    >> 
    >> If they share the repository, it's easier to guarantee that the
    >> nested tree revisions are present when handling the containing
    >> branch revisions.
    >> 
    >> If they don't... the fun begins.

    jam> In Aaron's spec they do, because you have:

    jam> base/
    jam>  .bzr/
    jam>    branch/
    jam>    branches/
    jam>      NT1/.bzr/branch/
    jam>      NT2/.bzr/branch/
    jam>    checkout/
    jam>    [repository?]
    jam>   subdir/.bzr/
    jam>     branch/location => ../.bzr/branches/NT1
    jam>     checkout/

    jam> However, as part of the spec, we want to be able to do:

    jam>   bzr branch http://bazaar-vcs.org/bzr/bzr.dev

    jam> and have it also grab
    jam>   lp:bzr-svn

    jam> (for example)

    jam> However, I'm pretty sure Aaron is leaning towards forcing there to be
    jam> local branches for all subtrees. (So even if you did 'bzr co
    jam> --lightweight .../bzr.dev', you would have a local branch for bzr-svn,
    jam> rather than a lightweight checkout of lp:bzr-svn.)

    jam> I'm not positive to that fact though, and I don't think he has mentioned
    jam> it in NestedTreeDesign yet.

I think that point is a very important one and should be clearly
defined.

        Vincent