Thanks everyone for your input. We'll keep the Linaro GCC 4.6 work on Launchpad/Bazzar, mainly for the following reasons: 1. Bazzar's merging is much easier and more reliable 2. Good integration with a bug tracker, blueprints, and release system 3. Ability to host early versions of patches that still need the license and copyright assignment sorted out
This leaves us the visibility problem, and that it's hard for other GCC developers to pick up our branch and play with it. Let's discuss these at today's meeting. It's a good time to talk about Bazaar as well. I've started the page: https://wiki.linaro.org/MichaelHope/Sandbox/BzrIssues Please record any specific issues, with enough detail to reproduce them, on the page. I'll consolidate the problems and get them fixed. -- Michael On Thu, Nov 18, 2010 at 3:52 AM, Andrew Stubbs <a...@codesourcery.com> wrote: > On 17/11/10 09:57, Andrew Stubbs wrote: >> >> On 17/11/10 03:35, Michael Hope wrote: >>> >>> There's two open questions: >>> 1. How easy is it to frequently merge in SVN? It used to be terrible >>> as you had to manually track the merges. These days can you do a 'svn >>> merge trunk' and have it just work? >> >> Subversion 1.5 supports merging that appears to be equivalent to bzr >> merging (within SVN's somewhat different concept of branching), and >> should do the job nicely. > > Oh, I should say, neither SVN merge, nor BZR merge will work for merging > *to* trunk. (Both will be suitable for merging *from* trunk.) > > Doing a merge like that will a) flatten all the patches into one monster > patch, and b) include all the other bits and pieces you don't want on the > main trunk (release version numbers, etc). > > Obviously, there are ways to work around these issues, but I'm just saying > that a straight merge probably isn't what you want. > > Andrew > _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
