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
