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
