similar to: [cfe-dev] Updates on SVN to GitHub migration

What's the status here? Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated with the current status of things? And once things are usable, probably update https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo as well. On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev < lldb-dev at lists.llvm.org> wrote: > On 2018-10-24

On 10/11/2018 03:27 PM, James Y Knight via llvm-dev wrote: > TLDR: https://github.com/llvm-git-prototype/ exists as a read-only mirror of SVN, and is being updated continuously with a script running on an llvm-project AWS VM. > Hi James, What is the current status of the monorepo, have you resolved all the known issues with the history? Are there any other changes that need to be made

Isn’t the checkout a local operation that should not involved GitHub ? Did you mean the clone operation ? And about sparse-checkout, I though they require a full clone of the repository anyway. Is there a way to do a partial clone only ? Note: If you don’t need the whole history local, you may perform a swallow clone (using —depth 1). > Le 9 nov. 2018 à 01:02, Anton Korobeynikov via llvm-dev

It'd be nice to know what about our repository is breaking it. Do they have any idea what that is? For example -- I think that we probably will want to archive+discard many of the random branches and tags currently in the repository. If the large number of branches and tags is breaking it, then maybe it just starts working after we do so. On Thu, Nov 8, 2018 at 3:53 PM Anton Korobeynikov

On 04/24/2020 03:24 AM, Sam McCall wrote: > clangd's experience using github issues to track bugs (in a separate repo) has been very positive, and I'm glad you're pushing on this! > > Part of this has been that our issue tracker has been scoped to our subproject only, which is a scope that the tool works well for (on the user and developer side). > As such I don't

On 10/16/2019 12:02 PM, Roman Lebedev wrote: > On Wed, Oct 16, 2019 at 9:55 PM Tom Stellard <tstellar at redhat.com> wrote: >> >> On 10/16/2019 07:31 AM, Roman Lebedev wrote: >>> +1, please. >>> >>> Also, putting a tag on the *first* commit in the repo, >>> and doing `git describe --match FIRST_COMMIT_TAG` will be *great*! >>>

Hi, I would like to start using GitHub Actions[1] for CI testing on the release/* branches. As far as I know we don't have any buildbots listening to the release branches, and I think GitHub Actions are a good way for us to quickly bring-up some CI jobs there. My proposal is to start by adding two post-commit CI jobs to the release/9.x branch. One for building and testing (ninja checka-all)

Speaking on how to locate/enable projects (like clang/lldb) - even with the monorepo, I'm still enabling clang/lldb by symlinking them into llvm/tools, for one specific reason: CMake and relative paths. As long as all the source that is being built is below the toplevel CMake directory, and the build directory itself is within the toplevel CMake project directory, CMake uses relative

On Fri, Nov 16, 2018 at 4:04 PM NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Hello, David. > > On Sat, Nov 17, 2018 at 7:46 AM David Jones via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi James, >> >> I've started working with the prototype layout in context of Google's >> internal infrastructure. With deep apologies, I

Hi, We are still on track to retire SVN and complete the transition to GitHub by Oct 21, 2019 (This year's US Dev Meeting). Even though this 3+ months away, it is very important that you begin to migrate your workflows to GitHub as soon as possible. For developers, this means using the git-llvm script to commit changes and for CI systems or other read-only use cases can begin fetching code

Excuse my ignorance (I'm not great with Git) but how would it differ for workflows of people who use a Git repository for local work but still use `svn up + patch + svn commit <list of files>` to actually land post CR or for NFC patches, while resolving conflicts during a pull into a local (non-trunk) branch manually, after the eventual full switch to GitHub? I'm aware that SVN

> 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

[ I am initially copying only a few lists since they seem like the most impacted projects and I didn't want to spam all the mailing lists. Please let me know if other lists should be included. ] I submitted D68230 for review but this is not about that patch per se. The patch allows update_cc_test_checks.py to process tests that should check target asm rather than LLVM IR. We use this

It sounds like we need to get someone from the Foundation (chandlerc@, lattner@, tanya@, someone else?) to reach out to them offline about this. On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer <arthur.j.odwyer at gmail.com> wrote: > On Wed, Mar 20, 2019 at 2:19 PM Tom Stellard via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > >> On 03/20/2019 10:41 AM, Zachary

> 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

Hi Galina, It seems that our libcxx bots are now triggering builds for any changes to llvm: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434 Should I file a bug report for this? Thanks, Diana On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits <cfe-commits at lists.llvm.org> wrote: > > Hello everyone, > > The staging master is

Sorry for the delay in writing this up and sending it out, but I wanted to recap the discussion from the roundtable on October 23rd. The roundtable ran for almost two hours and we discussed at most of the main points in my RFC. Thank you everyone who participated and contributed to the discussion! TL;DR: We should move to CMake 3.15 (RFC incoming). We should make `all` really `all`. We should

On 10/16/2019 07:31 AM, Roman Lebedev wrote: > +1, please. > > Also, putting a tag on the *first* commit in the repo, > and doing `git describe --match FIRST_COMMIT_TAG` will be *great*! > Do we need to add a tag or is `git rev-list --count HEAD` good enough? -Tom > Roman. > > On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev > <llvm-dev at

Hi James, I've started working with the prototype layout in context of Google's internal infrastructure. With deep apologies, I have a (very late, I know) pair of requests that have only recently solidified for me. 1. Could you add annotated tags after the cut point of each release? (I think this would probably be easy.) 2. Could you mark branch/tag operations somehow other than a

Hello build bot owners! The staging master is ready. Please feel free to use it to make sure your bots would work well with the monorepo and github. The following builders could be configured to build monorepo: * clang-atom-d525-fedora-rel * clang-native-arm-lnt-perf * clang-cmake-armv7-lnt * clang-cmake-armv7-selfhost-neon * clang-cmake-armv7-quick * clang-cmake-armv7-global-isel *