Hi Mark, Your couchdb links don't seem to me to argue for or against what I was suggesting, other than pointing out that unless git project == releasable subproject you'll have an impedance mismatch, which is what I was trying to point out and avoid.
The git docs http://book.git-scm.com/5_submodules.html certainly seem to indicate that my suggestion should work fine and when I suggested it on the aries list David Bosschart mentioned that JBoss has been using submodules in this way for a long time with great success. What's your evidence that submodules won't work for this? thanks david jencks On Dec 3, 2011, at 4:32 AM, Mark Struberg wrote: > David PLEASE DONT SPLIT ALL INTO SINGLE GIT REPOS! > > > This is a HUGE nightmare to maintain! > > You will NOT be able to just treat this nicely! > > Please go over and first read what I wrote on the OpenEJB dev list and what > we wrote together on > http://wiki.apache.org/couchdb/Git_At_Apache_Guide > > and especally on > > http://wiki.apache.org/couchdb/SVNvsGIT > > Trust me, you don't want to inependently maintain 350 git repos! > > There will (to my knowledge) be NO sane way to check out the project in one > go anymore! > > You could certainly move all specs into one GIT repo, all of geronimo into > another, etc but having too many independent repos is _really_ a nightmare > for each developer! > > > LieGrue, > strub > > > > ----- Original Message ----- >> From: David Jencks <[email protected]> >> To: [email protected] >> Cc: >> Sent: Friday, December 2, 2011 9:02 PM >> Subject: Re: Accepting proposals regarding early git adoption >> >> Anyone can already use git locally, there are apache mirrors of most svn >> projects and many project's committers expose a lot of work-in-progress on >> github (e.g. karaf) >> >> See e.g. http://wiki.apache.org/general/GitAtApache >> >> This is asking for projects that would like to use git instead of svn for >> their >> canonical apache repository. While I enthusiastically use git almost all >> the >> time including for almost all my geronimo work I think geronimo is too >> complicated to be a useful guinea pig for git at this point. I think it >> will >> take a lot of thought and time to figure out how to divide up the geronimo >> history into appropriately sized git projects. For instance: >> >> - each spec is separately releasable so it's a separate git project. Then >> we need an aggretator project to build them all at once for convenience. >> Same >> for bundles. >> - the server code was originally under cvs at root and only later moved >> under >> server. How will this history make it into git (this is probably solved >> already >> but I haven't looked) >> >> thanks >> david jencks >> >> On Dec 2, 2011, at 11:14 AM, Jay D. McHugh wrote: >> >>> Is the idea for this to abandon SVN and move completely over to git? >>> >>> Or is it just to add git as a way for folks to manage their local copies of >> the source? >>> >>> Jay >>> >>> On 11/29/2011 03:22 PM, Kevan Miller wrote: >>>> Forwarding (with permission), in case there's interest within >> Geronimo community. >>>> >>>> --kevan >>>> >>>> Begin forwarded message: >>>> >>>>> From: Joe Schaefer<[email protected]> >>>>> Subject: Accepting proposals regarding early git adoption >>>>> Date: November 28, 2011 8:28:17 AM EST >>>>> To: Apache Infrastructure<[email protected]> >>>>> Reply-To: Joe Schaefer<[email protected]> >>>>> >>>>> While many of you are aware of the ongoing "experiment/alpha >> test" >>>>> with git hosting for CouchDB, you may not be aware of the recent >>>>> members@ discussion about git @ Apache, the result of which is to >>>>> solicit proposals here for projects interested in adopting git now, >>>>> rather than after the testing phase is over. >>>>> >>>>> Any such projects you participate in should write a brief and civil >>>>> proposal as to why we should select you for further git testing. >>>>> Proposals should include statements of interest in assisting with >>>>> the git hosting codebase and associated jira issues from named >>>>> individuals on the project. >>>>> >>>>> We'll allow the remainder of the week to collect proposals >> before >>>>> deciding on who gets to go next. >>>>> >>>> >>
