search for: subrepo

...], } } We would like to be able to share the entire mercurial repository with developers and others in the company, but the contents of all but the default/generic database.yml need to be tightly controlled. We had sort of solved this problem with a custom fileserver mount point and a subrepo in our mercurial repo, but this only worked when referring to content as puppet://hostname/custommountpoint. As soon as we switched to omitting the hostname ("puppet:///") we can''t get the references to the subrepo to work since it wasn''t actually modules. In a perfect...

...ck to svn (which last time I used it did >> not have built-in support for bisection, not sure if that changed >> recently). > > svn-bisect is a trival tool and should be part of every good svn > installation. While I never got around to script the part of "update all > subrepos to the same revision", it certainly doesn't involve any > addition checks. From what I can tell, git submodules don't even support > that easily. I might be wrong though. In a nutshell: git-submodules basically records a git revision of your submodules with the commits. You can...

...el because that forces me back to svn (which last time I used it did > not have built-in support for bisection, not sure if that changed > recently). svn-bisect is a trival tool and should be part of every good svn installation. While I never got around to script the part of "update all subrepos to the same revision", it certainly doesn't involve any addition checks. From what I can tell, git submodules don't even support that easily. I might be wrong though. Joerg

...sed it did > >> not have built-in support for bisection, not sure if that changed > >> recently). > > > > svn-bisect is a trival tool and should be part of every good svn > > installation. While I never got around to script the part of "update all > > subrepos to the same revision", it certainly doesn't involve any > > addition checks. From what I can tell, git submodules don't even support > > that easily. I might be wrong though. > > In a nutshell: > git-submodules basically records a git revision of your submodules...

> On May 31, 2016, at 1:42 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote: >>> On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev >>>

Purpose : fail iso build on encountering error in arbitrary code '$CODE' 1. export 'WDIR' , for 'CODE' to pick-up location to create 'fail' file to indicate failure, note that it may not always be possible to return some error code on failure in 'CODE' 2. 'set' commands enclosing 'CODE' will not be required 3. 'CODE' is

...t command in each, and I think this is the main point of confusion. (In fact you wouldn't need to write such a script; it's just "git submodule foreach".) The submodules commands creates a single branch in the umbrella repo that encompasses the checked-out state of *all the LLVM subrepos*. So you can, at a later time, check out this branch in the umbrella repo and all the clang, llvm, etc. bits will be identical to the last time you were on the branch. If all you want is to continue using git the way you use it now, the multiple git repos gets you that (as does a sparse checkout...

...the main point of confusion. (In fact you wouldn't need to > > write such a script; it's just "git submodule foreach".) > > > > The submodules commands creates a single branch in the umbrella repo > > that encompasses the checked-out state of *all the LLVM subrepos*. So > > you can, at a later time, check out this branch in the umbrella repo > > and all the clang, llvm, etc. bits will be identical to the last time > > you were on the branch. > > > > If all you want is to continue using git the way you use it now, the > >...

...FAIK, GitHub doesn't support hooks at that level, so we'd either have > to host it somewhere else or use some more convoluted solution, no? Since it is a deterministic process (even if the update does not happen for an hour, it can be replayed) in this direction (monorepo -> multiple subrepo contrary to multiple repo -> monorepo) it can be done asynchronously (i.e. using a cron or a web hook). — Mehdi

> On Jul 26, 2016, at 9:46 AM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 26 July 2016 at 09:36, Mehdi Amini via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It is possible to continue adding the equivalent of git-svn-id in the commit message if it is what you’re referring to. > > Wouldn't that rely on people installing the correct

...he problem, and I don’t really think that the benefit (not needing to write some tooling) justifies the increased burden applied to contributors that don’t use the full LLVM family of projects. I think the trade-off you're considering here (cost to developers who use llvm plus a version-locked subrepo vs. cost to developers who don't want an llvm clone) is the right one. But as someone who has extensively used git submodules and repo (a wrapper script), I strongly disagree with the judgement that a monorepo would not be a significant improvement. Our primary disagreement, I think, is over...

...I don’t really think that the benefit (not needing to write some tooling) justifies the increased burden applied to contributors that don’t use the full LLVM family of projects. > > I think the trade-off you're considering here (cost to developers who > use llvm plus a version-locked subrepo vs. cost to developers who > don't want an llvm clone) is the right one. I actually think there are *a lot* more considerations we need to be making for an infrastructure change like this. While it is true that our SCM hosting strategy primarily impacts developers, it also impacts our use...

From: Jan Synacek <jan.synacek@redhat.com> --- daemon/listfs.ml | 19 ++++++++++++++++--- daemon/luks.c | 9 +++++---- generator/actions_core.ml | 3 ++- gobject/Makefile.inc | 2 ++ inspector/inspector.c | 2 +- sparsify/in_place.ml | 2 +- 6 files changed, 27 insertions(+), 10 deletions(-) diff --git a/daemon/listfs.ml b/daemon/listfs.ml index

...nk that > the benefit (not needing to write some tooling) justifies the increased > burden applied to contributors that don’t use the full LLVM family of > projects. > > > I think the trade-off you're considering here (cost to developers who > use llvm plus a version-locked subrepo vs. cost to developers who > don't want an llvm clone) is the right one. > > > I actually think there are *a lot* more considerations we need to be making > for an infrastructure change like this. While it is true that our SCM > hosting strategy primarily impacts developers, i...

I’m just now catching up on this massive thread after being on vacation last week, and I have a few thoughts I’d like to share. First and foremost please don’t consider lack of dissent on the thread as presence of consensus. The various git-related threads on LLVM-dev lately have been so active and contentious that I think a lot of people are zoning out on the conversations. As supporting

...e tooling) justifies the increased >>> burden applied to contributors that don’t use the full LLVM family of >>> projects. >>> >>> >>> I think the trade-off you're considering here (cost to developers who >>> use llvm plus a version-locked subrepo vs. cost to developers who >>> don't want an llvm clone) is the right one. >>> >>> >>> I actually think there are *a lot* more considerations we need to be making >>> for an infrastructure change like this. While it is true that our SCM >>&gt...

...ally think that the benefit (not needing to write some tooling) justifies the increased burden applied to contributors that don’t use the full LLVM family of projects. >> >> I think the trade-off you're considering here (cost to developers who >> use llvm plus a version-locked subrepo vs. cost to developers who >> don't want an llvm clone) is the right one. > > I actually think there are *a lot* more considerations we need to be making for an infrastructure change like this. While it is true that our SCM hosting strategy primarily impacts developers, it also impa...

...in Lebar via llvm-dev <llvm-dev at lists.llvm.org> writes: > > I would like to (re-)open a discussion on the following specific > question: > > > > Assuming we are moving the llvm project to git, should we > > a) use multiple git repositories, linked together as subrepositories > > of an umbrella repo, or > > b) use a single git repository for most llvm subprojects. > > > > The current proposal assembled by Renato follows option (a), but I > > think option (b) will be significantly simpler and more effective. > > Moreover, I t...

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