On Thu, Jun 16, 2011 at 12:08 AM, Alexander Belchenko <<a href="mailto:bialix@ukr.net">bialix@ukr.net</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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. </blockquote><div> 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. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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. </blockquote><div> 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. </div></div>Am I grossly under-estimating the problem? Marco -- Marco Pantaleoni