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

[Alexander Belchenko]

Marco Pantaleoni пишет:
> On Thu, Jun 16, 2011 at 12:08 AM, Alexander Belchenko <bialix at ukr.net 
> <mailto:bialix at ukr.net>> wrote:
> 
> 
>     2) Developer shares some library (code, media, or other files) between
>     several projects. Such library might be even published as open source
>     project, so it may eventually have its own forks and history. Working
>     with the main projects relying on such library without nested trees is
>     not very comfortable, sometimes it's so uncomfortable that one might
>     be even forced to merge library into main project just to have the
>     ability to have a consistent project tree, if there is no nested
>     trees. There is one serious problem though: once the library is merged
>     to other project it's not possible to extract it back in it's
>     independent state. So if you want to be able to share changes in that
>     library you definitely don't want to merge it, just because bzr won't
>     let you to get it back, and you'll be forced to use cherrypicking all
>     the time.
> 
> 
> For my projects I use a simple python tool that branches all needed 
> components (creating a virtualenv). I have a master configuration file 
> (versioned in the project) which specifies repositories, branches and 
> versions for the various components.

You have just described scmproj, but the latter is not separate python 
tool but bzr plugin instead. Otherwise there is no big conceptual 
difference between both.

> 
>     our releases. Now, add there feature branches and you'll have a small
>     nightmare. I need to track history of releases, which components have
>     been used for which release and for which customer (we have enough
>     customers and for some reasons we can't provide only one release for
>     all of them, we have custom builds based on specific requirements).
>     Now think about feature branches, to properly test a new feature we
>     need to create a testing build, therefore we have to create a
>     temporary copy of the project for it. But feature branches should not
>     live too long on the server, so once the feature is merged to trunk, I
>     prefer to clean merged branches out of main pool (often to
>     intermediate limbo directories like _MERGED). So when a component
>     branch disappears we have no way to restore the old state of the
>     project. That hurts. To workaround this problem we might support local
>     changes to project config, this should be pretty easy, but that's only
>     workaround, that's not a real solution.
> 
> 
> If I am not overlooking something, this could be solved, when using a 
> tool like the above, by integrating a command creating a feature branch, 
> which at the same time creates a feature branch also for the components 
> and updates the master config file.

We have that in scmproj as project-branch command. But it's not enough. 
You have to remember to call this command in the appropriate time. You 
have to remember many things you don't really have to, that's why I 
think the tool should make your life easier.

> We'd need a way to force branching 
> of only the master project, since many times the components don't need 
> to change, or control which components should be branched, etc.
> If the server is not "stable" (branches get moved, archived, etc.) you'd 
> need some extra work from the tool (for example to try different 
> locations for the branches, the "official" ones before, than the ones 
> for archived components, etc.).

Yep, maybe supporting list of alternate locations would help. But anyway 
it requires some manual intervention and you never can be sure how 
drastically you can move/delete things on the server, just because those 
things could be a component of the bigger project.

> This approach would have the benefit of not overloading bazaar with 
> tasks not strictly related to version control. Imho, it's better to do 
> one thing and do it well, in the unix philosophy.
> Am I grossly under-estimating the problem?

Maybe not. I have many of those in scmproj today, but our number of 
branches taught me that it won't scale well when number of feature 
branches are increased, and human factor becomes predominant source of 
errors -- people tend to forget doing so and so, just because we're 
humans not machines.