search for: r12345

...vm and clang (and the others projects) would be simple decoupled, individual git repositories. You would be able to check them out however you want and commit to them individually. There would be an extra "integration repository" on top that would only provide the service that tells "r12345 is llvm:36c941c clang:eaf492b compiler-rt:6d77ea5". This repository should be managed transparently by some server-side integration. The provided scripting I was referring to would just be a convenience that is using this extra layer of metadata ("integration repository") to be able...

...d clang (and the others projects) would be simple decoupled, individual git repositories. You would be able to check them out however you want and commit to them individually. > There would be an extra "integration repository" on top that would only provide the service that tells "r12345 is llvm:36c941c clang:eaf492b compiler-rt:6d77ea5". This repository should be managed transparently by some server-side integration. This actually sounds like a really good idea even if a full move to git gets blocked for some reason. It seems like it could be a fairly common requirement: I d...

On 31 May 2016 at 21:28, Mehdi Amini <mehdi.amini at apple.com> wrote: > Ideally, I'd prefer the cross-repository to be handled with an extra layer, in a way similar as described in: https://gerrit-review.googlesource.com/Documentation/user-submodules.htm (somehow conceptually similar to Android manifests XML files). > It would be easy to have tooling/scripts for llvm that would

...n sync). I can imagine some >> tooling for that, but with a github hosting it may still be fragile. > > What exactly is the concrete benefit of monotonically increasing > revision numbers? It's completely foreign to git's architecture. I'm notified that bug is fixed in r12345, my binary says "clang -v" is r23456, if I observe the bug I know there is a problem immediately. Another use case is that it provides a cross-repository reference. I'm sure that if you lookup the previous discussion about moving to git (two years ago, and four years ago I believe),...

...> API. > I’d like use a `const char *getLLVMVersion()` API that would be documented > as returning an opaque string representing the LLVM version. > The reason to return an opaque string is to prevent (not encourage…) users > to parse it. It could return something like “LLVM 4.0.0svn(r12345)”. > Using this as part of your cache key makes it more robust to switching a > given version of the compiler. > > But ultimately, if I had to build such a caching system*, I’d likely do it > upstream in LLVM and design the API to such that it would “just work” for > my shader dri...

So Mehdi, you're not in favour of providing this functionality then? Or just not in favour of that use case? On Wed, Feb 8, 2017 at 10:18 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Feb 7, 2017, at 5:44 PM, Timothy Arceri via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > On Wed, 2017-02-08 at 00:12 +0100, Nemanja Ivanovic wrote:

...s) would be simple decoupled, individual git repositories. You >> would be able to check them out however you want and commit to them >> individually. >> There would be an extra "integration repository" on top that would >> only provide the service that tells "r12345 is llvm:36c941c >> clang:eaf492b compiler-rt:6d77ea5". This repository should be managed >> transparently by some server-side integration. >> The provided scripting I was referring to would just be a convenience >> that is using this extra layer of metadata ("integ...

> On May 31, 2016, at 1:16 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> On May 31, 2016, at 12:31 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> There has been some discussion on IRC about SVN hosting and the perils >> of doing it ourselves. The consensus on the current discussion was >> that moving to a

...hine before any push. - Chris Lattner: "I think we *want* to severely limit how history is allowed to look. We don’t want the entire development history of your long-lived branch coming to mainline.” http://lists.llvm.org/pipermail/llvm-dev/2016-June/100665.html - Mehdi: "bug is fixed in r12345, my binary says "clang -v" is r23456 [or bot says it tested r23456], if I observe the bug [or the bot still fails] I know there is a problem immediately." — Mehdi > > James > On Wed, 27 Jul 2016 at 19:33, Justin Lebar <jlebar at google.com <mailto:jlebar at go...

...; - Chris Lattner: "I think we *want* to severely limit how history is > allowed to look. We don’t want the entire development history of your > long-lived branch coming to mainline.” > http://lists.llvm.org/pipermail/llvm-dev/2016-June/100665.html > - Mehdi: "bug is fixed in r12345, my binary says "clang -v" is r23456 [or > bot says it tested r23456], if I observe the bug [or the bot still fails] I > know there is a problem immediately." > > > — > Mehdi > > > > > > > James > On Wed, 27 Jul 2016 at 19:33, Justin Lebar &l...

...le decoupled, individual git >>> repositories. You would be able to check them out however you want >>> and commit to them individually. >>> There would be an extra "integration repository" on top that would >>> only provide the service that tells "r12345 is llvm:36c941c >>> clang:eaf492b compiler-rt:6d77ea5". This repository should be >>> managed transparently by some server-side integration. >> >> This actually sounds like a really good idea even if a full move to >> git gets blocked for some reason. It se...

Hi Justin, Firstly I really appreciate you taking the mantle and pushing this forward! Like Justin B I'll be bowing out after this. I thought it important because I don't believe you'll build consensus in this thread. I think the best that can be hoped for is opposition to give up fighting; advantages are to be had on both sides by different types of user and we've seen that many

Maybe we can hit the pause button on this issue of a survey vs consensus-building. I think it's a distraction from the main issue here, and it makes it harder for everyone else to participate in the thread. That said, I really do think that perspectives like Justin B's below are important. That is, if people have a problem with the monorepo, it is useful they can join the thread and say