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

[Marco Pantaleoni]

On Thu, Jun 16, 2011 at 12:08 AM, Alexander Belchenko <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.

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'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.).
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?

Marco

-- 
Marco Pantaleoni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110616/e9b7f839/attachment.html>