Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 30 June 2016 at 05:14, Tim Northover  wrote:
>> That makes it fragile, and that’s why I disagree with your “90% done” 
>> assessment.
>> What if the service behing the hook is down for a few days?
>
> In the long-term view, a pretty trivial catch-up script ought to be
> able to synthesize a sane history after any amount of down-time.
> People could even run it locally for their bisecting needs if it was
> that important to them.

Yup. If the script is stable (as in sort stable), anyone running it
locally will get the same results as upstream and each other.


> In the short term, I don't think it's a critical enough service to
> worry about, frankly. What we already have is hopelessly fragile:
> right now when LLVM's server plays up it takes out absolutely
> everything, in the proposed world it would take out this bisecting
> convenience feature. Seems like a strict improvement to me.

I think it's even less important than that. Bisecting will work
*better* when using submodules than it does using SVN (because git
bisect is more powerful, allows me to track all modules' history, and
will rid me of a complicated downstream set of SVN-bisect scripts).

The only thing we *have* to have a sequential number for, are
releases. Even that can be ran manually.

We agreed to have sequential numbering from the start to allow
infrastructure to migrate slowly to a Git model. That can also have an
extra step to run the script if IDs are not populated yet.


>> Who will maintain it?

Whoever maintains the current infrastructure, which is currently the
Foundation. All scripts will be upstream.

So far, they (Tanya, Anton, Galina) have been very responsible to
every downtime and problems I found. I have no doubt that this will
continue to be a trend.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Tim Northover via lldb-dev]

> That makes it fragile, and that’s why I disagree with your “90% done” 
> assessment.
> What if the service behing the hook is down for a few days?

In the long-term view, a pretty trivial catch-up script ought to be
able to synthesize a sane history after any amount of down-time.
People could even run it locally for their bisecting needs if it was
that important to them.

In the short term, I don't think it's a critical enough service to
worry about, frankly. What we already have is hopelessly fragile:
right now when LLVM's server plays up it takes out absolutely
everything, in the proposed world it would take out this bisecting
convenience feature. Seems like a strict improvement to me.

> Who will maintain it?

I'm not the best scripter and I'd be happy to cede to someone else,
but I'd be willing if it meant we could make progress.

Tim.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Sean Silva via lldb-dev]

On Wed, Jun 29, 2016 at 12:34 PM, Sean Silva  wrote:

>
>
> On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin 
> wrote:
>
>> On 29 June 2016 at 20:14, Sean Silva  wrote:
>> > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
>> > important special case we may be able to agree on. (and I say this as
>> > somebody that largely builds cross-compilers (targeting PS4))
>>
>> In that case, RT wouldn't "have" to be core. We use GCC rt-libs on GNU
>> systems, even for self-hosting.
>>
>
> I think there is a compelling argument for selfhosting with sanitizers
> (the sanitizer bootstrap bot has saved me more times than I care to admit).
>

Also libprofile for PGO selfhost.

-- Sean Silva


>
> -- Sean Silva
>
>
>>
>> Even if we move to full RT builtins (which I really want), we'd have
>> to get rid of everything else in that repo to move it to core.
>>
>> cheers,
>> --renato
>>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Sean Silva via lldb-dev]

On Wed, Jun 29, 2016 at 12:04 PM, Renato Golin 
wrote:

> On 29 June 2016 at 19:51, Sean Silva  wrote:
> > Roughly speaking, I would prefer a repo division (if any) to be along the
> > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra
> stuff
> > not strictly required".
>
> The problem comes when different people consider "core" different
> projects. :)
>

Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
important special case we may be able to agree on. (and I say this as
somebody that largely builds cross-compilers (targeting PS4))

-- Sean Silva


>
> We're always reviewing the projects and we do split them when people
> agree it's needed.
>
> Examples are the libunwind coming out of Compiler-RT, and the recent
> discussion to do the same with the sanitizers and others. This is not
> just about preference, but it's about cross dependency, and the only
> sane way we can cross-build to multiple targets.
>
> cheers,
> --renato
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 29 June 2016 at 15:11, David Chisnall  wrote:
> Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub 
> continue to work by simply switching the remote in the config?

I hope so. There isn't anything (modulo mistakes) stopping us from
having a clean migration.

