Bill Wendling <wendling at apple.com> writes:>> Let's face it, Joe Dragon is pretty much happy with svn and there's an >> svn-git bridge for the rest of us.The svn-git bridge is broken as several people stated before. It is easier to contribute code via the gateway but it causes headaches when one updates one's working git clone after submitting through dcommit. The git pull generates all kinds of false conflicts. This is because svn doesn't understand git history and never will. git-svn will never be a replacement for git.> For me, the question is "why do we *need* to switch our versioning > system?". Nothing is broken with our current model.There are things broken with the current model, though you may not care about them. It is not possible to conveniently keep a private copy of LLVM and associated projects and sync regularly with upstream. It flat out sucks. This is because the svn model is fundamentally opposed to the idea of private repositories. There's One True Repository and that's it. In other words, svn is not a distributed SCM. It has long struck me as odd that a project whose license encourages private copies would stick with an SCM that has no support for keeping such copies. You may not care, but don't claim the current model is not broken.> The things I've heard against SVN appear to be relatively minor > inconveniences.I assure you, they are not.> And we do have a git repo for those who wish to use the newest, most > fangled thing. :-)No, we don't. We have a git-svn mirror which is crippled compared to native git. -Dave
On Sep 8, 2011, at 5:09 PM, David A. Greene wrote:> Bill Wendling <wendling at apple.com> writes: > >>> Let's face it, Joe Dragon is pretty much happy with svn and there's an >>> svn-git bridge for the rest of us. > > The svn-git bridge is broken as several people stated before. It is > easier to contribute code via the gateway but it causes headaches when > one updates one's working git clone after submitting through dcommit. > The git pull generates all kinds of false conflicts. This is because > svn doesn't understand git history and never will. > > git-svn will never be a replacement for git. > >> For me, the question is "why do we *need* to switch our versioning >> system?". Nothing is broken with our current model. > > There are things broken with the current model, though you may not care > about them. It is not possible to conveniently keep a private copy of > LLVM and associated projects and sync regularly with upstream. It flat > out sucks. This is because the svn model is fundamentally opposed to > the idea of private repositories. There's One True Repository and > that's it. > > In other words, svn is not a distributed SCM. It has long struck me as > odd that a project whose license encourages private copies would stick > with an SCM that has no support for keeping such copies. >It's my understanding that the upcoming new version of SVN will have off-line commits available. And syncing will always be a problem if your tree has greatly diverged from the main trunk. No code management system will alleviate that.> You may not care, but don't claim the current model is not broken. >If you think git will help you with this, you use the git mirror (or create your own) and sync SVN to it. :-)>> The things I've heard against SVN appear to be relatively minor >> inconveniences. > > I assure you, they are not. >Just for the record, I've been using SVN for LLVM development for many years now. I've used it for our own, rather complex, internal use -- branching, patching, tagging. And while it may not be perfect, it's certainly not broken.>> And we do have a git repo for those who wish to use the newest, most >> fangled thing. :-) > > No, we don't. We have a git-svn mirror which is crippled compared to > native git. >So basically you want to use git and it doesn't play nicely with svn, and you're blaming svn. -bw
On Sep 8, 2011, at 5:09 PM, David A. Greene wrote:>> For me, the question is "why do we *need* to switch our versioning >> system?". Nothing is broken with our current model. > > There are things broken with the current model, though you may not care > about them. It is not possible to conveniently keep a private copy of > LLVM and associated projects and sync regularly with upstream. It flat > out sucks. This is because the svn model is fundamentally opposed to > the idea of private repositories. There's One True Repository and > that's it.David, You need to separate "what is good for David" from "what is good for the project". Encouraging decentralized development and long-lived branches is not actually in the best interest of the project. I agree that there are some (quite minor IMO, like offline commits) advantages that git can provide over SVN for the preferred llvm development workflow. However, there are also large costs to switch (both in terms of effort, but also in terms of forcing lots of people to learn new things) and the result is going to be *worst* in as many places as it is better. I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project. -Chris
Chris Lattner <clattner at apple.com> writes:> You need to separate "what is good for David" from "what is good for > the project". Encouraging decentralized development and long-lived > branches is not actually in the best interest of the project. > > I agree that there are some (quite minor IMO, like offline commits) > advantages that git can provide over SVN for the preferred llvm > development workflow.You need to separate "what is good for Chris" from "what is good for the project" :-) Offline commits are useful for Chris when he is on a place without internet access. But offline commits are a godsend for people who still have no commit rights or for developers who are conducting a series of "what if" experiments. But whatever. Evaluating one feature at a time from our personal experiences or prejudices is wrong, wrong, wrong. What matters is the big picture and how it fits the whole project, taking into account current and potential contributors. The transition from svn to git is a *social* evolution, not merely a technical one like the migration from cvs to svn was. The convenience of committing while you are in a plane is insignificant compared with the impact such social change can have on the project.> However, there are also large costs to switch (both in terms of > effort, but also in terms of forcing lots of people to learn new > things) and the result is going to be *worst* in as many places as it > is better.How do you know this? How much experience do you have with this kind of transitions? (No, cvs -> svn doesn't count, see above)> I don't see the conversion to Git actually happening until someone can > clearly demonstrate a win for the open source project.A really interesting path is one that starts by explicitly stating the fundamentals of LLVM project development. Things like release-level code quality at all times combined with fast and smooth development, etc. Let's put aside the policies you implemented for achieving the fundamental goals, which are conditioned by the tools you had at the time you stated them. If you wish, bring those policies up for critical review compared with the possibilities provided by the new tool, but at a later point on the discussion.
Bill Wendling <wendling at apple.com> writes:>> In other words, svn is not a distributed SCM. It has long struck me as >> odd that a project whose license encourages private copies would stick >> with an SCM that has no support for keeping such copies. >> > It's my understanding that the upcoming new version of SVN will have > off-line commits available.Frankly, that's the least important feature git has.> And syncing will always be a problem if your tree has greatly diverged > from the main trunk. No code management system will alleviate that.Not true. SCM support means you get to use all sorts of nice merge tools to handle the sync. Applying patches sucks.>> You may not care, but don't claim the current model is not broken. >> > If you think git will help you with this, you use the git mirror (or > create your own) and sync SVN to it. :-)As several people have stated before, this is only a partial solution. It leads to lots of false conflicts that must be resolved.>>> The things I've heard against SVN appear to be relatively minor >>> inconveniences. >> >> I assure you, they are not. >> > Just for the record, I've been using SVN for LLVM development for many > years now.Haven't we all?> I've used it for our own, rather complex, internal use -- branching, > patching, tagging. And while it may not be perfect, it's certainly not > broken.You must have a much higher pain threshold than I do. :)>> No, we don't. We have a git-svn mirror which is crippled compared to >> native git. > > So basically you want to use git and it doesn't play nicely with svn, > and you're blaming svn.No, I'm pointing out that svn doesn't support everything that some people in the LLVM development community need to be able to do. -Dave
Chris Lattner <clattner at apple.com> writes:> On Sep 8, 2011, at 5:09 PM, David A. Greene wrote: >>> For me, the question is "why do we *need* to switch our versioning >>> system?". Nothing is broken with our current model. >> >> There are things broken with the current model, though you may not care >> about them. It is not possible to conveniently keep a private copy of >> LLVM and associated projects and sync regularly with upstream. It flat >> out sucks. This is because the svn model is fundamentally opposed to >> the idea of private repositories. There's One True Repository and >> that's it. > > You need to separate "what is good for David" from "what is good for > the project".I am simply attempting to explain where svn falls down. As you have made clear before, you don't care about those areas. That's fine. But it doesn't mean those concerns/needs go away. It's certainly been more than just me arguing for a switch.> Encouraging decentralized development and long-lived branches is not > actually in the best interest of the project.Who said anything about long-lived branches? Nothing about git necessitates that. And open source development is by nature decentrailized, so I'm not sure what you're getting at.> I agree that there are some (quite minor IMO, like offline commits) > advantages that git can provide over SVN for the preferred llvm > development workflow.I have outlined repeatedly advantages that come with git beyond simple things like offline commits. To me, the biggest advantage for LLVM is the direct tool support it has for the LLVM review process. I don't know why that keeps getting dismissed as unimportant.> However, there are also large costs to switch (both in terms of > effort, but also in terms of forcing lots of people to learn new > things) and the result is going to be *worst* in as many places as it > is better.Yes, there is cost. There is a cost with staying with svn as well. And I do not think we can assert that the result of a switch will necessarily be worse in the same/more places as it is better. That is pure speculation.> I don't see the conversion to Git actually happening until someone can > clearly demonstrate a win for the open source project.Well, I give up then. I've written a couple of documents trying to demonstrate just that. Apparently I have been unsuccessful. -Dave
On 09/09/2011 01:47 AM, Chris Lattner wrote:> On Sep 8, 2011, at 5:09 PM, David A. Greene wrote: >>> For me, the question is "why do we *need* to switch our versioning >>> system?". Nothing is broken with our current model. >> >> There are things broken with the current model, though you may not care >> about them. It is not possible to conveniently keep a private copy of >> LLVM and associated projects and sync regularly with upstream. It flat >> out sucks. This is because the svn model is fundamentally opposed to >> the idea of private repositories. There's One True Repository and >> that's it. > > David,Hi Chris,> You need to separate "what is good for David" from "what is good for the project". Encouraging decentralized development and long-lived branches is not actually in the best interest of the project.I (and probably most of us) agree that we do not want long-lived feature branches to be integrated into LLVM. The small, incremental patches policy works well. It is obvious that long lived feature branches highly complicate reviews and will significantly slow down patch review. Yet, this is a policy which we can and should enforce during normal patch review. The same as we nowadays successfully enforce small, incremental patches and discourage big, difficult to review patches. There is no need to enforce such a policy through the use of svn.> I agree that there are some (quite minor IMO, like offline commits) advantages that git can provide over SVN for the preferred llvm development workflow. However, there are also large costs to switch (both in terms of effort, but also in terms of forcing lots of people to learn new things) and the result is going to be *worst* in as many places as it is better. > I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project.I understand it is most probably difficult to see the benefits, that for many of us are so obvious. Having used git for a while, I never want to miss the increased productivity. Points I believe are important: - Git reduces the chance of diverting feature branches When opening a branch with svn, it often happens that the branch and trunk divert significantly, because merging with svn involves significant effort. git on the other hand simplifies merges a lot, such that merges happen very often. As a result, a branch rarely diverges significantly from trunk. - Git simplifies cherry-picking and small patches As git simplifies cherry-picking and encourages the use of small patches, it allows to submit patches early and often. Even if you have not finished a feature patch yet, you can easily chop-off unrelated, supporting patches and submit them straight ahead. As a result, the nowadays often used two step approach with svn, that consists of first developing a set of patches and subsequently submitting them can often be turned into a model that allows to keep unfinished patches privately, but at the same time to submit finished patches at the time they are coded. There are a lot more benefits of the use of git. Mentioning all is out of scope here. Cheers Tobi
On Sep 8, 2011, at 7:47 PM, Chris Lattner wrote:> I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project.I would think that using git would allow LLVM to setup a system whereby commits are pushed to a special buildbot repository instead of the main repository. If a commit fails to pass the test suite then it would be rejected and never committed to the main repository, preventing it from causing issues with other developers. If a commit passes then the buildbots could automagically push the changes into the main repository. I'm not exactly sure how this would work, but I think it would be possible. -- Wesley Peck University of Kansas SLDG Laboratory
On 9/8/2011 7:47 PM, Chris Lattner wrote:> I don't see the conversion to Git actually happening until someone can > clearly demonstrate a win for the open source project.In my experience with Mozilla (which uses mercurial, not git, but the principles are the same), moving to a DVCS has really changed the flow of development. Over the past year or so, most of the development has moved off of the trunk and into a large suite of project repositories: the JS engine, build system, and others maintain their own repository and merge them with the trunk around once a week. This makes it easier to discover when checkins cause failures, and, more importantly, it means that the main trunk has moved to a state where you no longer need to check first that it actually builds before updating your local copy. A think a lot of the arguments that people purport for git workflow is actually the workflow that is used on GitHub, which is certainly not necessary for a project. Mozilla still revolves a lot around upload-and-download patches (mostly for review processes); we have also taken advantage of the extensibility of modern DVCS's to be able to integrate the "grab the patch on bug XYZ and apply it for review testing." I would also point out the mercurial queues feature is probably in part responsible for breaking down patches from large "fix everything at once" to a series of much smaller partial and more atomic rewrites, with all of the review and bisecting advantages it brings. Using the repository to manage patches locals eases the cost of keeping them up-to-date, since instead of getting patch rejections, you can use $MERGE_PROGRAM to do a more interactive 3-way-merge. Another advantage is the ability to bisect changes. The modern DVCS provides good tools for automatic bisection to help pinpoint regressions, something which is invariably going to occur in any large, nontrivial project. -- Joshua Cranmer News submodule owner DXR coauthor
On Thu, Sep 8, 2011 at 5:09 PM, David A. Greene <dag at cray.com> wrote:> Bill Wendling <wendling at apple.com> writes: > > >> Let's face it, Joe Dragon is pretty much happy with svn and there's an > >> svn-git bridge for the rest of us. > > The svn-git bridge is broken as several people stated before. It is > easier to contribute code via the gateway but it causes headaches when > one updates one's working git clone after submitting through dcommit. > The git pull generates all kinds of false conflicts. This is because > svn doesn't understand git history and never will. > > git-svn will never be a replacement for git. > > > For me, the question is "why do we *need* to switch our versioning > > system?". Nothing is broken with our current model. > > There are things broken with the current model, though you may not care > about them. It is not possible to conveniently keep a private copy of > LLVM and associated projects and sync regularly with upstream. It flat > out sucks. This is because the svn model is fundamentally opposed to > the idea of private repositories. There's One True Repository and > that's it. > >Err, there are other ways around these issues - At least from mercurial side, the svn bridge is probably similarly busted, but I avoid those issues by using MQ to maintain a set of patches - once the patches are applied, and "finished", the patches go away, but since they are VC ed, you can always timetravel back to prior "versions" of the patches and do all the dvcs things w/o too much hassles - and WITHOUT any false conflicts when doing a fresh pull. I've kept multiple, parallel sets of "local commits" on top of the hg-subversion bridge, jumping back and forth between "branches of patch sets", all the while rebasing to tip of tree, one patch branchset at a time. I believe git has a similar system for maintaining "branches of patches" Seriously folks, there are solutions to these problems - we don't have to burn down the world for the sake of dvcs "purity" my 2c, obviously. -jason> In other words, svn is not a distributed SCM. It has long struck me as > odd that a project whose license encourages private copies would stick > with an SCM that has no support for keeping such copies. > > You may not care, but don't claim the current model is not broken. > >> > The things I've heard against SVN appear to be relatively minor > > inconveniences. > > I assure you, they are not. > > > And we do have a git repo for those who wish to use the newest, most > > fangled thing. :-) > > No, we don't. We have a git-svn mirror which is crippled compared to > native git. > > -Dave > _______________________________________________ > 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/20110909/f8be0999/attachment.html>