On 11-Feb-09, at 8:07 AM, Nick Guenther wrote: > Our bzr branch is at lp:mixxx, aka > https://code.launchpad.net/~vcs-imports/mixxx/trunk. sourceforge, in > it's infinite crashiness, has been holding up the imports for the last > 2 weeks, but the #launchpad people said "it should be fixed on the > next import" and that once it's in sync again to ask on > https://answers.edge.launchpad.net/launchpad-bazaar about stopping the > import (and I guess moving it out of ~vcs-imports too). Once we do > this we can empty the sourceforge project for good. > > Does this sound like a good plan? Do we want to wait until after > Features_looping is merged to switch?
There's probably never going to be a super convenient time to switch since we have 3 branches still on the go (my xmas midi branch, sqlite, and looping). However, I think it would be a bad idea to merge before 1.6.2 since it won't be any short-term gain that's worth the hassle before then. On that note, we haven't even really had a formal on-list discussion about switching to a new VCS yet, so now's probably a good time. I'll try to summarize our past discussions to the extent of my memory: Distributed version control systems (DVCS) have some nice features that would hopefully make our lives a bit easier. These include things like offline branches and better branch management in general. I also like the idea of being able to change our VCS workflow from centralized (a la SVN) to something like distributed+gatekeeper for trunk in the future. I suspect it's not worth even considering changing our workflow until 2.X, but using a DVCS will give us more options down the road. There also seems to be agreement that version controls systems in general attract fanboy crowds and flamewars that border on zealotry. We're need to cut through the crap and make sure we look at things objectively, and especially pay attention to our unique constraints (mainly cross-platform development). Roughly, my thoughts are: git === Pros: - Scales to kernel/WINE-sized projects fine - Nice changeset workflow stuff for patches Cons: - Requires a PhD to operate - Tons of out-of-date tutorials and documentation on the net, hard to figure out (there's like 100 commands) - Requires cygwin or msys to run on Windows - No Launchpad integration bzr === Pros: - Integrates _very_ nicely with Launchpad - Our repo is already mirrored in LP, we didn't have to do anything - Runs on Windows just fine (the Bzr win32 installer includes TortoiseBzr too) - Reasonably easy to use Cons: - Further cements our dependency on Python - Performance = ?? Hg === Pros: - Works well on Windows, no python dependency - Reasonably easy to use - ??? Cons: - No Launchpad integration - ??? The thing about Launchpad integration is that we could survive without it (as SourceForge's SVN integration is basically non-existent), but I think it'll do wonders for our workflow. Eg. being able to automatically close bugs via your bzr commit messages. Anyways, if anyone wants to chime in based on personal experience, please feel free to add to the above list. I personally think the cost of cementing our dependency on Python is worth getting great Launchpad integration, and I think this is one of the main reasons why we've been talking about bzr so much on IRC. I should also point out that I very limited experience with Hg, although it seemed decent when I played around with it. Thanks, Albert ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
