I believe we’ve satisfied all prerequisits to integrate git into our infrastructure (we have a recent bamboo, jira and install4j).
It appears Smack has made or is making the switch to Gihub and Flow already has setup the repo and things are looking nice. I suggest Spark follows suit.
The igniterealtime.org community has been setup on github, and Spark already has a shared repo there (alongside Smack).
(needs re-sync, has gone stale)
To move forward I propose the following:
1) Someone with access investigates how involved switching the build system and ticket system to point to the git repo.
2) We do a planned “commit freeze” for one day.
a) Gives time to perform the last sync between the svn and git repos (I can do this via either svn2git or subgit to preserve at much history as possible)
b) Gives time to actually perform the configuration changes to point at the git repo
3) “Beautify” the new git Spark repo to be more git/github friendly (ie. add .gitignore, .gitattributes, markdown version of the readme, etc)
4) Afterwhich we put the svn repo into an “archive” role and make it read only (for legacy). (no new commits to the svn archive).
We don’t have a ton of active developers on Spark at the moment, which really makes this an ideal time to do the switch.
I can assit you with the migration. It’s basically
git svn clone (–stdlayout)
But, you need to decide if you want to remap the users. I wrote all Smack SVN contribtors an e-mail asking if they want their SVN username mapped and if so, to which e-mail address.
If you want to remap, then you need to use git filter-branch. I have a filter script ready from Smack’s git migration, that reads a CSV file and does the mapping.
So, a dumb question from a sysadmin guy I do SVN sync with RapidSVN and have Spark project setup in NetBeans. Occasionally someone post a patch on the forums. I apply it to the code in NetBeans, test, tell if something wrong or attach it to a ticket in Jira.
What will change for me? Should i use another tools to sync the current code?
You will need to use git instead of SVN. That’s all.
Plus you can improve your workflow regarding testing patches: With git you would create a test branch - I recommend using the issue key as name so FOO-123 becomes branch ‘foo123’ - apply the patch and test it. You then can make additional modifications to the code within that branch, and, if you think that branch is ready for merging, you can create a pull request for that branch (either to pull into the master branch or to pull into the offical git repositiory as feature branch for the project lead to decide when to merge).
I use Eclipse myself, but I tend to use git on the cmd line instead of relying on the plugins/apps. Git isn’t hard once you learn the basics.
For applying patches and testing, basically just as Flow said. You would clone the repo locally, then create a local branch, apply the changes and test. If it’s good, it can be merged into the relevant branch on github.
Ya, def. beat me! I left the office before my repo clone finished last night lol.
OK, so that looks like it leaves only 8 committers to track down. I’m assuming we have email addresses for all 8 either from their svn user or jira user. Do you want to PM me the details you have and I’ll start emailing today?
Flow, what way are you controlling your Smack repo for contributions?
I sortof have the mindset that nobody (accept maybe core trusted group) should commit directly to the main repo, but instead fork/branch and use pull requests.
This would help guard against accidental bad commits (line ending changes, white space changes, etc, and the resultant revert commits to fix them), especially as people get used to git I expect some commit mistakes to be made.
I suppose this is similar to what we have now.
Everyone should check this video/slides out. It's from Zach Holman's talk about how Github uses Github.
[http://zachholman.com/talk/how-github-uses-github-to-build-github/](http://zachholman.com/talk/how-github-uses-github-to-build-github/)
I suggest you contact Daryl about the e-mail addresses of the missing contributors. Then writen them an e-mail asking if they want their commits mapped, if yes, which author name and author e-mail should be used for the mapping.
You should wait about 2 weeks for answers. And then pm the answers to me so that I can perform the mapping and upload Spark to github.
Plan?
For reference, here is the template I used for the Smack mapping mails:
I almost forgot: You may want to mention in the mail that the people may want to be mapped to their e-mail address they also have registered with their github account.
I like this. I was about to say nobody commits to the main repo, only allow merges/pull-requests from forks, including maintainers, but thought I’d get pushback.
I don’t favor maintaining a “maintainer’s” repo in addition to the master repo, since the project lead may or may not always be active. Perhaps this works well for Smack, but for Spark I think more-or-less pull-requests are ok against the main repo, since the maintiner still must review it before accepting. Maybe different branches, a stable branch and a development branch?
Anyways, might be jumping the gun here, since we still have some buildup time before making the switch.
good point. I was planning to mention it was a move to github so any github handles should be mapped if desired. github users love their stats! (bragging rights!)
