Tom, On Tue, 2009-03-03 at 22:09 +0100, Tom Eyckmans wrote: > 2009/2/27 Russel Winder <[email protected]>
> I also try to do it with maintenance branches but to avoid the > plethora > of branches sometimes don't for them. > That is understandable. :-) > I had thought that Kevin O'Neill had set up a Groovy mirror > repository > that does auto update on GitHub. Perhaps he does it with an > external > cron job? > > Perhaps it would be better to plugin some logic into the svn commit > hook so to remove the need for polling? Is this possible at codehaus? I don't think so. Last time I communicated with Ben about Subversion commit hooks, I go the impression that change was nigh on impossible. > I find working with individual branches on Launchpad for > exchanging > changesets between development branches straightforward to > understand. > > I'm not sure on how the changes on the dev branches get committed to > svn could you explain how this works because I don't have experience > with Bazaar on this point. I think I am missing the problem here. Bazaar and Git are just being used as Subversion clients when working with a Subversion repository -- though Bazaar can also store all the Bazaar branch metadata in the Subversion repository so that Subversion is storing a Bazaar branch; Git cannot do this. > Is there an easy explanation of how to do the same with Git? > > I think if we could get a dedicated repo up on GitHub for the svn sync > it would work in the same way. But still don't know how the parenting > issue is solved with Git, perhaps that falls into place when I > understand the Bazaar way of working. The problem here is that as soon as Git makes a commit to a Subversion repository it performs a rebase. This destroys the history as far as any other Git repository is concerned. AS far as I can tell there is no workflow based on Git that can treat a Subversion repository as a peer. Git can be used as a Subversion client but not on a DVCS basis. Bazaar has the ability to treat the Subversion repository as a peer, i.e. as a Bazaar branch. This changes the game since then there is no rebase. Bazaar does however suffer a performance penalty for this capability (even if you don't use it). Because of all the extras Bazaar can do compared to Git, Bazaar's interaction with a Subversion repository is slow compared to Git. So as a Subversion client where interaction performance is required then Git is a good tool -- but only as a client, you cannot use that Git repository as part of a DVCS network. For Gant I am now storing Bazaar branches in the Codehaus Subversion repository. It all seems to work well -- albeit a little slow at times. It means though that I can safely use DVCS workflows and processes with the branches safe in the knowledge that there are no rebases going on that are not consistent with DVCS practice. Unfortunately given that I am the only developer -- Graeme uses Subversion when he tinkers with Gant, and Peter passes me Bazaar revisions when he tinkers with Gant -- the efficacy of all this has not been tested. The upshot of all this is that if DVCS approaches are desired for Gradle then there are a number of options. 1. Use Bazaar and store a Bazaar branch in the Subversion repository. Launchpad may or may not be used for experimentation. 2. Use Bazaar and Launchpad or Git and GitHub as the sole mechanism of development and then create a separate mechanism for updating the Codehaus Subversion store simply for the record. Both Bazaar and Git (and indeed Mercurial but we don't seem to be discussing that?) have email hooks and so the mainline could create an event on every commit that could cause Subversion commits. What we are missing here though is discussion of how to manage a mainline. there are many models of which three seem to apply: 1. A human individual is responsible for the mainline and committing all changes to it. This is the Linux model (effectively) and Bazaar, Git, and Mercurial are all equal on this. 2. Have an automated voting system so there are no explicit commits to the mainline. As far as I am aware the only way of doing this is with Bazaar and BundleBuggy. This is how Bazaar itself is developed and that seems to work very well. 3. There is no control and chaos ensues (this might be termed the Groovy model ;-) -- 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
