search for: multirepo

...s commits from the existing monorepo mirror and commits them via SVN. It's annoying to do, but it is possible today to atomically commit to multiple subprojects, as you observed. Under the monorepo proposal, this becomes much easier. It's just "git commit", no magic. Under the multirepo git proposal, this becomes either impossible or much more complicated. Under the proposal, we have separate git repositories for each subproject, and we push directly to these. There's then an umbrella repository, which includes the subproject repos as git submodules. There's a script whi...

...o variants, but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. I spent some time today thinking through what set of questions would get us the data we want. - I've focused on the main conce...

...doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. >> >> Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. >> >> I spent some time today thinking through what set of questions would get us the data we want. >> - I'v...

...repositories. I can have patch queues that include LLVM commits and clang commits arbitrarily interspersed with one another -- something I didn't realize I wanted until I made the switch and noticed I already had branches I could merge (and something we can't do with Bogner's suggested multirepo workflow). [1] https://github.com/llvm-project/llvm-project [2] https://github.com/jlebar/llvm-repo-tools [3] https://github.com/llvm-project/llvm-project/commit/38a6db646d8f43cd9d7cec6c0533e40946cd162f (which, embarrassingly, has a typo in the commit message) [4] http://jasonkarns.com/blog/subdir...

..., but it doesn't force the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. > > Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. > > I spent some time today thinking through what set of questions would get us the data we want. > - I've focused on...

> The only thing a monorepo gets you that strictly isn’t possible without > it is the ability to commit to multiple projects in a single commit. > Personally I don’t think that is a big enough justification, but that is > my opinion, not a fact. Okay, I just bumped into r277008, in which commits to llvm, clang, and clang-tools-extra all have the same SVN revision number. I don't

...o mirror and commits them via SVN. It's annoying > to do, but it is possible today to atomically commit to multiple > subprojects, as you observed. > > Under the monorepo proposal, this becomes much easier. It's just "git > commit", no magic. > > Under the multirepo git proposal, this becomes either impossible or > much more complicated. Under the proposal, we have separate git > repositories for each subproject, and we push directly to these. > There's then an umbrella repository, which includes the subproject > repos as git submodules. Ther...

...maintain said mirrors in exchange for getting a monorepo as the canonical source of truth. > and those mirrors will have all the technical hurdles and drawbacks that a submodule repository would have. I don't understand this. The point of the mirrors is to allow people to use a read-only multirepo workflow. I agree that if one chose to do so, one would bite all of the drawbacks of a multirepo workflow, but...that's the point? Maybe I'm missing something. > The question here is: Do you make downstream single project users work off potentially unreliable mirrors, or do you make t...

...includes one submodule update. That would be fairly simple to add. > >> and those mirrors will have all the technical hurdles and drawbacks that a submodule repository would have. > > I don't understand this. The point of the mirrors is to allow people > to use a read-only multirepo workflow. I agree that if one chose to > do so, one would bite all of the drawbacks of a multirepo workflow, > but...that's the point? Maybe I'm missing something. What I’m referring to is that since we don’t have the ability to run server-side hooks on github the submodule reposit...

...ce the respondent to think about the specific issues. I'd rather find a way to ask about the specific concerns raised in the document. >>>> >>>> Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. >>>> >>>> I spent some time today thinking through what set of questions would get us the data we want. &g...

...> queues that include LLVM commits and clang commits arbitrarily >> interspersed with one another -- something I didn't realize I wanted >> until I made the switch and noticed I already had branches I could >> merge (and something we can't do with Bogner's suggested multirepo >> workflow). >> >> [1] https://github.com/llvm-project/llvm-project >> [2] https://github.com/jlebar/llvm-repo-tools >> [3] https://github.com/llvm-project/llvm-project/commit/38a6db646d8f43cd9d7cec6c0533e40946cd162f >> (which, embarrassingly, has a typo in the...

...that include LLVM commits and clang commits arbitrarily >>> interspersed with one another -- something I didn't realize I wanted >>> until I made the switch and noticed I already had branches I could >>> merge (and something we can't do with Bogner's suggested multirepo >>> workflow). >>> >>> [1] https://github.com/llvm-project/llvm-project >>> [2] https://github.com/jlebar/llvm-repo-tools >>> [3] https://github.com/llvm-project/llvm-project/commit/38a6db646d8f43cd9d7cec6c0533e40946cd162f >>> (which, embarrass...

...fairly simple to add. >> >> >> and those mirrors will have all the technical hurdles and drawbacks that a >> submodule repository would have. >> >> >> I don't understand this. The point of the mirrors is to allow people >> to use a read-only multirepo workflow. I agree that if one chose to >> do so, one would bite all of the drawbacks of a multirepo workflow, >> but...that's the point? Maybe I'm missing something. >> >> >> What I’m referring to is that since we don’t have the ability to run >> serv...

Folks, It's 1st of September, and we don't have the document nor the survey ready. With the US meeting on 3-4 November, that leaves us only 2 months to do everything, and I'm not sure we'll be able to if we delay much more. Being the devil's advocate and hoping this doesn't spiral down (again), there were a few pertinent questions left unanswered from the previous

...> put their bias on top. Given the nature of this problem, we should > avoid bias whenever possible, especially when interpreting the > answers. > > >> Thirdly, I'm worried that the follow-ups talk about "preferred" and "non-preferred" instead of "multirepo" and "monorepo". This makes data-mining non-trivial (because the meaning depends on previous answers) and increases the chance of respondent confusion. > > I see your point. We can re-word to make that more clear. > >> 4. How often do you work on a small LLVM sub-pr...

...flow depends very much on "how we're moving to > git". That's exactly what I understood. :) > For example, if we do a monorepo, I may now need to lay code out > differently on my filesystem (since I currently check out multiple repos > rooted at llvm), or if we do a multirepo I probably need to learn some > new commands to associate llvm and clang repos (rather than using git > svn find-rev). If we do something where there's a monorepo of some of > the stuff but not all, I probably have to adapt to things from each. My point is: either way, you'll have...

> On Jul 28, 2016, at 10:53 AM, Justin Lebar <jlebar at google.com> wrote: > > Thanks again for your thoughts, Chris. > >> As a straw man I would suggest the following criteria for inclusion into the mono-repo: >> >> (1) Projects in the mono-repo must be tightly coupled to specific versions or commits of other projects in the mono-repo > > I'm fine

On 19 August 2016 at 18:20, Justin Bogner <mail at justinbogner.com> wrote: > The one time cost of the mono-repo proposal is drastically different > than that of the multi-repo. True. But maybe not as different as from one company / project to another. I'm assuming some people will suffer a lot more than others on either choice. > I already use git, but depending on how

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > Justin Lebar via llvm-dev > Sent: Wednesday, July 27, 2016 1:32 PM > To: Chris Bieneman > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [RFC] One or many git repositories? > > Thanks for elaborating, Chris. > > > Case Study 1 - Simple development

Hi all- I was wondering if anyone knew what the status/schedule of the SVN to git/github transition was? I thought I saw that at the November meeting it was agreed upon, but I'm not sure I saw any progress since? Thanks, Erich