Hi Daniel, I've been using bzr+svn at my company since late 2010 with a decent amount of success. It works as advertised for inter-bazaar trading, and works generally well for bzr-svn. Some rather important bugs to watch for: <ul><li><a href="https://bugs.launchpad.net/bzr/+bug/485601">https://bugs.launchpad.net/bzr/+bug/485601</a></li><li><a href="https://bugs.launchpad.net/bugs/887880">https://bugs.launchpad.net/bugs/887880</a></li><li><a href="https://bugs.launchpad.net/bzr-svn/+bug/628354">https://bugs.launchpad.net/bzr-svn/+bug/628354</a></li> </ul>At my work, we were attempting to use svn as the main trunk point, with bzr simply behaving as an svn client. This met with a lot of problems when everyone was hosting their own repo's on their own computers. There seems to be a bzr-svn bridge problem that causes revisions to not maintain consistency between computers, so we would hit issues where we couldnt merge each other's changes, and couldnt save or update from trunk. The solution ended up being a slight workflow adjustment. Rather than having developers commit to svn directly from their own machine & own repository, we started requirement them to remote into a central shared repository using putty. Basically, no dev ever directly pulled or committed changes from subversion, but rather, they'd all use the shared repo. This solved the broken repositories and changes... and without too many hassles. A bit of developer re-training, but it worked well. Never had any stability or speed problems really. We have some large binaries checked in, and it all has functioned without a hitch for a while. Apart from the inconsistent versioning issue (which as far as I am aware can only be worked around by the previously described setup), it's been an all-round win. Most of our devs were happy subversion users... and now they're even happier bazaar users. The primary down-side is the lack of tool integration, and the unreliability of Bzr Explorer on larger trees under Windows. The linux tooling is much slicker... so we generally only use the command line bzr, and the qbzr tools (qcommit, qshelve, etc.). I'm happy to field any questions or queries :)Cheers,Philip <div class="gmail_quote">On 7 June 2012 21:17, Alexander Belchenko <<a href="mailto:bialix@ukr.net" target="_blank">bialix@ukr.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Daniel Carrera пишет:<div><div class="h5"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hey, This is an opinion question: Do you think that it is easier for a project using SVN to migrate to Bzr than to Hg or Git? Well, for Git I think the answer is obvious... so I'm thinking more of Bzr vs Hg. I am thinking of things like: * Foreign branches and the ability of the bzr-svn bridge to let an SVN user switch to using bzr as an SVN client. The idea is that this gives an easier transition path, as long as it works well. So it relates in part to the quality of the bzr-svn bridge. * I'm also thinking about how easy or hard it might be to actually migrate a repository to Bzr... I know that this is a place where Hg struggles a bit and I think I heard once that this has slowed down Hg's acceptance (but don't quote me on that). I'd be interested in any thoughts you have to share on this topic. </blockquote> </div></div> bzr-svn plugin is very good on the task of either importing 1 branch or several branches from SVN to bzr. And as I remember it allows you to pull new content from SVN later. Usually it just works. </blockquote></div> -- Philip Peitsch Mob: 0439 810 260