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. 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. -------------------- ** 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