We'll have to re-organise the GitHub mirrors, though, as Takumi has
mostly driven out of his own account, and it'll have to be owned by
"The LLVM Project" somehow.

Mehdi suggested us to flip the mirror (from GitHub to LLVM Git to
SVN), as soon as we mark them read-only, and then open RW only in
GitHub.

We don't want to use GitHub's "pull requests" for every patch, so
we'll have to add push rights to all committers today.

Meaning, you can just change the remote to the official GitHub repo
and get rid of Git-SVN.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Sean Silva via lldb-dev]

On Wed, Jun 29, 2016 at 9:28 AM, James Y Knight via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> On 27 June 2016 at 17:03, Rafael Espíndola 
>> wrote:
>> > I think that trying to create a ordering/rev number between independent
>> git
>> > repositories is fundamentally unreliable.
>> >
>> > If we want to keep llvm and clang in lock step we should probably
>> probably
>> > just have them in the same repository like
>> > https://github.com/llvm-project/llvm-project.
>>
>> That is similar to the proposal we have, except that llvm-projects
>> will have sub-modules.
>>
>> Having all of them in the same physical repository is a big problems
>> for those that only use a small subset of the components, which is the
>> vast majority of users, most of the time (all buildbots, Jenkins,
>> local development, downstream users, even releases don't clone all
>> repos).
>
>
> (This is kinda a sidenote, because it doesn't actually change the
> problem-space at all, but :)
>
> I really disagree that it'd cause big problems to merge them all.
> Especially when using git, which makes it a lot easier to keep a local
> shared copy of the repository, so you don't need to re-download the whole
> world every time you want a clean checkout. The entire set of llvm code,
> all put together, is really just not that big in the end. But I do find it
> annoying to have the many different repositories to track, and I don't
> really see the value of having as many as we do.
>

This is anecdotal, but using llvm-project on a ~daily basis, I can say that
the place where the larger repo is noticeable is the increased size of the
checkout; this affects the time of `git status` and many other frequently
used commands. It isn't terrible though (even on windows; at least with an
SSD; I haven't tried HDD).


>
> However, even without big problems, it does make some sense to keep the
> C/C++ language separate from the (mostly-)language-independent llvm
> backend. There are a multitude of other frontends which use LLVM too: go,
> swift, rust, etc. Would we really want to pull in all of those into a
> single repo, as well, if they happened to get contributed to the llvm
> project organization? Probably not.
>

Clang is special in that we have the expectation that developers need to
update clang if their patch to LLVM breaks it. (I assume this is largely
due to its role in self-hosting). It is unlikely that any other frontend
will ever get that special treatment since it does entail a high
maintenance burden. So I don't see a strong reason to split out clang just
because it is a "frontend".

Roughly speaking, I would prefer a repo division (if any) to be along the
lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff
not strictly required".

Just my 2c

-- Sean Silva


> So, while this wouldn't affect the need for a "llvm-project" repository,
> it might be nice to consider merging some of the other ones together
>

> E.g.:
> llvm: Core language-independent functionality: LLVM, assembler, and linker
> tools. (merge in lld, and maybe compiler-rt, to the llvm repository).
> clang: C/C++ frontend and related libraries (merge in clang-tools-extra,
> libcxx, and libcxxabi into the clang repository).
>
>
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[James Y Knight via lldb-dev]

On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 27 June 2016 at 17:03, Rafael Espíndola 
> wrote:
> > I think that trying to create a ordering/rev number between independent
> git
> > repositories is fundamentally unreliable.
> >
> > If we want to keep llvm and clang in lock step we should probably
> probably
> > just have them in the same repository like
> > https://github.com/llvm-project/llvm-project.
>
> That is similar to the proposal we have, except that llvm-projects
> will have sub-modules.
>
> Having all of them in the same physical repository is a big problems
> for those that only use a small subset of the components, which is the
> vast majority of users, most of the time (all buildbots, Jenkins,
> local development, downstream users, even releases don't clone all
> repos).


(This is kinda a sidenote, because it doesn't actually change the
problem-space at all, but :)

I really disagree that it'd cause big problems to merge them all.
Especially when using git, which makes it a lot easier to keep a local
shared copy of the repository, so you don't need to re-download the whole
world every time you want a clean checkout. The entire set of llvm code,
all put together, is really just not that big in the end. But I do find it
annoying to have the many different repositories to track, and I don't
really see the value of having as many as we do.

