Git Migration
Some of you may have noticed that in recent posts that the dm Server team has been referencing Git repository URLs. The team has been migrating all of its source code and I'm now pleased to announce that this migration is done. The list below contains the Git URLs for the code managed by the dm Server team. If you were referencing the equivalent repositories in SVN, please clone these new repos instead.
This announcement only covers code managed by the dm Server team, and not the entirety of the Spring portfolio. Other projects will be converting at their own pace and the Subversion repositories will stay open until they do.
dm Server
dm Server Samples
OSGi Web Container
| Repository | Clone URL | Fisheye URL |
|---|---|---|
| osgi-web-container | git://git.springsource.org/osgi-web-container/osgi-web-container.git | https://fisheye.springsource.org/browse/osgi-web-container |
Slices
| Repository | Clone URL | Fisheye URL |
|---|---|---|
| slices | git://git.springsource.org/slices/slices.git | https://fisheye.springsource.org/browse/slices |
Bundlor
| Repository | Clone URL | Fisheye URL |
|---|---|---|
| bundlor | git://git.springsource.org/bundlor/bundlor.git | https://fisheye.springsource.org/browse/bundlor |
OSGi Test Stubs
| Repository | Clone URL | Fisheye URL |
|---|---|---|
| osgi-test-stubs | git://git.springsource.org/osgi-test-stubs/osgi-test-stubs.git | https://fisheye.springsource.org/browse/osgi-test-stubs |
Maven PAR Plugin
| Repository | Clone URL | Fisheye URL |
|---|---|---|
| maven-par-plugin | git://git.springsource.org/maven-par-plugin/maven-par-plugin.git | https://fisheye.springsource.org/browse/maven-par-plugin |
Similar Posts
- dm Server 2.0 M3
- Using Bundlor in Eclipse
- Using an OSGi Profile with Bundlor
- Deploying WARs to the OSGi Web Container is now even easier
- Maven PAR Plugin 1.0.0.M1
David Linsin says:
Added on July 15th, 2009 at 6:11 amWhat are the reasons to choose Git over another DSCM?
Dominic Mitchell says:
Added on July 15th, 2009 at 7:59 am@David: It's damn quick. Plus, private branches are dead easy. I was explaining to somebody else the other day that what really makes git nice is that it's easy to throw work away when you no longer want it. Because local branches are so cheap, you tend to make a new one for each feature you work on. Without disturbing any other users of the software.
Neale says:
Added on July 15th, 2009 at 1:50 pmI'd be interested to hear how Spring are getting on with tools (presumably egit). I've been using Bzr recently (and will probably mirror our SVN repos on launchpad in the short term).
I'd caution against migrating the lot without some good feedback from end users, otherwise the likelihood of getting patches attached to JIRAs could decline. Naturally I think we might be expecting to see egit bundled with STS soon
Ben Hale (blog author) says:
Added on July 16th, 2009 at 12:48 pm@David
To be honest, I'm not sure there was a huge technical issue that led us to Git over something like Mercurial or any of the other DSCMs. In the end, Git had a very vibrant community and was easy to get started and educate our developers with. Those things more than anything technical sent us in that direction.
Ben Hale (blog author) says:
Added on July 16th, 2009 at 12:53 pm@Dominic
I'll second the branching notion. We've always aimed to do developer branches (I come from a ClearCase background where that was the norm), but Subversion just kept letting us down. At first, it wasn't feasible with 1.4, then 1.5's support was half-hearted and caused us more grief than it helped. If you took a look at our kernel git repository since the move, we've really embraced branching and have dozens of them in only a few weeks. We're still feeling our way along with respect to reverse-merges, rebasing, etc. but I don't think any of our developers regret the change.
Ben Hale (blog author) says:
Added on July 17th, 2009 at 1:41 am@Neale
Luckily for the dm Server team, we're not the first group in the company to move to Git. The Grails guys moved over a while back (http://github.com/grails/grails/tree/master) and haven't had any complaints from their community. To quote Graeme Rocher, the lead of the Grails project:
… we have definitely seen quite a few folks (I think around 40 so
far) forking the repository. Some of those have submitted pull
requests. The community reaction has been good, there has been no one
crying out for SVN to return which is a good sign.
Obviously we'll keep an eye out for problems, but I think we'll see the same thing Grails does.