what should be done to merge nested trees patch to bzr-core?

[Martin Pool]

On 15 June 2011 15:37, Alexander Belchenko <bialix at ukr.net> wrote:
> 16.06.2011 1:08, Alexander Belchenko пишет:
>> Anyway, we have 2 problems with feature branches for nested components:
>>
>> a) the problem with disappearance of component branches is more
>> painful in bzr than in git/hg, because bzr operates with single branch
>> per URL, rather than with single repository per URL, repository that
>> allows fetching an arbitrary revisions, required for recreating a
>> state of nested trees.
>>
>> b) automatic creation of feature branch remote counterpart for nested
>> component. If I want to create a feature branch for my root component,
>> my actions are straightforward. But if I want to be sure I won't
>> accidentally push changes introduced by this feature from nested
>> components to their trunk branches I have to be very very careful. In
>> git/hg you can just push to main repository (because see "a" above),
>> but with bzr I have to manually create feature branches on the server
>> for all affected nested components, and won't forget update the
>> project config.
>
> I've just realized that to workaround this nasty problem with feature
> branches and nested trees bzr should allow branch, pull, push and
> merge commands to be allowed to work with shared repositories as
> source/destination if explicit revision-id is provided, i.e.
>
> bzr branch /path/url/to/shared/repository -r revid:xxx foo
>
> will create a branch "foo", using revid:xxx as tip revision of the
> branch, extracting the branch history from shared repository. But we
> lose tags in this case.

There's no theoretical or format reason we can't do that, and I would
be happy to see it added.  I think there is already a bug asking for
it.

It seems like there are a few choices for tow to represent this in the
code.  Perhaps the revision spec should be able to take a repository
rather than a branch, and that will be enough.  There might be some
code that counts on getting a branch object, and then we'd have a
choice to either make one up that doesn't exist, or change it so it
only needed a revision tree.

Martin