search for: monorepo

The monorepo prototype at https://github.com/llvm-project/llvm-project-20170507 is currently 9 hours behind. I forget who’s responsible for the script(s) updating the monorepo(s), and it would be great if we can inform them of the state of the monorepo. Cheers -- Dean

Hi, Thanks for starting this discussion Justin! On 10/31/18 5:22 PM, Justin Bogner via llvm-dev wrote: > Hi all, > > I've spent some time in the last couple of days trying to figure out how > to adopt the [LLVM git monorepo prototype] for an out of tree backend. > TLDR: I'm not convinced that this prototype is the right approach to > converting to the monorepo, and I have a possible alternative. > > The main problems I'm running into stem from the fact that this > prototype rewrites all of hist...

> 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...

Mehdi AMINI <joker.eph at gmail.com> writes: > > If you want a monorepo view for all of your branches' histories > > too it's more involved, but I'm not sure anyone really needs > > that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructivel...

Hi, The llvm-project monorepo (https://github.com/llvm/llvm-project) is currently missing a top-level license file. It would be nice if there was one so that anyone unfamiliar with layout of the monorepo could find it right away. I have put up a patch that adds a LICENSE.txt file to the monorepo root: https://reviews.llvm.org/...

..., >> >> Thanks for starting this discussion Justin! >> >> On 10/31/18 5:22 PM, Justin Bogner via llvm-dev wrote: >>> Hi all, >>> >>> I've spent some time in the last couple of days trying to figure out how >>> to adopt the [LLVM git monorepo prototype] for an out of tree backend. >>> TLDR: I'm not convinced that this prototype is the right approach to >>> converting to the monorepo, and I have a possible alternative. >>> >>> The main problems I'm running into stem from the fact that this &gt...

...> > Yes, but that's the case for the zipper repo anyway: one merge > per > > commit. The point is that the second commit is just a trivial > merge, > > it wouldn't show up in a file `git log` for example. > > In the linear rewritten monorepo, adding the history taken from > the > > existing git mirror would lead to duplicated commits, as in > > *identical* commit / commit with the same diff but different git > > hashes. I'd expect git log to show us the two commits in the git > log >...

On 06/18/2020 11:27 AM, Steven Wu via llvm-dev wrote: > I like the proposal but I would like to go even further. If we are going to create a top level CMake file, we should just go ahead and eliminate all the standalone build configuration. The standalone build should just be `cmake <monorepo-root> -DLLVM_ENABLE_PROJECTS=standalone-project ...`. That means less build configuration to maintain which is always good. > Eliminating stand-alone builds would be an inconvenience for us in Fedora, since this is how we build LLVM packages. However, I think we may have different definitio...

Mehdi AMINI <joker.eph at gmail.com> writes: > Yes, but that's the case for the zipper repo anyway: one merge per > commit. The point is that the second commit is just a trivial merge, > it wouldn't show up in a file `git log` for example. > In the linear rewritten monorepo, adding the history taken from the > existing git mirror would lead to duplicated commits, as in > *identical* commit / commit with the same diff but different git > hashes. I'd expect git log to show us the two commits in the git log > of a single file. Would it be valuable to hav...

Here's another question about the current status of this. It's close to two months after the official monorepo was supposed to be published. Can someone give an update? Is this on hold indefinitely? Are there concrete issues that people are working on and this will happen as soon as those are resolved? At the least, I'm assuming the "SVN will shut down 1 year from now" refers to 1 year from w...

> And if it is, then the "only thing a monorepo gets you" isn't something that you need a monorepo to get. This is an *extremely important* point to understand, so let me try to be really clear about the current state of the world and the state of the world under the two "move to git" proposals. Today, all commits ultimately...

Hello, I am trying to access https://git.llvm.org/git/llvm to be able to cherry pick some of the recent commits I did in the monorepo into our downstream llvm-only repository. The host seems defunct, is this part of the move to the monorepo? I think I can just get the patch and remove the `llvm` on top of the paths, but that’s not a scalable approach. Francesco

...39;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 concerns about (and benefits o...

By the way, I've been using the existing read-only monorepo [1] for a few days now. The intent is to commit via the script I put together [2], although I haven't committed anything other than a testing commit [3]. All I can say is, *wow* is it nice. I hid everything I don't care about using a sparse checkout [4]. Many of my tools (e.g. ctrl-p [5...

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

...confines of what's possible given that prioritization. On Wed, Oct 31, 2018 at 12:22 PM Justin Bogner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > An arguably cleaner solution would be try to recreate all of my trees' > history artificially as if they were based on the monorepo prototype > history all along, but this has two problems. First, it's a very > significant tooling effort to do this - I'd need to match up several > years of merge points to their corresponding spots in the monorepo > prototype and somehow redo all of the merges in the same way...

...the official repository going > forward. > > How do you define "best conversion" here? I may be missing something, > but I really don't see any actual advantage to re-writing the git > history from scratch rather than leveraging the existing git mirrors to > build a monorepo. > > The re-generated history approach gives us an artificial alternate > history where we developed in a git monorepo from the beginning of time. > I note that "we", where "we" = llvm upstream developers, *have* been developing in a monorepo -- an SVN monorepo, wit...

...os to the top-level. Thanks, Slava From: James Y Knight [mailto:jyknight at google.com] Sent: Wednesday, July 17, 2019 11:19 AM To: Zakharin, Vyacheslav P <vyacheslav.p.zakharin at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] change .gitignore for monorepo On Wed, Jul 17, 2019 at 12:45 PM Zakharin, Vyacheslav P via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello, My team is using some non-llvm projects along with llvm-project monorepo. The projects are checked out to the top level of llvm-project,...

...pondent 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 con...

Hi folks, Building any LLVM project currently requires invoking CMake inside <monorepo-root>/llvm, while setting the projects to enable in the LLVM_ENABLE_PROJECTS variable. This has the downside that CMake processing for the LLVM subproject happens even when one doesn't really need or want it. It's also not great from a build hygiene perspective, as LLVM globally sets som...