2009/2/27 <[email protected]> > > > Adam, > > > > > http://docs.codehaus.org/display/GRADLE/How+to+contribute+a+patch+to+Gradle > ^ > > >Feedback is more than welcome. > > > > I think it's a little odd that I have to use a particular developer's > > repository, which may or may not be up to date, and may or may not have > > other changes in it. Is it possible to set up a repository on github > > which is automatically synchronised with svn? Or is it easy for someone > > to create an empty repository and sync it with svn manually? > > > > I agree. > > * > While the solution posted by Tom is helpful, > I'm hoping it's only a very short-term stopgap. > > There are two configurations I think would be preferable: > > [A] The revolutionary approach: Make Git the master repo > ------------------------------------------------------ > Every time a checkin happens on the master Git repo, a > hook could push it over to an SVN mirror. Developers > would use Git, but folks who just want to download > a particular version of the source & run it could > still fetch stuff from SVN. > > > [B] The evolutionary approach: Keep SVN as the master repo > ------------------------------------------------------- > Every time a checkin happens on the canonical SVN > master, a hook could push that changeset over to an > always-up-to-date github repo. Remote git users could > then use that as their upstream (rather than Tom's). > The bummer here is that the core team of Gradle sumitters > would still be stuck dealing with SVN merge hassles. >
I think this is the only option at the moment, if we could do the Git repo sync with SVN hooks that would be perfect. Dev repos should not be clones or forks of the repo that is synchronized by the SVN hooks, otherwise the SVN changes would be coming in on 2 branches and Devs would not be able to commit to SVN with git svn dcommit. This would also prevent us from using the Fork Queue feature of GitHub I think, but as a solution to this problem I Devs should use multiple git remotes to pull in work from forks. > > > Repository users typically fall into one of the following 7 categories: > > [1] Binary downloaders (beta testers) > [2] Source downloaders who never want to submit anything > [3] Someone who only ever submits one or two patches > [4] Active submitters who can't commit to the master repo > [5] The core team members (i.e.: committers) > [6] The admins, who can do anything at all > [7] Automated users (CI servers, etc.). > > Currently, I'm in group [3]. > > Option [A] would make things much nicer for those in groups > [4], [5], and [6], yet it would allow those in groups > [1], [2], and [3] to continue using SVN as they always have. > > SVN does not handle branch merges that well, so the chief > advantage for picking option [A] over [B] is that it would > make the lives of those in groups [5] and [6] better. ** > > > Why then would someone in group [3] like me care if > the Gradle project chooses [A] or [B] ? > > It's simple: my guess is that if merges are easy, > they'll happen faster & more reliably. If SVN > is the master, I'm not as confident that community > participation will be as robust. > > Anyway, that's my 2cents. > > > Cheers, > -Jon > > > -------------------- > * > In the end, I used a somewhat different setup from the > one Tom posted, but it was still a nice starting point. Could elaborate what you did different? > > > -------------------- > ** > I think option [A] and [B] are pretty much equivalent for group [7]. > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
