On 10/03/2014 12:44 AM, George Nychis wrote: > Marcus, I like the idea of an uber-repo with external submodules. That > would mean these submodules could link to a repo we could provide the > user, a repo they already have on github, or a repo they have on some > other external server. But in the end, our uber repo would point to all > of them and then they could update the commit that external submodule > points to over time. Thanks for that suggestion.
Sorry for being a buzzkill here, but I don't really like this except as a temporary/transition solution. Assume CGRAN really takes off and grows. Do you really want all OOTs out there in a single repo? What exactly is their logical connection, which would warrant them all being tied together in a super-repo? This would require someone to keep updating the submodules, too, which seems unnecessary. In the long run, I would assume people want to host their OOTs on github (or similar services), and CGRAN would simply be a link to those. As I said, during a transition time, we might want something else. But submodules are messy, and I suggest not using them for this particular application. M > Rick, thanks for this suggestion also! I will make sure that we are > able to include some sort of snapshot. When you say snapshot here, does > that act as some sort of release or history? It must be different than > a tag, since you say tags are part of a snapshot. Can you give me an > example snapshot provided by some other service? > > On Thu, Oct 2, 2014 at 7:51 AM, Marcus Müller <marcus.muel...@ettus.com > <mailto:marcus.muel...@ettus.com>> wrote: > > Hi everyone, > > that seems to be a nice solution you're proposing, George. What > about having a uber-repo that uses external submodules? This way, > you could have your single CGRAN repo, with all the packages as > submodules, some documentation in a single wiki, all per gitlab, and > just keep the projects as independent repos, hosted on a cgran > machine or on github/osmocom/wherever. We get the functionality to > backup "all the GNU Radio ecosystem" at once by running some git > submodule update command, and pybombs could just clone that repo, > and init submodules as the user installs them. > > Greetings, > Marcus > > > On 30.09.2014 01:00, George Nychis wrote: >> I agree with Martin that once we go to git, every project has its own >> independent repo. That shouldn't take much time at all to do, I can just >> run some svn2git magic to spit out separate repositories. The question >> will be where those repositories live. I can host the repositories >> again. >> I could replace the tired Trac interface with Gitlab and then host the >> repositories locally and through there. If that's the case, Github >> repositories could be forked in Gitlab and/or point to the Github repos? >> (e.g., for people who only want their code on Github). I think the >> downside of Gitlab is that it doesn't seem to be very customizable to, >> for >> example, have a coherent single Wiki of some sort like Trac dd. It will >> be >> a bunch of separate Wikis buried in to each separate repository's page. >> >> So I think we are agreeing so far on git with multiple repositories for >> each project. What we need to figure out is what the frontend is. >> >> On Mon, Sep 29, 2014 at 3:47 PM, Martin Braun <martin.br...@ettus.com> >> <mailto:martin.br...@ettus.com> >> wrote: >> >>> On 29.09.2014 14:55, Marcus D. Leech wrote: >>> >>>> I have no religious convictions about git vs svn. >>>> >>>> I'd have to change a couple of scripts [...] >>>> >>> When CGRAN was inaugurated, github wasn't as popular as it was (and GNU >>> Radio was still on SVN itself). We would not have gone for a central SVN >>> repo if github had been on our radar back then. >>> >>> I guess most people either share Marcus' sentiment, or are biased >>> towards >>> git. So, ditching SVN is pretty much a no-brainer. >>> >>> However, one major difference between SVN and git is that the latter >>> doesn't have the concept of every dir being a repo in and of itself. >>> This means if we simply pushed everything to a giant github repo, that >>> would not be terribly useful (definitely not a replacement for CGRAN), >>> although I can see that being a temp solution so that at the very least, >>> nothing is lost (a big advantage of using github is that they're less >>> likely to lose data). >>> >>> Really, every CGRAN project should be pulled into it's own little repo, >>> e.g. on github. Migrating from SVN to git is really easy (even with >>> preserving history and all). I guess we could put up instructions on >>> how to >>> do that if there's popular demand. >>> >>> However, there's also the wiki pages on CGRAN. We do need a strategy for >>> those (and a way to access them). >>> >>> Keep the ideas and comments coming, people! >>> >>> Cheers, >>> >>> M >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