However, even without big problems, it does make some sense to keep the
C/C++ language separate from the (mostly-)language-independent llvm
backend. There are a multitude of other frontends which use LLVM too: go,
swift, rust, etc. Would we really want to pull in all of those into a
single repo, as well, if they happened to get contributed to the llvm
project organization? Probably not.

So, while this wouldn't affect the need for a "llvm-project" repository, it
might be nice to consider merging some of the other ones together

E.g.:
llvm: Core language-independent functionality: LLVM, assembler, and linker
tools. (merge in lld, and maybe compiler-rt, to the llvm repository).
clang: C/C++ frontend and related libraries (merge in clang-tools-extra,
libcxx, and libcxxabi into the clang repository).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 28 June 2016 at 16:46, Mehdi Amini  wrote:
> Why? Assuming we don’t have branches, there was many mention that the id can 
> be computed from the number of commits in the history.

We have branches (release_nm) and we may want them to be in the same
sequential numbering.

So, I'm assuming this hook gets executed every time a new commit
arrives, but they're sub-modules, would they also notify the parents?

If this works in a trigger mode (every commit), not a timed basis
(every 5 minutes), then it could work well.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Mehdi Amini via lldb-dev]

> On Jun 28, 2016, at 1:55 AM, NAKAMURA Takumi via llvm-dev 
>  wrote:
> 
> It has also submodules. 
> https://github.com/llvm-project/llvm-project-submodule 
> 
> 
> Both llvm-project(-tree) and (-submodule) have refs/notes/commits.

This is easy to compute when coming from SVN, the difficulty will be to keep 
this when having multiple git repo as a source.

— 
Mehid


> 
> On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev 
> > wrote:
> On 27 June 2016 at 17:03, Rafael Espíndola  > wrote:
> > I think that trying to create a ordering/rev number between independent git
> > repositories is fundamentally unreliable.
> >
> > If we want to keep llvm and clang in lock step we should probably probably
> > just have them in the same repository like
> > https://github.com/llvm-project/llvm-project 
> > .
> 
> That is similar to the proposal we have, except that llvm-projects
> will have sub-modules.
> 
> Having all of them in the same physical repository is a big problems
> for those that only use a small subset of the components, which is the
> vast majority of users, most of the time (all buildbots, Jenkins,
> local development, downstream users, even releases don't clone all
> repos).
> 
> cheers,
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 28 June 2016 at 06:55, NAKAMURA Takumi  wrote:
> It has also submodules.
> https://github.com/llvm-project/llvm-project-submodule
>
> Both llvm-project(-tree) and (-submodule) have refs/notes/commits.

Nice! Can you try a server hook that will add an auto-increment number
from submodules commits?

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[NAKAMURA Takumi via lldb-dev]

It has also submodules.
https://github.com/llvm-project/llvm-project-submodule

Both llvm-project(-tree) and (-submodule) have refs/notes/commits.

On Tue, Jun 28, 2016 at 1:13 AM Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 27 June 2016 at 17:03, Rafael Espíndola 
> wrote:
> > I think that trying to create a ordering/rev number between independent
> git
> > repositories is fundamentally unreliable.
> >
> > If we want to keep llvm and clang in lock step we should probably
> probably
> > just have them in the same repository like
> > https://github.com/llvm-project/llvm-project.
>
> That is similar to the proposal we have, except that llvm-projects
> will have sub-modules.
>
> Having all of them in the same physical repository is a big problems
> for those that only use a small subset of the components, which is the
> vast majority of users, most of the time (all buildbots, Jenkins,
> local development, downstream users, even releases don't clone all
> repos).
>
> cheers,
> --renato
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Alexey Denisov via lldb-dev]

Hello there,

Renato, thank you for putting everything together.

Talking about second question (commits mailing list): github provides set
of various web hooks. I think here we are interested
In 'push'es particularly.

Besides that it has some CI related integrations: buildbots can update pull
request status to show if tests are passing or not. The builds can be also
triggered using web hooks (issue_comment with specific text). IIRC swift
and rust do this (and more) in a very similar way.

Cheers,
Alex.

[1] https://developer.github.com/webhooks


