search for: subrepos

We keep our puppet configuration in a revision control system and are trying to facilitate developers using the same modules as production/ staging servers. We define a variable ($servergroup) as test/staging/production and use fileserver defaults from hostname to servergroup to generic. The hostname and $servergroup versions need to be confidential. We have modules specific to an application,

...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 w...

> 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 > > m...

> On Jul 26, 2016, at 10:32 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 26 July 2016 at 17:59, Mehdi Amini <mehdi.amini at apple.com> wrote: >> When exporting a commit from the monorepo to one of the read-only >> repository, it should be possible to generate a “git-svn-id”-like the same >> way we’re doing when exporting from SVN today. >

> 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

Thanks for your thoughts, Chris. > As supporting evidence of this, I was discussing this thread yesterday around the office yesterday and had quite a few people responding something along the lines of “they’re proposing what?”. I hope they'll join us in this thread. Ultimately a survey is going to be strongly biased in favor of "don't change anything". There is a strong

> On Jul 27, 2016, at 10:21 AM, Justin Lebar <jlebar at google.com> wrote: > > Thanks for your thoughts, Chris. > >> As supporting evidence of this, I was discussing this thread yesterday around the office yesterday and had quite a few people responding something along the lines of “they’re proposing what?”. > > I hope they'll join us in this thread. > >

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

> (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’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

> On Aug 9, 2016, at 1:38 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Aug 9, 2016, at 11:27 AM, Justin Lebar via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >>> (2) If I’m stuck using git-svn I kinda feel like there is no real point in changing anything. >> >>

Thanks for elaborating, Chris. > Case Study 1 - Simple development on a sub-project I explicitly addressed this workflow in my original e-mail. I know it was a while ago, but it sounds like it may be worth a read if you haven't checked it out. In the mail I described how to use sparse checkouts to create a repository structure that functions virtually identically to what you have today.

...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 th...

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