[cfe-dev] [llvm-dev] GitHub anyone?

[Richard Smith via cfe-dev]

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/cfe-dev/attachments/20160601/4e3178d4/attachment.html>