There are more than a few reasons for this:
-
The big repository made svn slow - it also makes Git slow (yes, its that big!)
-
We have modules that could just stay untouched between releases, in big repo these had to be rebuilt, in splitup we can move to a build-when-needed approach.
-
A change in git repo will trigger every build on Jenkins - waste builds. (yes, we could filter these with SVN but its a mess to maintain)
-
Everyone thinks someone else is taking care of a module in a big repo - now its clear who owns what
-
GitHub pull-requests are awesome.
-
Easier to contribute to a smaller repo than a big one.
Not everything was migrated because some content was old/garbage/not-relevant/not-applicable to the split up. You can see JBIDE-12475 for discussion and details on how the split was made.
The following is a snapshot from the suggested layout when migration began:
| SVN location | GitHub repo | Gatekeeper | Comments |
|---|---|---|---|
| build | jbosstools-parent jbosstools-targetplatform | release engineering | Might not be available from day one |
| documentation | jbosstools-documentation | Isaac Rooskov/Max Andersen | |
| freemarker | jbosstools-freemarker | Denis Golovin | |
| forge | jbosstools-forge | Koen Aers | |
| gwt | jbosstools-gwt | Denis Golovin | |
| vpe | jbosstools-vpe | Yahor Radtsevich | |
| openshift | jbosstools-openshift | Andre Dietsheim | |
| jst | jbosstools-jst | Alexey Kazakov | |
| portlet | jbosstools-portlet | Snjezana Peceo | Kept on its own since Portal team said they would like to update/replace it |
| ws | jbosstools-webservices | Xavier Coulon | |
| xulrunner | jbosstools-xulrunner | Yahor Radtsevich | |
| hibernatetools | jbosstools-hibernate | Koen Aers | renamed from hibernatetools to follow the jbosstools-framework convention. |
| birt | jbosstools-birt | Snjezana Peco | |
|
cdi jsf seam struts | jbosstools-javaee | Alexey Kazakov | |
|
common runtime usage tests | jbosstools-base | Alexey/Rob | |
|
as archives jmx | jbosstools-server | Rob Stryker | |
|
central examples maven | jbosstools-central | Fred Bricon | maven is odd here, but dependencies prevent it to currently move. |
If that does not answer your question then please speak up on JBoss Tools Mailing list and we can help locate it or if something is indeed missing resurrect it if need be.
What happens with the SVN repostory at http://svn.jboss.org/repos/jbosstools ?
It will remain for doing old builds if it ever needs to be done again.
Content of modules in trunk that have been migrated to Git will be svn deleteed leaving
only a README.md file pointing to the new home of the repository and the module trunk will
be marked read-only to avoid suprises.
Is the svn github mirror (https://github.com/jbosstools/jbosstools-svn-mirror) still relevant ?
Since there can be changes made in the SVN repo after our migration in case of builds/fixes needed for older builds we plan to keep this mirror alive to at least have an easy way to get proper diffs for merges and comparison.
No, we'll continue to use Jira for tracking issues and you'll be happy for it since GitHub issue system is very limited and weak compared to Jira.
Before releng (Nick) would tag and branch the central svn repository, now we have multiple repositories who does the tagging/branching ?
To begin with we will continue doing "global" tagging/branches for the repositories that was part of jbosstools svn repo. Over time it will be the module owners that should do the tagging/branches for the individual repositories which then gets included into the overall build. This will be a gradual progress as we get experience and feedback on the move to git/smaller repositories.
We used git-svn to do the initial conversion of svn to git and these lines that look like:
git-svn-id: https://svn.jboss.org/repos/jbosstools/trunk@43947 a97e2381-89e5-4abb-bab3-167db6db766c
is metadata git-svn used for tracking its migration.
We could actually remove these but we opted for keeping them in for two reasons:
- It allow us to see which exact svn commit a change is from and can use that to look in the svn repo in case we want to explore for possible bad migration data.
- svn allows empty commit messages, git does not - if we removed these lines we would have to readjust all the commits that has no message in the history.