> On Jan 16, 2015, at 3:26 AM, Erik de Castro Lopo <mle+cl at mega-nerd.com> wrote: > > As for all the reason why the LLVM project does not use Git, I wonder > why large complex projects like the Linux kernel, Wine, MinGW-w64, > GHC and many many others don't seem to have any major problems using > Git.Lots of projects are also happy with Mercurial, or BZR, or even CVS. Every open source community has its own established workflows by which developers interact with and ultimately contribute to the mainline repository. Those workflows, and the common use cases that lead to them, strongly impact what specific SCM arrangements will or will not work. To take the Linux kernel as an example, they use a very different integration strategy from LLVM that is predicated on having a significant hierarchy of developers whose major roles are to act as integrators for incoming patches. Obviously they use (and built!) an SCM tool that supports their workflow. LLVM does *not* use such a workflow. The outcome of several iterations of this discussion on this list has been that, for the LLVM community’s workflow, the advantages of moving mainline to git have not been seen as substantial versus our current arrangement, and it will lose some features that are useful. Any re-opening of this discussion needs to address the fundamental question of how switching mainline to git will actively help the LLVM community’s development process, and whether those benefits will outweigh the downsides. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150116/2d51818e/attachment.html>
Hence, "I doubt we could be bothered", since there is an unknown amount of existing infrastructure and processes that depend on the current svn implementation that would need to be migrated. Even though git could be used in the same way as svn, why migrate just to re-create the current workflow? Doesn't make too much sense to me. A migration to git would have to include some other benefit, not just be change for the sake of it. On Fri, Jan 16, 2015 at 10:10 PM, Owen Anderson <resistor at mac.com> wrote:> > On Jan 16, 2015, at 3:26 AM, Erik de Castro Lopo <mle+cl at mega-nerd.com> > wrote: > > As for all the reason why the LLVM project does not use Git, I wonder > why large complex projects like the Linux kernel, Wine, MinGW-w64, > GHC and many many others don't seem to have any major problems using > Git. > > > Lots of projects are also happy with Mercurial, or BZR, or even CVS. > > Every open source community has its own established workflows by which > developers interact with and ultimately contribute to the mainline > repository. Those workflows, and the common use cases that lead to them, > strongly impact what specific SCM arrangements will or will not work. > > To take the Linux kernel as an example, they use a very different > integration strategy from LLVM that is predicated on having a significant > hierarchy of developers whose major roles are to act as integrators for > incoming patches. Obviously they use (and built!) an SCM tool that > supports their workflow. > > LLVM does *not* use such a workflow. The outcome of several iterations of > this discussion on this list has been that, for the LLVM community’s > workflow, the advantages of moving mainline to git have not been seen as > substantial versus our current arrangement, and it will lose some features > that are useful. > > Any re-opening of this discussion needs to address the fundamental > question of how switching mainline to git will actively help the LLVM > community’s development process, and whether those benefits will outweigh > the downsides. > > —Owen > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150116/d8d0f3e8/attachment.html>
Owen, and many others … I do not wish to belabor this conversation as it distracts from everything else you all have to do. The fact that llvm does have a synchronized repository on github is sufficient for me. I can fork it, hack on it, and keep it up to date as needed. If a change I make is sufficiently useful, I’ll just submit a patch. The arguments about monotonically increasing revision number are, in my view, rather silly. That is not a very good reason for choosing or even staying with an SCM. There are stronger arguments for sticking with SVN. The arguments about having a single line of change is valid, but SVN isn’t the only tool that supports that model. I’m in support of this approach as I use it on all my projects, including those using GIT. I do understand that many automated processes are now built up around SVN and changing to git would be a huge effort with little to be gained. In putting out my inquiry, I was concerned more about LLVM being sequestered off in a corner of the Internet and not having its code as easily available as on, say, github. Code access and brows ability is one of the things that fosters innovation. However, I get that switching would be a huge pain and that LLVM is by now a mature project where perhaps innovation is taking a back seat to maintaining a standard development model that its many existing developers have grown accustomed to. So, let’s follow Owen’s suggestion and end the conversation about SCM choice and replace it with conversations about improving the development process. I for one will need to get back into that process before I can comment because it is clear that after 7 years, things just ain’t the same. :) Best, Reid.> On Jan 16, 2015, at 6:40 AM, Owen Anderson <resistor at mac.com> wrote: > > >> On Jan 16, 2015, at 3:26 AM, Erik de Castro Lopo <mle+cl at mega-nerd.com <mailto:mle+cl at mega-nerd.com>> wrote: >> >> As for all the reason why the LLVM project does not use Git, I wonder >> why large complex projects like the Linux kernel, Wine, MinGW-w64, >> GHC and many many others don't seem to have any major problems using >> Git. > > Lots of projects are also happy with Mercurial, or BZR, or even CVS. > > Every open source community has its own established workflows by which developers interact with and ultimately contribute to the mainline repository. Those workflows, and the common use cases that lead to them, strongly impact what specific SCM arrangements will or will not work. > > To take the Linux kernel as an example, they use a very different integration strategy from LLVM that is predicated on having a significant hierarchy of developers whose major roles are to act as integrators for incoming patches. Obviously they use (and built!) an SCM tool that supports their workflow. > > LLVM does *not* use such a workflow. The outcome of several iterations of this discussion on this list has been that, for the LLVM community’s workflow, the advantages of moving mainline to git have not been seen as substantial versus our current arrangement, and it will lose some features that are useful. > > Any re-opening of this discussion needs to address the fundamental question of how switching mainline to git will actively help the LLVM community’s development process, and whether those benefits will outweigh the downsides. > > —Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150116/383d077a/attachment.html>
On Fri, Jan 16, 2015 at 5:38 AM, Reid Spencer <reid at reactific.com> wrote:> Owen, and many others … > > I do not wish to belabor this conversation as it distracts from everything > else you all have to do. > > The fact that llvm does have a synchronized repository on github is > sufficient for me. I can fork it, hack on it, and keep it up to date as > needed. If a change I make is sufficiently useful, I’ll just submit a > patch. > > The arguments about monotonically increasing revision number are, in my > view, rather silly. That is not a very good reason for choosing or even > staying with an SCM. There are stronger arguments for sticking with SVN. > > The arguments about having a single line of change is valid, but SVN isn’t > the only tool that supports that model. I’m in support of this approach as > I use it on all my projects, including those using GIT. > > I do understand that many automated processes are now built up around SVN > and changing to git would be a huge effort with little to be gained. > > In putting out my inquiry, I was concerned more about LLVM being > sequestered off in a corner of the Internet and not having its code as > easily available as on, say, github. Code access and brows ability is one > of the things that fosters innovation. However, I get that switching would > be a huge pain and that LLVM is by now a mature project where perhaps > innovation is taking a back seat to maintaining a standard development > model that its many existing developers have grown accustomed to. > > So, let’s follow Owen’s suggestion and end the conversation about SCM > choice and replace it with conversations about improving the development > process. I for one will need to get back into that process before I can > comment because it is clear that after 7 years, things just ain’t the same. > :) >There is definitely quite a bit of stuff that is recognized as being pretty crusty and in need of revitalization (and for all I know, you might find familiar even with 7 years of absence). Bugpoint, TableGen, the llvm.org website, bugzilla, etc. -- Sean Silva> > Best, > > Reid. > > On Jan 16, 2015, at 6:40 AM, Owen Anderson <resistor at mac.com> wrote: > > > On Jan 16, 2015, at 3:26 AM, Erik de Castro Lopo <mle+cl at mega-nerd.com> > wrote: > > As for all the reason why the LLVM project does not use Git, I wonder > why large complex projects like the Linux kernel, Wine, MinGW-w64, > GHC and many many others don't seem to have any major problems using > Git. > > > Lots of projects are also happy with Mercurial, or BZR, or even CVS. > > Every open source community has its own established workflows by which > developers interact with and ultimately contribute to the mainline > repository. Those workflows, and the common use cases that lead to them, > strongly impact what specific SCM arrangements will or will not work. > > To take the Linux kernel as an example, they use a very different > integration strategy from LLVM that is predicated on having a significant > hierarchy of developers whose major roles are to act as integrators for > incoming patches. Obviously they use (and built!) an SCM tool that > supports their workflow. > > LLVM does *not* use such a workflow. The outcome of several iterations of > this discussion on this list has been that, for the LLVM community’s > workflow, the advantages of moving mainline to git have not been seen as > substantial versus our current arrangement, and it will lose some features > that are useful. > > Any re-opening of this discussion needs to address the fundamental > question of how switching mainline to git will actively help the LLVM > community’s development process, and whether those benefits will outweigh > the downsides. > > —Owen > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150116/74cde87f/attachment.html>
> Even though git could be used in the same way as svn, why migrate just to > re-create the current workflow? Doesn't make too much sense to me. A > migration to git would have to include some other benefit, not just be > change for the sake of it.I think our routine workflow suffers quite a bit from the svn emphasis. Sending text patches is all very well from a portability point, but it makes applying someone else's commits rather annoying (particularly for commit, but even for testing): 1. Download the patch. 2. Remember where you put it (~/Downloads, ~, ~/Documents -- depends on exactly what program downloaded it) and what the name of the file was. 3. Either look or randomly guess what -pN you need to apply it. 4. Check things. 5. Open the blasted file again to recover the commit message (frequently weirdly indented because that's what "git show" produces). Or make one up. 6. Commit with that via copy/paste. 7. Hope you didn't forget to "git/svn add" the new test before committing. This is all you can do in svn (as far as I'm aware), but it's something git has solutions for. Some unified "git fetch" available for this would be very useful for example, even if we do decide a world without monotonic numbers is too scary for us. Tim.