Being able to quickly create git repos of the Subversion projects is exactly what these are for. See this: http://wiki.apache.org/general/GitAtApache
Don On Wed, May 6, 2009 at 7:48 PM, Rene Gielen <gie...@it-neering.net> wrote: > Another scenario I recently experimented with came up when I was thinking > about a feasible process to enable a local CI infrastructure for > experimental changes on the s2 codebase. While we have our central CI builds > set up, they only make sense for features which are targeted for immidiate > improvements and soon production, you would not want to push highly > experiental code that even might never make it into a release unless you are > working on a fresh early branch like upcoming 2.2. Nevertheless, when your > experiments turned out to be both stable and useful, you would want to push > them as a whole to the main repository. > > The solution I found was to use git-svn, which is able to make a git > repository mirror out of a svn repo (so far not that different from the new > mirror infrastructure introduced her), but also to push changes back to the > original svn. It helped me to introduce a very useful workflow, allowing me > to commit small changes to my local git repository, triggering a Hudson > build, while I went over to the next change. I'm also able to pull incoming > svn changes easily, improving the quality of the integration test and solve > merge issues upfront. After implementing and testing all changes, the commit > to the svn repo then goes as a whole. > > The only downside was that, since our svn tree is part of the huge Apache > svn repo containing all revisions of all projects, the initial creation of > the git-svn repo took about one (!!) day - it scanned about 7.3 million > revisions only to get our "small" tree synced. But once done, things run > very fast. After all, I found this workflow also very useful for my client's > projects - convincing some of them to move from cvs to svn took me ages, now > telling them that they should move over to git would make them go mad on me, > I guess. > > When I first saw the git mirror announcement, I had the still hope that the > svn push would be possible too, which not seems to be the case now. But > being a huge git fan now, I really appreciate this git integration step and > how non-committers can use it to build a good development environment. > > - Rene > > Don Brown schrieb: >> >> On Mon, Apr 27, 2009 at 3:17 PM, Wes Wannemacher <w...@wantii.com> wrote: >>> >>> Don, >>> >>> I'm not familiar much with Git. I know of it, and have read a little >>> about it. >>> Is there a significant advantage to using Git over Subversion? >> >> While Atlassian still uses Subversion, I've moved over to using Git >> for all my work and personal projects, and I've found it a much better >> tool to keep me productive (great branching/merge, sane cli, >> super-fast, etc). However, why I'm particularly excited about having >> a Struts mirror is I hope it will be a way for the community to be >> much more active in its development. With Subversion, only committers >> can make any changes, so if you as a user wrote a feature, all you can >> do is attach it to JIRA and hope for the best. If you are more >> adventurous, you could fork Struts into your own Subversion repo, but >> then you have to deal with the pain of keeping them in sync. Git, as >> a distributed SCM tool, is built for this type of decentralized >> development, and in particular, Github makes it easy to track, both >> for the user and committer. >> >> In a perfect world, we'd have an "official" Github mirror of Struts. >> If a user wanted to get rid of OGNL, they can click the "Fork" button >> and have their own repo. Once they commit their changes, they send us >> a pull request or at least create a JIRA issue and link to their repo. >> What is cool about this is the user can start using their feature >> now with minimal hassles keeping up to date with Struts trunk, but >> better yet, any other user can fork that fork and build on that >> change. You could have a whole sub-community around a certain fork, >> say, one that gets rid of OGNL and all other Struts deps, all without >> any need to have commit access. As Struts committers, it allows us to >> take our philosophy of letting the community sift through ideas to the >> next level from just ideas and JIRA issues to actual code and forked >> releases. Our job then is to pick the creme of the crop, vet the >> legal stuff, and push the chosen features back to the official Struts >> repo. >> >> Therefore, I think git will help us empower our community, make the >> committers lives easier, and deliver better code quicker. Who could >> argue with that? :) >> >> Don >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > > -- > René Gielen > IT-Neering.net > Saarstrasse 100, 52062 Aachen, Germany > Tel: +49-(0)241-4010770 > Fax: +49-(0)241-4010771 > http://twitter.com/rgielen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
