llvm dev - Jun 2016 - GitHub anyone?

On Wed, Jun 1, 2016 at 1:07 PM, Manuel Jacob via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 2016-05-31 22:45, Mehdi Amini via llvm-dev wrote:
>
>> On May 31, 2016, at 1:31 PM, Renato Golin <renato.golin at
linaro.org>
>>> wrote:
>>>
>>> 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
easily say
>>>> "checkout llvm+clang+compiler-rt+libcxx+clang-extra
here", or "update all
>>>> llvm subproject under this root", or "checkout this
specific revision for
>>>> all these" (with a monotonic number for the revision).
>>>>
>>>
>>> At Linaro, we already have a set of scripts that do that. We're
now
>>> moving to git worktree, and I think it's going to simplify our
work
>>> considerably. But honestly, I'd rather not force anyone to use
any set
>>> of scripts, and let people work directly with git, so I'd be
more in
>>> favour of having a server-side solution, if at all possible.
>>>
>>
>> Apparently I wasn't very clear: llvm 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 checkout the other individual repositories together at the
>> right "rev-lock" revision.
>> This is not on your way if you don't want to use it, but it
provides
>> this "single increase monotonic revision number across multiple
>> repository" that is convenient for some people.
>>
>> Makes sense?
>>
>
> How would you ensure that two dependent changes on different repositories
> get the same revision number?

That is not the case today and isn't (in my opinion) a problem we need to
solve with this migration. If there's a small (1-2 revision) window in
which things are broken, that's annoying but not a showstopper and not a
regression.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160601/4e3178d4/attachment.html>

Richard Smith via llvm-dev <llvm-dev at lists.llvm.org> writes:
>     How would you ensure that two dependent changes on different
>     repositories get the same revision number?
>
> That is not the case today and isn't (in my opinion) a problem we need
> to solve with this migration. If there's a small (1-2 revision) window
> in which things are broken, that's annoying but not a showstopper and
> not a regression.
With git-subtree you could commit both changes atomically in the
"host"
repository, then split out the histories to the individual components.

                             -David

We could also think about using gerrit in the future to manage code reviews
and commits into the repository. (perhaps via the gerrithub.io hosted
platform, which also has github integration, including the ability to deal
with pull requests).

Gerrit already has pretty good support for cross-repository changes (via
assigning a bunch of commits to the same "topic", so they can be
reviewed
together).

It also already supports making the submodule commits for the
"llvm-project" superproject. And it is supposed to "soon"
support doing an
atomic commit of a "topic" across multiple repositories, which could
then
show up as a single change in the "llvm-project" superproject
repository. I
don't believe it does that atomically right now, but that's in the
plans.

I have found gerrit a really nice code review system in the past for other
projects, and I'm a little afraid that github's PR system will not be
featureful enough by itself. But, maybe it will.

On Thu, Jun 2, 2016 at 2:06 PM, via cfe-dev <cfe-dev at lists.llvm.org>
wrote:
> Richard Smith via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> >     How would you ensure that two dependent changes on different
> >     repositories get the same revision number?
> >
> > That is not the case today and isn't (in my opinion) a problem we
need
> > to solve with this migration. If there's a small (1-2 revision)
window
> > in which things are broken, that's annoying but not a showstopper
and
> > not a regression.
>
> With git-subtree you could commit both changes atomically in the
"host"
> repository, then split out the histories to the individual components.
>
>                              -David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/61ef12c8/attachment-0001.html>