similar to: Reminder: SVN will be retired on Oct 21, 2019 -- Please migrate your workflows to github ASAP.

I've found that for first-time users (myself included) it's easy to accidentally commit a series of SVN commits with git llvm push. If we expect that a lot of folks will be switching over, might it be worth adding a warning to the script when more than one commit will be pushed? On Fri, Jul 12, 2019 at 12:48 PM James Y Knight via cfe-dev < cfe-dev at lists.llvm.org> wrote: > On

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"

Hello, I was wondering what was the current expected practice for committing patches to LLVM now that the Git monorepo is here. I have commit access to SVN but when I try to land my patched through GitHub I get an error saying "Permission to llvm/llvm-project.git denied". Depending on the answer, the documentation might need to be slightly clarified: the getting started documents for

Hello. I'm developing a LLVM based project and I'm using a fork of LLVM and Clang repos from https://github.com/llvm-mirror . The workflow was merging my work with release_XX branches from these repos, so now I have my commits interspersed with upstream ones. I'd be grateful for any advice on how should I move my work towards official git monorepo. I want to preserve my history, of

That last post I see on this mailing list is from November <http://lists.llvm.org/pipermail/llvm-dev/2016-November/106941.html> concerning the results of the survey. So I was wondering what the latest status for moving to github? -- Wnk -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello everyone, We are in the middle of porting the majority of zorg to GitHub/monorepo. The following build factories will be ported and if you use one of those for your bots, you are all covered: * ClangBuilder.getClangCMakeBuildFactory (31 bots) * ClangBuilder.getClangCMakeGCSBuildFactory (2 bots) * LibcxxAndAbiBuilder (23 bots) * SphinxDocsBuilder (7 bots) * UnifiedTreeBuilder (11

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

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

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 Oct 13, 2016, at 11:03 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > | 6. How important is cross-project blame, grep, etc.? >   <> > I don't understand "cross-project blame" as it works on one file at a time? True, not straightforward blame. My workflow when trying to track the history of some code involves frequently

> On 2016-Oct-13, at 11:23, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi, > > Thanks a lot Duncan, I really like this! I totally support adopting this scheme now. See inline a few quite minor comments. > > Renato: are you still interested and available now to set-up the survey? We should close on this *this week*. > > >> On Oct 12, 2016, at 7:07

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 *

> On 2016-Oct-13, at 13:51, Renato Golin <renato.golin at linaro.org> wrote: > > On 13 October 2016 at 03:07, Duncan P. N. Exon Smith > <dexonsmith at apple.com> wrote: >> 6. How important is cross-project blame, grep, etc.? >> - Vital. I already use SVN/monorepo/custom-tooling to accomplish this. >> - Extremely. It should be easy enough that everyone

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 19 August 2016 at 19:35, Justin Bogner <mail at justinbogner.com> wrote: > I think you misunderstood what I meant here. Whether "moving to git" > will affect my workflow 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

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

When retiring a command test for a free_callback associated with their buffer. If there is one call it. This allows language bindings to use this mechanism to automatically decrement a reference to the persistent buffer (note: this patch does not implement this). The vast majority of this change is simply passing around the handle so we have it when we call nbd_internal_free_callback in

> On Oct 13, 2016, at 11:56 AM, Renato Golin <renato.golin at linaro.org> wrote: > > Hi Duncan, > > I don't understand your concerns. > > First, the choice between sub-modules and mono-repo has been put > forward as the only two choices because people felt that, if we let it > open, we'd have too many different implementation details and we'd >

> On Oct 13, 2016, at 2:54 PM, Renato Golin <renato.golin at linaro.org> wrote: > > On 13 October 2016 at 22:25, Mehdi Amini <mehdi.amini at apple.com> wrote: >> I’m not sure what you’re referring to here. In case I wasn’t clear before, >> I’m not interested in any way “to do a third” proposal. > > Ok, so we only mention two. No we mention what’s in the

Renato, Let me be clear about my motivation on this particular question: I don’t like this variant, and I don’t want us to extra time discussing it at the BoF because we have enough things to go through. But that is only my personal opinion, and I avoid driving solely on my personal opinion, which is why this variant is present in the document. I believe data and facts are and the only way is to