RHadoop repo split into package repos

391 views
Skip to first unread message

Antonio Piccolboni

unread,
Feb 5, 2013, 7:49:54 PM2/5/13
to rha...@googlegroups.com
Hi,
in an effort to simplify version management and follow accepted github/R practices, we decided that we needed to have one repo for each package. Hence the RHadoop github repo will be from now on used only for the wiki. The code will be there but no more changes are planned. No additional issues should be added to the issue tracker. If you do they will be closed asking to open an equivalent one on the package-specific issue tracker. There will be some broken links and some confusion as we complete the transition, my apologies in advance. Please do not hesitate to point out problems. Thanks


Antonio

il...@sin-inc.net

unread,
Mar 9, 2013, 8:33:09 PM3/9/13
to rha...@googlegroups.com
What about using the main repo to include the others as submodules? Each commit of the main repo could be considered a fully compatible distribution.

Antonio Piccolboni

unread,
Mar 9, 2013, 8:53:11 PM3/9/13
to RHadoop Google Group
There's two issues here. submodules, which I explored for other goals and decided against (we use subtree instead). Read the first few matches of this and it is pretty disappointing. So let's take submodules out of your proposal and replace it with subtree, which seems to address many of the objections to submodules. Why would we do that? You are talking about distributions. Each commit of the main repo would  not be a distribution because neither are commits of the separate repos. The only distributions are the tar.gz files linked to from  the Downloads page, not because we love red tape, because we can't have hundreds of versions around and we can't test after every commit on every supported platform. Without that motivation, I have myself considered having the central repo with the other repos as subtrees, but the only reason I had was that it is technically possible and keeping them up to date, unfortunately, is a manual task. Another thing to do, another thing to forget. So right now I am for the DRY principle, the code is in one place, not in two. Of course there may be other advantages I am unaware of. Thanks


Antonio


--
post: rha...@googlegroups.com ||
unsubscribe: rhadoop+u...@googlegroups.com ||
web: https://groups.google.com/d/forum/rhadoop?hl=en-US
---
You received this message because you are subscribed to the Google Groups "RHadoop" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rhadoop+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

il...@sin-inc.net

unread,
Mar 9, 2013, 10:54:04 PM3/9/13
to rha...@googlegroups.com
There's a lot of hype about submodules being evil. I get the impression people are somehow using them incorrectly. When used for the right things they can work very well.

But your other points make a lot of sense. Of course it could probably be handled through some sort of commit hook but I'm not sure the benefit is really there once I consider what you say about the Downloads page.
Reply all
Reply to author
Forward
0 new messages