powered by Jive Software

Spark git transition

Enough talking, let’s do this thing!

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.

Thoughts?

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.

Then you can set Spark’s SVN to read-only.

Let me know what you need done with Ignite’s Infra. Flow was the guinea pig and has most of it figured out already.

Great idea. How did you go about getting a list? Just export Jira users?

I can email users if I can get a list somehow. I don’t think my Jira privs let me export other accounts or whatnot.

I know Mircea will probably want to port his commits. Maybe others.

Do a git clone of the svn repository and show use the output of ‘git shortlog -sn’. I may be able to compose such a list also for Spark.

I’ll try this out later today and see if I can build a list… I owe some work to the community anyways.

I was faster Here are the commit stats of Spark:

1187 derek (*)

297 michael.will (*)

262 wolf.posdorfer (*)

158 holger.bergunde (*)

124 thiago (*)

100 mirceac (*)

60 dhenninger (*)

54 timjentz (*)

33 konstantin.zolotarev

33 matt (*)

18 andrew.seymour

11 jay

9 david

9 gato (*)

8 qa

7 mikemcmahon

4 bill

4 francisco

3 akrherz (**)

2 alex (*)

2 andrew (*)

1 guus (*)

*: I have the maping data form Smack

**: I don’t have the data, but I know who that is

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).

Also, if you are looking for easy ways to manage git via GUI, there are several good apps that can help.

The Github client is actually pretty decent, and free. They have a Windows, Mac, and Mobile version.

http://mobile.github.com/

The apps don’t let you do too crazy of stuff, but covers all the basics with the click of a button.

Eclipse IDE has several git plugins that integrate git into the IDE and allow for easy push/pulling/branching of the codebase.

Here’s probably the most popular one:

Netbeans looks like they have baked-in support for git as-of Netbeans version 7.4 and up.

https://netbeans.org/kb/docs/ide/git.html

IntelliJ IDE also has baked-in support:

http://www.jetbrains.com/idea/webhelp/using-git-integration.html

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?

PM me for contact details on those you need to find. Some of these folks are long gone.

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:

Hello $Realname,

this is second and last reminder to get your igniterealtime.org SVN

username mapped to a e-mail address of yours, so that you can claim

your commits and show the world your open-source contribution. :slight_smile:

We are currently in the process of creating a git repository out of

Smack’s SVN [1] repository and identified you as possible contributor

with the SVN username ‘$SVNUser’.

We can map your SVN username ‘$SVNUser’ to the following typical git

commit author format:

$Realname <$EMail>

If this is OK for you, or if you would like to use a different string

for your real name and/or e-mail address, then let us know by replying

to this mail.

If you don’t answer this mail, the mapping will be done 1:1 by simply

using your SVN username as git commit author.

Regards

Sounds like a plan to me. I’ve already pm’ed daryl.

PS: I’m glad you were the guinea pig

Smack’s policy is that only the project lead should write the master branch or accept pull requests. For the seam reasoning that you mention: We don’t want loq quality commits to go into master, accidental or not.

Ideally, there is also a second instance to review every commit.

I also encourage people not to make pull requests against the Ignite Realtime smack repo on github, but use my personal github repo instead.

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.

The result are stats like these: https://github.com/igniterealtime/Smack/graphs/contributors

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!)

You may be interested in this… seems Smack already has a bunch of unique repo visitors.