<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 31, 2016, at 1:42 PM, Matthias Braun <<a href="mailto:mbraun@apple.com" class="">mbraun@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On May 31, 2016, at 1:31 PM, Joerg Sonnenberger via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""><br class="">On Tue, May 31, 2016 at 04:24:08PM -0400, Aaron Ballman via cfe-dev wrote:<br class=""><blockquote type="cite" class="">On Tue, May 31, 2016 at 3:31 PM, Renato Golin via cfe-dev<br class=""><<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""><blockquote type="cite" class="">Folks,<br class=""><br class="">There has been some discussion on IRC about SVN hosting and the perils<br class="">of doing it ourselves. The consensus on the current discussion was<br class="">that moving to a Git-only solution would have some disvantages, but<br class="">many advantages. Furthermore, not hosting our own repos would save us<br class="">a lot of headaches, admin costs and timed out connections.<br class=""></blockquote><br class="">Not everyone thinks git is a step forward. Please do not force people<br class="">to use a "git-only" solution.<br class=""></blockquote><br class="">Amen.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">2. Due to SVN, we have a mandatory time sequence, so commits go first<br class="">in LLVM, then Clang (for example), and buildbots don't get lost. If we<br class="">use submodules [1], we can have a similar relationship, but in a more<br class="">explicit way, and the problem could be solved elegantly.<br class=""></blockquote><br class="">I actually consider the monotonically increasing revisions to be a<br class="">feature, but not sufficient to warrant a decision one way or the<br class="">other.<br class=""></blockquote><br class="">Has the situation with git-submodules and bisect improved at all or is<br class="">bisecting clang+llvm going to be manual mess?<br class=""></blockquote><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I found bisecting with submodules (in another project) far superior to the manual mess I have to do in clang+llvm today.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div>To be more exact here: I usually do not checkout llvm svn at a higher level 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). So while I have a consistent state in svn I spend the time manually calculating the next commit to checkout. So what I do instead is using git for bisecting and having some (brittle) scripts that sync multiple git repositories to use a commit from the same time!</div><div><br class=""></div><div>- Matthias</div><div><br class=""></div></div></body></html>