similar to: A Fresh Start with LLVM

On Sun, May 13, 2018 at 8:48 PM Bruce Hoult via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I recommend using https://github.com/llvm-project/llvm-project-20170507 if you can spare 1.1 GB of disk and bandwidth for the initial checkout and git repo itself. > It's just a few minutes behind the svn master copies. I don't know of a better monorepo at present. > Although

I recommend using https://github.com/llvm-project/llvm-project-20170507 if you can spare 1.1 GB of disk and bandwidth for the initial checkout and git repo itself. It's just a few minutes behind the svn master copies. I don't know of a better monorepo at present. Although everything is there, things such as clang and compiler-rt aren't actually built unless you saymlink them into the

Thanks Dean and Bruce. 1.1GB is a "lot" smaller than I expected, my worry was that it might be >60GB with the entire change histories to v1.0. Disk space is not a problem (at ~€80 per TB) just ISP download caps and 1.1GB is well under the radar :-) I will get Phabricator set up for collaboration. Thanks again for your help, MartinO -----Original Message----- From: Dean Michael

Yes, it's not bad. You can actually reduce the size of the .git directory to 597 MB by running "git repack -a -d -f --depth=250 --window=250". This takes less than 5 minutes on a 16 core Xeon. Unfortunately I've never found a way to get such a nicely packed repo into github such that it checks out for others as nicely as it was when I uploaded it :-( On Mon, May 14, 2018 at

> 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 Jul 28, 2016, at 12:05 PM, Justin Lebar <jlebar at google.com> wrote: > >>> The decision of whether or not to include these projects >>> affects only read-write consumers of these projects -- of which there >>> are relatively few people. >> >> Maybe there are few, but the impact is non-insignificant. Also I think the opinions of the

> On Jul 28, 2016, at 12:59 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 28 Jul 2016 8:36 a.m., "David Chisnall via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > This does not apply to libc++. We support building the entire LLVM suite with other C++ standard library implementations (at

Hi Mehdi, I really like your idea of having a few "projected" git repositories (i.e. capture all commits that touch llvm/ into llvm.git, all that touch clang/ to clang.git etc.). I think it should solve our problem of llvm-forks-with-downstream changes very nicely (I think we won't have to do anything, as you said). I still want to sleep on it to see if I can spot any issues.

Hi Duncan, > […] > 2. Those working on projects *outside* the monolithic repo will get the downsides of both: a monolithic repo that they are only using parts of, and multiple repos that are somehow version-locked. > > 3. For many (most?) developers, changing to a monolithic git repo is a *bigger* workflow change than switching to separate git repos. Many people (and at least some

> On Jul 22, 2016, at 1:16 AM, Simon Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Ill start by saying Ive skimmed this thread and am not actually a user of LLVM at all, but had some git thoughts that might be worth contributing. > >> On 22 Jul 2016, at 01:16, Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>

Hi, In our CMake build system there are currently two ways of specifying which LLVM sub projects to build by setting CMake cache variables. * Setting `LLVM_ENABLE_PROJECTS` to the list of projects to enable (e.g. `-DLLVM_ENABLE_PROJECTS=clang;compiler-rt`) * Setting `LLVM_TOOL_<PROJECT>_BUILD` boolean CMake cache variables (e.g. `-DLLVM_TOOL_CLANG_BUILD=ON

On Jan 13, 2017, at 1:37 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The main outcome of the BoF had the dev meeting was that we agree’d that moving to GitHub was the best choice forward for LLVM (IIRC only one person in the room expressed concerned about GitHub, but he said he had personal grief with them and nothing specific for LLVM). > > The unknown that

On Fri, 3 Aug 2018 at 11:42, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > A few months ago I switched from using SVN for the LLVM project to using the GIT mono-repo, but I am still not particularly good at using GIT. How can I use the GIT command-line interface to select to the exact same set of sources used for the v7.0.0 branch, Do you mean the commit

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

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

On Sat, Jun 24, 2017 at 9:57 AM Chandler Carruth <chandlerc at gmail.com> wrote: > But now git-svn will be unable to rebuild revisions without switching URL > and breaking git hashes. Have folks tried this? What commands should > git-svn and hit mirror users use to update? > It's possible I'm off base here, but a couple of things: a) This shouldn't be a problem if

> (2) If I’m stuck using git-svn I kinda feel like there is no real point in changing anything. No real point *for you specifically*. But the vast majority of people would not be stuck using git-svn. And in addition the LLVM project would not be stuck using svn, with all the baggage, hosting issues, workflow issues (for people other than you), etc. The bar by which this proposal should be

I was under the impression that the (non-monorepo) separate LLVM and Clang git repos hosted at git.llvm.org would be maintained for a year after the transition to the mono repo. I don't recall where I got that impression from; probably from some of the many emails on the migration topic. I noticed today that updates to these repos ceased on October 22nd of last year following transition to

Hi all, Today, we maintain a high bar for getting a new subproject into LLVM: first a subproject has to be built far enough along to “prove its worth” to be part of the LLVM monorepo (e.g. demonstrate community, etc). Once conceptually approved, it needs to follow all of the policies and practices expected by an LLVM subproject. This is problematic for a couple reasons: it implicitly means that

My expectation was that they would continue to be fed from the updates to the svn repo. But again, I don't recall where I got that impression from. It may have been a bad assumption on my part. Tom. From: Anton Korobeynikov <anton at korobeynikov.info> Sent: Tuesday, February 25, 2020 12:36 PM To: Tom Honermann <thonerma at synopsys.com> Cc: llvm-dev at lists.llvm.org; Michael