Push mirror of SVN repository to GitHub?

[pah]

There are a bunch of rapidjson forks available on GitHub already, each with a different set of fixes and with differing histories. See for instance (skipped the ones without any additional fixes/features beyond the current trunk ):

• chrismanning/rapidjson (by @chrismanning, with C++11 integration)
• kanma/rapidjson (by @Kanma, several additions)
• pah/rapidjson (my personal fork, see svn/trunk branch for SVN history)
• rjeczalik/rapidjson (by @rjeczalik, Cmake integration, Git submodules)

Is there any chance to merge those repositories to be based on a single, "official" SVN mirror here at GitHub? Even if the current upstream development of rapidjson seems to have slowed down, maybe a more collaborative model could help to keep the project alive and to join forces among the current users.

Thanks for your work on rapidjson!

[pah]

I missed to mention scanlime/rapidjson by @scanlime, which contains a DeepCopy function proposal (somewhat conflicting with my proposal in pah/rapidjson#2).

[rjeczalik]

+1

[chrismanning]

An "official" mirror would definitely be a good thing.

I would not recommend using my fork as my changes A) were very inconsistent, B) introduce STL which rapidjson was originally explicit to avoid (for whatever reason), and C) sacrifice a little performance, from replacing some (as I said, very inconsistent) placement news with swaps, IIRC.

I've been using my own BSON library (jbson) for a while which parses JSON directly to BSON with decent performance and a nicer interface which fulfills my needs, so I'm unlikely to work on rapidjson any more.

[pah]

@miloyip: Thanks for starting to push code to GitHub. Can you please briefly comment on your plans regarding the short-term development of rapidjson? Are you willing to accept pull-requests via GitHub?

My GitHub fork contains a slightly dfifferent git-svn history, correctly attributing the changes to your GitHub account (see svn/trunk branch here). Do you want to adopt this branch as master in the official repository? Otherwise, I would recreate my fork to become a real GitHub fork and start submitting pull-requests for the issues fixed in my repository.

Thanks,
Philipp

[miloyip]

@pah I wrote a little bit at this wiki. Solving long-awaited issues should be the first priority. And I hope to finish document and examples in order to make a release. I am open on these plan.
Actually rapidjson is my first open source project and I am lack of experience running it. I will be glad if you can give me advices. Or we can discuss via gtalk or other means.

[pah]

Yes, I saw the wiki pages. The roadmap mostly covers the longer term development. I'm currently more interested in an efficient way to address the "fixes to open issues", i.e. by reintegrating the patches that are floating around in the Google code issue tracker as well as in the different forks here at GitHub.

I'll drop you a mail with my Gtalk/XMPP/Skype handle, maybe we can come up with a good process to efficiently handle this merging process.

[ArtemGr]

Glad to see you guys beginning the process of processing the process. : )

[pah]

@miloyip: As you may have seen, I have now opened several pull-requests with my patches against the new official upstream repo here at GitHub.

The "fixes/xx" pull-requests (#9, #10, #11, #12, #13, #14) are all against the master branch , whereas the "feature/xx" pull-requests are against the dev branch (#15, #16, #17).

Please let me know what you think, I'd happily adjust the changes based on your feedback.