Hans, Sorry this got long. I suspect it really needs to be turned into a wiki page, if someone want to transfer the information feel free. I'm afraid I have to go and do JavaME things for the rest of the next 6 days.
On Sat, 2008-10-11 at 23:10 +0200, Hans Dockter wrote: > Hi, > > I had the first time a closer look at distributed VCS systems. In > particular I had a look at bazaar, bundle buggy and launchpad. I have > to say, on first sight I'm very impressed. It tears down the strong > divide between committers and non-commiters. It offers a much more > convenient and powerful way to contribute for non committers. Another > killer feature is how launchpad (optionally) enforces code reviews. > And obviously it is so much easier to informally exchange code (for > example when you are doing bug fixing together with a user, as I have > been doing frequently the last month). And there are even additional > important advantages. I'm excited. But we have to keep the Gradle svn- > only users happy. > > These questions go to Russel. Provided bazaar is master and the svn > codehaus is slave. What about: > > 1.) using svn to get the latest from branch/trunk to build a > distribution from. > 2.) checking the history of the code via svn. > 3.) submitting a svn-patch via Jira. We have to remember that Codehaus are looking at DVCS. This will be a slow thing as Ben is not able to focus on Codehaus much just at the minute. We know various other things: -- Git, Mercurial and Bazaar are the only real options. -- Git has the zeitgeist despite having a dreadful command line structure and very poor GUI tools, and dreadful integration with Eclipse, NetBeans and IntelliJ IDEA. -- Sun are backing Mercurial. -- Git is blindingly fast, Mercurial is fast, Bazaar can sometimes be a little slow. -- Git and Mercurial have a "branches in repository" model, Bazaar has a "branches as separate entities" model. -- Bazaar has Launchpad and Bundle Buggy, Git and Mercurial are sadly lacking in equivalent functionality. -- Codehaus uses JIRA, there is a Mercurial plugin for JIRA. I suspect there may be a Git plugin. Various Bazaar people object to Atlassian for FOSS because of the BitKeeper effect hindering work on a Bazaar plugin for JIRA. -- Bazaar and Mercurial have a command set sympathetic to Subversion, Git is in a world of its own. -- Git is currently by far the best for interacting with a Subversion repository. Bazaar has capability but some issues, Mercurial is catching up very slowly. -- Bazaar can have commit hooks as Subversion does. Whatever infrastructure is set up, a Codehaus project really needs to have its bug reporting and mainline source on Codehaus -- BTW I think Gradle perhaps needs to do something better with http://gradle.codehaus.org. Gairls set up a redirect from grails.codehaus.org to grails.org, perhaps Gradle should do something analogous? So for the moment, the Subversion repository should be treated as the mainline. I can think of many infrastructure organizations for which this is true even though Bazaar or Git (or even Mercurial) are the main tools of use. Git only allows interaction with a Subversion store, Bazaar has a facility for storing a Bazaar branch in a Subversion repository. The problem with this (and why I stopped doing this with Gant) is that the current Codehaus Subversion commit reporting system uses svnlook which reports all changes to properties in full as well as changes to files. The Bazaar plugin for dealing with Subversion uses properties (in a way similar to SVK) to store Bazaar branch version information. This leads to ever increasing and large commit emails -- where the bulk of the email is about the Bazaar store information. Ben is aware of the issue but not is a position to change anything -- the problem is trivially solved by using the Python (or Perl? I am not sure as I use the Python program) commit hook. This does not report the property changes in detail so the commit emails look very much like a Subversion or Git one. However Ben was not prepared to change the Codehaus commit hook last time I communicated with him on this. If I didn't get these ever increasingly big emails on commit I would still be using Bazaar as my principle tool for Gant, putting the full Bazaar branch into the Subversion store. I much prefer Bazaar overall to Git, but I am having a period of Git being the main tool for developing Gant. Hopefully I can switch back to Bazaar soon. All this switching is possible only because the Subversion repository is treated as the mainline! I have not yet tinkered with having a mainline in Bazaar or Git and then having the Subversion repository be a mirror of that, but... Using Bundle Buggy as an example -- but this is not to say it cannot be done with other systems: When a vote on a submitted patch results in a commit to the Bazaar mainline that Bundle Buggy maintains, a hook (Bazaar commits have hooks just as Subversion commits do) can be triggered. This hook could fire off a job on some server somewhere that used Bazaar to inject the commits into the Subversion repository from the Bazaar mainline. Thus the Subversion store would be an almost immediately updated mirror of the Bazaar mainline. > If we were to move to Bazzar, the developers would have to use it. > They could not choose to use svn instead. For contributions it would > be also the preferred way. I think this is true (even if Git or Mercurial are used instead of Bazaar). > There is an IntelliJ plugin out there for bazaar. Russel, what would > I have to do, if I would like to use bazaar locally but then get the > changes into codehaus svn as well as merge from codehaus svn? There is indeed a Bazaar plugin for Eclipse (actually there are two) and one for IntelliJ IDEA. I don't use them that much though as I tend to use the command line even when using IDEs. Recently though all three plugins have evolved quite dramatically and have become more usable, so I need to rethink things. My problem is that I often have Eclipse and IntelliJ IDEA working on the same project concurrently. The crucial element in using Bazaar or Git with Subversion is to have the plugin (bzr-svn and git-svn repectively). Creating a local version: bzr branch https://svn.codehaus.org/gradle/gradle-core/trunk GradleCore_Trunk git svn clone --stdlayout https://svn.codehaus.org/gradle-core GradleCore these operations will take a while (many tens of minutes). Then when wanting to make sure you are up to date with the Subversion repository: bzr rebase :parent git svn rebase Bazaar keeps an idea of parent and child, Git keeps an idea of Subversion parent/child and Git siblings. Rebasing means putting your local changes on top of any changes from the parent. Changesets get renamed so be careful. When you commit locally: bzr commit -m "..." ... git commit -m "..." ... then when you want to send in a batch of local commits to the Subversion store: bzr dpush git svn dcommit Bazaar has a tool for checking differences between branches: bzr missing Git fails to have anything quite so useful. Both Bazaar and Git have integrated help systems so: bzr help git help Mercurial has recently acquired the convert command which looks like it might allow two-way working between a Subversion repository and a Mercurial repository but I haven't played with it. It is very new. Historically Mercurial has been able to create a Mercurial repository from a Subversion repository but to go the other way required a lot of ugly hacking. I hope this contributes positively to progress, it is certainly a long email :-) -- Russel. ==================================================== Dr Russel Winder Partner Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 London SW11 1EN, UK. m: +44 7770 465 077
signature.asc
Description: This is a digitally signed message part
