On Wed, Jun 1, 2016 at 1:07 PM, Manuel Jacob via llvm-dev < llvm-...@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.go...@linaro.org> >>> wrote: >>> >>> On 31 May 2016 at 21:28, Mehdi Amini <mehdi.am...@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.
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