On Sunday, 26 June 2016, Renato Golin via llvm-dev 
wrote:

> So,
>
> It's been a while and the GitHub thread is officially dead, so I'll
> propose a development methodology based on the feedback from that
> thread. This is not *my* view, but all that was discussed in the
> threads.
>
> My objective is to form an official proposal to use Git as our main
> repository, overcoming all the problems we currently have without
> creating many others. In the end, I think Tanya wanted to make a vote,
> and see how string the community feels about it. The vote should be
> "Should we move to GitHub as the proposed workflow, or should we try
> to find another solution away from our own hosting?".
>
> The important part is that we *must* move from the current schema. It
> does not scale and the administrative costs are not worth the trouble.
> So, if we don't go with GitHub, we have to find another way out.
>
> The proposal
> ==
>
> Move to GitHub with N+1 projects: all current LLVM projects + the
> "llvm-projs" umbrella. The latter will have all other projects as
> "submodules" with the intent to:
>
>  1. Control the history via server hooks updating a unique and
> auto-increment identifier, which will apply to every commit on its
> submodules (ie, every other LLVM project).
>  2. Serve as a reference for releases, buildbots, etc., checking out
> only the necessary submodules for each.
>  3. Have additional logic to handle the additional complexity for
> mailing lists, tools, buildbots to deal with the umbrella project
> *only*.
>
> The existing LLVM projects (llvm, clang, compiler-rt, etc) will
> continue on their own repositories and be built locally just like they
> are today. You can check them out individually inside the final
> directory (llvm/tools/clang) or use symbolic links, just like we do
> today. You can also checkout "llvm-projs" and update only the required
> submodules, and use symbolic links.
>
> The llvm-projs umbrella will have its own versioning, and tools can
> report that ID as their "version", if they're not in a release branch.
>
> Release branches should be off of master and have a linear history,
> just like master, in the exact same way we do now with SVN. This will
> guarantee the umbrella project will be able to correctly
> auto-increment the ID and make sure current tools work as usual.
>
> We don't want private branches to end up in upstream LLVM (only
> upstream release branches), but that's perfectly natural in GitHub,
> where anyone can fork and implement their features and own releases
> off of the upstream official repositories.
>
> This can work as well for upstream development of "feature branches",
> where upstream developers contribute to both repositories, but keeping
> a specific feature in test separate. Merges will still have to be like
> it is today, one patch at a time, or risk reverting the whole merge
> window if the buildbots start breaking, which can be impossible if the
> window is large or two or more windows get committed at the same time.
>
> For "feature branches" we could use git-imerge, but that's for the
> future and not considered in the first stage of the move.
>
> Git Submodules
> -
>
> There were concerns is submodules would work with our flow, but the
> concerns were addressed by demonstrating that:
>
>  1. Submodules can work in an umbrella project, which controls the
> auto-increment ID
>  2. You can check-out individual modules or all, so work well for
> releases and buildbots
>  3. The history is shared with the root project, so git-bisect works
> out of the box
>
> The Alternatives
> -
>
> A few alternatives were proposed, but git submodules ended up being
> considered more thoroughly. Here are some of the reasons:
>
>  * Google repo:
>
> It's an independent tool, which may suite us today, but not
> necessarily tomorrow. It may work well with the infrastructure that is
> already set for it on other projects (mostly Google projects like
> Android), but it does require some tooling (like git submodules). The
> point is, that it's much more likely to exist tooling for official git
> features than third-party projects, especially on Windows.
>
>  * All-in-one:
>
> Proposals to have all projects inside one big repo were quickly
> dismissed due to the problems it creates to *users* of LLVM as 

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Rafael Espíndola via lldb-dev]

I think that trying to create a ordering/rev number between independent git
repositories is fundamentally unreliable.

If we want to keep llvm and clang in lock step we should probably probably
just have them in the same repository like
https://github.com/llvm-project/llvm-project.

Cheers,
Rafael
On Jun 27, 2016 11:10 AM, "Renato Golin"  wrote:

