Jon, On Tue, 2009-03-03 at 21:50 -0800, [email protected] wrote:
> [1] Make a canonical *internal* git repository on > some machine over which you have total control. > Given that the total number of committers is small, > this box could be done on a very modest box. > For the sake of argument, let's call this > machine 'internal'. s/git/(git|bzr|hg)/ > [2] Create a public repository on github. > This will be all the non-committers ever see. or Bazaar branch on Launcpad or Mercurial repository on ??? > [3] Create a post commit hook on 'internal' that > does a push to github. Because 'internal' > is the only machine that updates github, > you're guaranteed that this will always > be a trivial fast-forward operation. or Bazaar branch on Launcpad or Mercurial repository on ??? Am I missing something? GitHub allows for individuals to have repositories and for people to clone willy nilly, etc. Launchpad has this, but it also has the idea of groups of individuals and projects, i.e. it has project structuring support that appears to be absent on GitHub. The upshot of this is that Launchpad has all the branches related to a given project collected together and potentially under the control of a set of individuals and not jsut one. > [4] Make the post-submit hook on 'internal' also > send the submit over to the public hosted svn > server, for the sake of the svn folks out there. > Later, rinse, repeat for Bzr, and whatever else. > > When folks in the community wish to get the latest changes, > they just get stuff from github, or the bzr or svn host. > They need not know/care about the existence of 'internal'. > > The core group of committers never manually commit > to the git repository on github; they just commit > to 'internal' (and 'internal' handles the sync to github). > Sometimes, they might pull from the public git repositories > of the community as well, merge/rebase those changes > (and then do a commit to 'internal', which again causes > the multi-way autosync). > > This eliminates all polling and even provides you > with an opportunity to make an airlock between > what the team submits and what the world sees. > For example, you could have a CI server on 'internal' > that runs tests on the commits and asynchronously > updates a sister repository (or branch) for Gradle > that includes a summary of the test results. > > Here's some ASCII art to illustrate the notion: > > .--------->.--------->.--------->. > | | | | > | v v v > [internal] [github] [svn] [bzr] > ^ ^ | | | | | | > | | V V v v v v > committers community community community > ^ ^ | | | > | | | | | > | | v v v > | | [public community git repositories] > | | | | > | | V | > | `-------------' V > `-----------------------------' > > > What do you think? I agree that this is workable -- it is one of the standard DVCS workflows :-) I have used effectively this model for a number of collaborations, at least with Subversion and Bazaar anyway -- though Subversion doesn't count here as I am trying to remove all the repositories I am hosting! My approach has been to create a shared user and have a writeable Bazaar branch. No login passwords, only access by SSH with big SSH keys preferably with passphrases. Anyone whose keys are associated with the user can write to the branch. Every commit can trigger an event which can then do whatever we want -- though there will have to be some experimentation here as I think we are talking a custom commit hook. I think the real point here is that the Codehaus Subversion repository is no longer the mainline and commits to it will achieve nothing in terms of progressing the project. It becomes a record of development not a tool of development. -- 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
