Initially, probably something like: -web site -ldj test suite (not currenly under development) -security delegates -river trunk -anything else?
I don't experience any size issues with River on github. I'm not sure if the integration test suite should be broken out, perhaps doing so would allow us to test binary compatibility. I don't have strong feelings about it, I have heard that git history isn't as good as svn, but merge is much better. I know we've had merge issues in the past with svn, but I haven't experienced history issues with git yet. You mentioned you've had issues with git, I'd like to understand what those issues are. Are they included in posts to the stack exchange discussion list links? Cheers, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Simon IJskes - QCG <si...@qcg.nl> Sent: 13/09/2016 05:35:28 pm To: dev@river.apache.org Subject: Re: Fwd: [jira] [Updated] (INFRA-12432) Apache River migration from SVN to Git - Git commit access Could you make a proposal how to arrange the git repo(s)? Please mitigate for: http://programmers.stackexchange.com/questions/206668/using-multiple-git-repositories-instead-of-a-single-one-containing-many-apps-fro http://programmers.stackexchange.com/questions/161293/choosing-between-single-or-multiple-projects-in-a-git-repository G. Simon On 09-09-16 13:14, Bryan Thompson wrote: > I have become significantly pro-git over the last few years. I feel that > it is much more nimble, and I think the goal here is to help make river > more modular and gain the ability for an improved pace of development. > > Can you expand on your objection about scripts and complexity incurred? > > Bryan > > On Fri, Sep 9, 2016 at 1:40 AM, Simon IJskes - QCG <si...@qcg.nl> wrote: > >> If any, please dont. >> >> The amount of scripting or addons that is needed to have multiple repos >> integrated does not outweigh the perceived benefits of git. >> >> The amount of work in forking, pushing, merging etc. is a lot compared to >> subversion commits >> >> You can have your own git, sync it with subversion, and back patch the >> changes into subversion. >> >> So you can still have your own git, and have subversion for the project. >> >> OK, subversion is not as nimble as git. But so fast we are not really >> going are we? >> >> G. Simon