> On 27 June 2016 at 15:39, Rafael Espíndola 
> wrote:
> > So, I probably missed something, but what was the main objection to
> > just using submodules? This would put llvm inside clang instead of the
> > other way around. When changing an API one currently has to
>
> I don't think the consensus was to change the order of inclusion (llvm
> into clang), but to *not* change anything else at this stage.
>
> That's one of the reasons the umbrella project with sub-modules was
> the most accepted solution, because we can later change the inclusion
> order (if we all agree, etc), without changing the underlying storage.
>
>
> > * Change llvm.
> > * Change clang and in the same atomic commit change what revision the
> > submodule points to.
>
> Having one repository inside another was rejected due to the problems
> it brings for development, validation and release. James has just
> pointed a few of those problems for development.
>
> An umbrella project with a commit hook and an auto-update would make
> sure all commits are synchronised correctly. Though, indeed, this will
> mean we'll still have the trouble of buildbots picking up one commit
> and not the other, I don't think this is a big enough problem that we
> should mess up everyone's workflow.
>
> cheers,
> --renato
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 27 June 2016 at 15:39, Rafael Espíndola  wrote:
> So, I probably missed something, but what was the main objection to
> just using submodules? This would put llvm inside clang instead of the
> other way around. When changing an API one currently has to

I don't think the consensus was to change the order of inclusion (llvm
into clang), but to *not* change anything else at this stage.

That's one of the reasons the umbrella project with sub-modules was
the most accepted solution, because we can later change the inclusion
order (if we all agree, etc), without changing the underlying storage.


> * Change llvm.
> * Change clang and in the same atomic commit change what revision the
> submodule points to.

Having one repository inside another was rejected due to the problems
it brings for development, validation and release. James has just
pointed a few of those problems for development.

An umbrella project with a commit hook and an auto-update would make
sure all commits are synchronised correctly. Though, indeed, this will
mean we'll still have the trouble of buildbots picking up one commit
and not the other, I don't think this is a big enough problem that we
should mess up everyone's workflow.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Rafael Espíndola via lldb-dev]

>> As for updating the meta repository: We could disable write access for the 
>> normal llvm developer and delegate the submodule bumping to an external
>> server. I believe this would be an easy enough job for buildbot or jenkins.
>
> The plan is to disable all write access to this repository (otherwise
> we'll create a nightmare). Having an external counter could be
> problematic due to synchronisation issues.
>
> If the hook doesn't work, we'll have serious problems.

So, I probably missed something, but what was the main objection to
just using submodules? This would put llvm inside clang instead of the
other way around. When changing an API one currently has to

* Change llvm.
* Quickly change clang and hope no bot picks up a revision with only
the llvm change.

With submodules it becomes

* Change llvm.
* Change clang and in the same atomic commit change what revision the
submodule points to.


Cheers,
Rafael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 27 June 2016 at 01:20, Matthias Braun  wrote:
> I really liked the the solution proposed earlier in this thread: Do nothing 
> server side, but instead use
> `git rev-list --count master` on the client side (which takes 0.9s on my 
> machine) to get the number of the commit. So nothing to do on the ID part IMO.

Mehdi replied to this proposal:

"it does not help to solve the cross-repository problem, we need a
"meta integration repository"."


> As for updating the meta repository: We could disable write access for the 
> normal llvm developer and delegate the submodule bumping to an external
> server. I believe this would be an easy enough job for buildbot or jenkins.

The plan is to disable all write access to this repository (otherwise
we'll create a nightmare). Having an external counter could be
problematic due to synchronisation issues.

If the hook doesn't work, we'll have serious problems.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Renato Golin via lldb-dev]

On 26 June 2016 at 23:02, Anton Korobeynikov  wrote:
> Does github allow this? IIRC their support for server-side hooks was
> very limited due to obvious reasons. And executing hooks e.g. on
> llvm.org seems very error-prone.

Someone suggested it was possible. I have sent them an email with a
draft proposal and they said everything was fine, though they didn't
confirm specific support.

I can't see shy changing a local auto-increment ID on the repository
itself would be a breach of security, so even if there are
limitations, I think we can get this done.

I'll send them another email to confirm this specific point.

cheers,
--renato
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[Anton Korobeynikov via lldb-dev]

>  1. Control the history via server hooks updating a unique and
> auto-increment identifier, which will apply to every commit on its
> submodules (ie, every other LLVM project).
Does github allow this? IIRC their support for server-side hooks was
very limited due to obvious reasons. And executing hooks e.g. on
llvm.org seems very error-prone.

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev