Hi John, <div class="gmail_quote">On Fri, Mar 26, 2010 at 1:36 AM, John Szakmeister <<a href="mailto:john@szakmeister.net">john@szakmeister.net</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> On Thu, Mar 25, 2010 at 1:19 PM, Eric Berry <<a href="mailto:elberry@gmail.com">elberry@gmail.com</a>> wrote: [snip] <div class="im">> I don't quite understand. To be honest, I haven't performed a full migration > with bzr yet either. At least, not one where I've had to worry about hooks > and plugins. Are you referring to migrating a single bzr branch, or a full > bzr repository, and are you cautioning that the plugins and hooks won't go > along with a push? </div>There was a long description of the process to move your subversion repository from one location to another (svn dump, copy your hooks, copy DB_CONFIG, create the new repo, load it, copy the hooks back, restore DB_CONFIG), but a short one for Bazaar and Git. I see several faults with that. One is that the procedure for Subversion is what it is to help make sure you get all your hooks back into place, but the Bazaar version didn't account for that. You could move the repo by just pushing it somewhere, but that doesn't take care of the hooks because they're plugins, and plugins don't get transferred. And, Bazaar operates only on branches, so to take a whole shared repository isn't a matter of a single pull/push. Also, the Subversion story is much simpler these days. FSFS is the default backend. So you can simply tar up the repo, and untar it somewhere else. Couple that with svnserve (my preferred hosting technique), and it's really not so hard to move a Subversion repo. </blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im"> > From my understanding, a bzr branch, or repository can be migrated using > simple methods like rsync, or just taring up the entire directory. I'm > assuming the same could be done with installed plugins and hooks. Is this > correct? </div>That is true. But that's not what was outlined in the slides. The hooks story gets a little more interesting if it's installed system-wide or just for the user hosting the repositories. A system-wide install would be more difficult to just tar up the hooks and plugins. Either way, those hooks aren't stored with the repo or branch, they're stored in either ~/.bazaar/plugins or have been installed system-wide in $SITE_PACKAGES/bzrlib/plugins/.</blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I think in the end, Subversion is easier than was outlined, and Bazaar is a little more complicated than outlined. I personally think it's a wash. Some would say that the hosting story is better for Bazaar, but as I'm currently trying to do that (and setup appropriate access permissions and such), I'm inclined to disagree with that as well. </blockquote><div> <div> Thanks for explaining this. It is a good point, and I will update the presentation to state that the process shown is the simplest method of migrating a single bzr branch, or Git clone, and that it doesn't migrate hooks or server-side plugins. I added some extra notes about migrating a bzr repository, but it should be more strongly noted. As for taring up the SVN repo, I thought this was discouraged, especially when moving to a different file system. My understanding is that the svnadmin/dump process is the preferred and recommended method of migration. Which still makes my point valid. Migrating a SVN repo the recommended way is still way more complicated than migrating a Bazaar repo. In my experience, the more steps there are to a procedure, the easier it is to forget one. :) </div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> OTOH, there are some great features in Bazaar that you can't match with Subversion today. Branching and merging being the biggest. Subversion does have merge tracking, but you have to tell it whether you're re-integrating or not (and we usually forget that at some point, which means we have to revert and try again). Bazaar's Just Works for most merging operations (the one place Subversion has Bazaar beat is with cherry-picking revisions, but we do that relatively little in our environment). The other nice feature is true rename tracking. In Subversion, if you branched and made some fixes, then tried to re-integrate those on trunk, but the files had been renamed on trunk... well, you lose. It patches the old version of the file (although it may actually raise a tree conflict today... I haven't tried this in a while). :-( Bazaar recognizes that the file was moved, and correctly patches it. Bazaar's ability to have the entire history of the branch at your fingertips is also very nice. Coupled with qlog, it's extremely powerful. On the flip-side, for a really active repository (multiple committers, and fairly frequent changes), you have to constantly update your branch/working tree in Bazaar whereas Subversion will silently rebase your changes. The plus side for Subversion is that your developer's aren't constantly faced with errors telling them to pull and update. The down side is that you can't checkout revision X and have the exact same working copy that you did when you made the commit. Bazaar rigidity here helps to ensure you can always get back to that exact state. Maybe it's worth talking about that stuff in the presentation?</blockquote><div> I do. One thing that I think the presentation is missing is at least one slide on this very subject. I covered merging a little bit when I explained how bzr has made my life easier at work, but I can certainly include some of these other ones. Renames are a true benefit, but unfortunately, you only really gain this benefit when it's hosted by bzr. Renames in bzr, still come across as a delete and add when committed to a SVN repo (understandably so). But it's still a great feature to bring up. The logs are also a nice feature. I've often shown-off BazaarExplorer to my co-workers, and the log viewer always raises some Ooohs, and Ahhhs. :) Are there any others you can think of that would be worth showing? </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I don't think the advantages/disadvantages are as cut and dry as "Bazaar is better than Subversion" or "Git is better than Subversion" (despite Linus's opinion). It really depends on how your organization uses those tools, what the structure is, what's willing to change about that structure, what tools are you willing to put into place to help cope with some of the differences (such as PQM-like entity to help merge changes to trunk), and whether the kind of data your putting under VCS is suitable (one project I've worked on in the past had a lot of media and multi gigabyte binary files... that would fail under most DVCSs today because of the assumption that they can hold the entire content in memory). </blockquote><div> I completely agree. Popular tools exist because they help their users. If SVN didn't serve a purpose, it wouldn't exist, or at least, it wouldn't have survived and become as popular as it has. SVN has served us very well up until this point, and it's because of some recent developments with a larger and more distributed team that it's just now starting to "fail". We are certainly making due with SVN, but moving to a DVCS, would make our lives easier, and it's my opinion that Bazaar is the right DVCS for our needs. This is primarily due to Bazaar's flexibility, it would allow us to work the way we want, team to team. Each team can make use of a different work flow, or combination of workflows to fit their needs. This is something Bazaar does well I think. It's ability to work the way we want to work is really (in my opinion) what sets it apart from the others. Just m2c. Eric </div></div> -- Learn from the past. Live in the present. Plan for the future. Blog: <a href="http://www.townsfolkdesigns.com/blogs/elberry">http://www.townsfolkdesigns.com/blogs/elberry</a> jEdit <<a href="http://www.jedit.org">http://www.jedit.org</a>> - Programmer's Text Editor Bazaar <<a href="http://bazaar.canonical.com">http://bazaar.canonical.com</a>> - Version Control for Humans