On Sat, Jul 23, 2011 at 01:02:10AM +0200, Óscar Fuentes wrote:> One thing that I wanted to see (and probably missed, because I didn't > read all the thread) is to discuss the workflow. I'm under the > impression that not all regular LLVM developers understand the > implications for the LLVM community of migrating from a central VCS to a > distributed one, on terms of developer workflow, group management, > etc. We should make those details explicit just to avoid surprises.You know, this is exactly the crux of this whole "move to git" thread. It is the very same problem of every other VCS migration I have seen (or dealt with). The core issue here is that you are effectively telling us that the current workflow is not supported by Git. You are also telling us that the current workflow is in some way wrong or misguided or suboptimal and has to change. Let's avoid all the religious argument about how distributed version control is somehow better than centralistic version control. What are the precise gains from changing the status quo? What can you do by moving everything to Git that you couldn't do in the current world with svn as master repository and the additional git mirror? If the argument is "I don't like svn", it is weak. Others don't like Git and would prefer Mercurial. Or Bazaar. Or maybe even Perforce or CVS. If the argument is better branching, I would like to see it clarified for how this improves the workflow. I have dealt with many open source projects and many VCS variants. I don't see a noticable improvement from using Git compared e.g. to SVN for sane usage of branches -- be it short-term feature branches, mid-term restructoring or long-term release branches. The exception may be doing wild cross branch merging and long dependency chains between branches like done in the Linux kernel -- but I don't think that's a sane development model and I certainly don't see that agreeing with the development policy of LLVM. If the argument is doing detached development, that is already possible. Approaches include the Git mirror, SVN mirroring solutions etc. Advocats of DVCS tend to ignore the cost of the move. The linear commit graph and associated properties is the biggest one. This can be dealt with as part of a defined workflow, but that is far more work than just saying "use tool XXX" and I don't see this happening yet. At least on that point, we both agree. Joerg
Joerg Sonnenberger <joerg at britannica.bec.de> writes:> You know, this is exactly the crux of this whole "move to git" thread. > It is the very same problem of every other VCS migration I have seen (or > dealt with). The core issue here is that you are effectively telling us > that the current workflow is not supported by Git.It is supported, but if you want to work svn-style, nothing better than svn itself.> You are also telling us that the current workflow is in some way wrong > or misguided or suboptimal and has to change.Suboptimal is the right word. There is nothing essentially wrong with everybody-and-his-cat pushing revisions to mainline but an user with write privileges to a git repo can make quite a bit of damage. Undoing that damage usually will cause inconveniences to everybody. Having a set of maintainers with write privileges that incorporates patches submitted to the mailing list, *maybe* is a better arrangement.> Let's avoid all the religious argument about how distributed version > control is somehow better than centralistic version control. What are > the precise gains from changing the status quo? What can you do by > moving everything to Git that you couldn't do in the current world > with svn as master repository and the additional git mirror?git-svn is quite ok for lone developers doing experiments or coding small features, but if you work on a team and/or the changes are submitted on incremental steps, you have a problem because, for instance, git-svn will not recognize the revisions you contributed to the svn's repo as the same you and you co-workers already have in your git branch. If there is a feature that sets distributed version control systems apart from the traditional ones it is their role as communication tools. I can choose *not* to communicate my work to the public (or keep it within a restricted group) without giving out the convenience of using a version control system, or publishing my work on a way that it is easy for others to access, extend and incorporate into their own developments. Both this possibilities are positive for the project, for a variety of reasons. git-svn, as explained on the previous paragraph, is a hindrance for using the communication possibilities of git.> If the argument is "I don't like svn", it is weak. Others don't like Git > and would prefer Mercurial. Or Bazaar. Or maybe even Perforce or CVS. > > If the argument is better branching,Better *merging*.> I would like to see it clarified for how this improves the workflow. I > have dealt with many open source projects and many VCS variants. I > don't see a noticable improvement from using Git compared e.g. to SVN > for sane usage of branches -- be it short-term feature branches, > mid-term restructoring or long-term release branches.Merging support in svn is brain-dead. Having a single commit "Merged branch foo rX:Y" is hardly informative. Having the actual chunk of VC history merged into the target branch is the Right Thing.> The exception > may be doing wild cross branch merging and long dependency chains > between branches like done in the Linux kernel -- but I don't think > that's a sane development model and I certainly don't see that > agreeing with the development policy of LLVM.I'm sure that, conciously or not, the development policy of LLVM was conditioned by the limitations imposed by the VC tools the project used so far: CVS and svn (which is CVS refurbished). I can't believe that anyone thinks it is a good thing to scatter the commits that implements a feature all over the VC history, instead of atomically merging them á-la-git, with a parent-child relation that shows those commits as part of a logically consistent series and giving the precise point where the feature was incorporated into mainline.> If the argument is doing detached development, that is already possible. > Approaches include the Git mirror, SVN mirroring solutions etc. > > Advocats of DVCS tend to ignore the cost of the move.I'm not ignoring it. Actually, I'm one of those who are warning against the "let's migrate the infraestructure and then all will be a path of roses" view.> The linear commit > graph and associated properties is the biggest one.However, I'm also saying that if the loss of the LG (Linear Graph) is the biggest one, then the stumbling rock for adopting git is not realizing its potential. The LG is convenient for some tasks, but it is also a limiting factor for others. You are accustomed to its conveniences and accepted its limitations (possibly without much thinking). You are not accustomed to the advantages of using a tool like git. Once the transition is *correctly* done, the loss of the LG will seem as a petty one.> This can be dealt > with as part of a defined workflow, but that is far more work than just > saying "use tool XXX" and I don't see this happening yet. At least on > that point, we both agree.Definitely, agreeing on a workflow and creating awareness about its consequences is fundamental for the success of the switch.
Joerg Sonnenberger <joerg at britannica.bec.de> writes:> The core issue here is that you are effectively telling us > that the current workflow is not supported by Git.No, it's fully supported. We can even run things exactly the same way. But we don't _have_ to do that.> You are also telling us that the current workflow is in some way wrong > or misguided or suboptimal and has to change.I don't think anyone said that. But git does open up a lot more possibilities. We don't need to explore those possibilities right away. I would say we should not until everyone gets comfortable.> What are the precise gains from changing the status quo? What can you > do by moving everything to Git that you couldn't do in the current > world with svn as master repository and the additional git mirror?I work on a third-party branch. I can sync with upstream and push our changes back to upstream nearly trivially with git. With svn it is unpleasent, to say the least. The centralized model is in many ways completely wrong for a codebase like LLVM which is explicitly expected to be forked and enhanced in proprietary ways. By definition there will be many copies of the repository. A DVCS allows everyone to keep those copies in sync. To me this is the killer feature of any DVCS.> If the argument is better branching, I would like to see it clarified > for how this improves the workflow.I often come across the case where I want to share some changes with a few colleagues but don't want to push it to "mainline" for fear of disturbing too many people. Local branches are great for this kind of thing.> Advocats of DVCS tend to ignore the cost of the move. The linear commit > graph and associated properties is the biggest one.I think the linear commit graph is in many ways misleading. As has been pointed out, it is common to think "r33423" implies every change before that, but it does not. It is very easy to forget to merge a change from one branch to another. git has some nice ways to verify that a change has migrated from one branch to another. That doesn't require a DVCS but to my knowledge svn doesn't have something similar built-in. I don't know about other SCM systems. -Dave
Óscar Fuentes <ofv at wanadoo.es> writes:> If there is a feature that sets distributed version control systems > apart from the traditional ones it is their role as communication > tools.This is probably the best, most concise statement of git/DVCS advantages I have seen anywhere. -Dave
On Sat, Jul 23, 2011 at 05:49:38AM +0200, Óscar Fuentes wrote:> Joerg Sonnenberger <joerg at britannica.bec.de> writes: > > > You know, this is exactly the crux of this whole "move to git" thread. > > It is the very same problem of every other VCS migration I have seen (or > > dealt with). The core issue here is that you are effectively telling us > > that the current workflow is not supported by Git. > > It is supported, but if you want to work svn-style, nothing better than > svn itself.Given that the svn-style workflow is not specific to svn, that sounds like a good reason for not changing to git...> > You are also telling us that the current workflow is in some way wrong > > or misguided or suboptimal and has to change. > > Suboptimal is the right word. There is nothing essentially wrong with > everybody-and-his-cat pushing revisions to mainline but an user with > write privileges to a git repo can make quite a bit of damage. Undoing > that damage usually will cause inconveniences to everybody. Having a set > of maintainers with write privileges that incorporates patches submitted > to the mailing list, *maybe* is a better arrangement.You are saying that git forces a different workflow because it is so easy to mess up a repository with write access? I know exactly what you mean. I have also dealt with bogus messed up work on other VCS and so far, git beats them all. That's not exactly a good argument for git though.> > Let's avoid all the religious argument about how distributed version > > control is somehow better than centralistic version control. What are > > the precise gains from changing the status quo? What can you do by > > moving everything to Git that you couldn't do in the current world > > with svn as master repository and the additional git mirror? > > git-svn is quite ok for lone developers doing experiments or coding > small features, but if you work on a team and/or the changes are > submitted on incremental steps, you have a problem because, for > instance, git-svn will not recognize the revisions you contributed to > the svn's repo as the same you and you co-workers already have in your > git branch.Either this makes git buggy or it isn't different from manually applied patches in every other system I have dealt with. Heck, many patches submitted to mailing lists are not committed as is, so you would have merge overhead anyway. Especially the interesting non-trivial ones.> If there is a feature that sets distributed version control systems > apart from the traditional ones it is their role as communication > tools. I can choose *not* to communicate my work to the public (or keep > it within a restricted group) without giving out the convenience of > using a version control system, or publishing my work on a way that it > is easy for others to access, extend and incorporate into their own > developments. Both this possibilities are positive for the project, for > a variety of reasons. git-svn, as explained on the previous paragraph, > is a hindrance for using the communication possibilities of git.So this goes back to "it isn't git". Let's imagine for a moment that LLVM would move to Mercurial. Most of your arguments would still apply. Now, there is nothing wrong with using Mercurial on top of SVN. Basically, all the good points of Git also apply to Mercurial. So choosing it over Git gives pretty much the same advantages, but it still doesn't address your specific concerns. Hm....> > If the argument is "I don't like svn", it is weak. Others don't like Git > > and would prefer Mercurial. Or Bazaar. Or maybe even Perforce or CVS. > > > > If the argument is better branching, > > Better *merging*. > > > I would like to see it clarified for how this improves the workflow. I > > have dealt with many open source projects and many VCS variants. I > > don't see a noticable improvement from using Git compared e.g. to SVN > > for sane usage of branches -- be it short-term feature branches, > > mid-term restructoring or long-term release branches. > > Merging support in svn is brain-dead. Having a single commit "Merged > branch foo rX:Y" is hardly informative. Having the actual chunk of VC > history merged into the target branch is the Right Thing.I can't even make sense of your statement. Subversion has merge tracking, so it certainly keeps track of "where did this chunk of history come from".> > The exception > > may be doing wild cross branch merging and long dependency chains > > between branches like done in the Linux kernel -- but I don't think > > that's a sane development model and I certainly don't see that > > agreeing with the development policy of LLVM. > > I'm sure that, conciously or not, the development policy of LLVM was > conditioned by the limitations imposed by the VC tools the project used > so far: CVS and svn (which is CVS refurbished). I can't believe that > anyone thinks it is a good thing to scatter the commits that implements > a feature all over the VC history, instead of atomically merging them > á-la-git, with a parent-child relation that shows those commits as part > of a logically consistent series and giving the precise point where the > feature was incorporated into mainline.Again, I can't make sense of your statement. I've done merging in both CVS and svn of features. Both in the form of incremental patches and as atomic patch. Surprisingly, both approaches work for different cases. The cases where incremental and non-continious patches are used tended to be larger scale changes to otherwise active parts of the tree, where the overhead of permanent merging is greater. Merging in the non-fast-forward sense for git speakers.> > The linear commit > > graph and associated properties is the biggest one. > > However, I'm also saying that if the loss of the LG (Linear Graph) is > the biggest one, then the stumbling rock for adopting git is not > realizing its potential. The LG is convenient for some tasks, but it is > also a limiting factor for others. You are accustomed to its > conveniences and accepted its limitations (possibly without much > thinking). You are not accustomed to the advantages of using a tool like > git. Once the transition is *correctly* done, the loss of the LG will > seem as a petty one.You still have given me a good argument for giving up the convience. All you have been talking about so far are issues of git. Joerg
On Jul 22, 2011, at 10:55 PM, David A. Greene wrote:>> >> What are the precise gains from changing the status quo? What can you >> do by moving everything to Git that you couldn't do in the current >> world with svn as master repository and the additional git mirror? > > I work on a third-party branch. I can sync with upstream and push our > changes back to upstream nearly trivially with git. With svn it is > unpleasent, to say the least. > > The centralized model is in many ways completely wrong for a codebase > like LLVM which is explicitly expected to be forked and enhanced in > proprietary ways. By definition there will be many copies of the > repository. A DVCS allows everyone to keep those copies in sync. > > To me this is the killer feature of any DVCS.This is great, sounds like a handy feature, but I really don't care. We are not fundamentally changing the development policy around LLVM. This policy centers around small and incremental changes that are reviewed. It includes the fact that trusted people have direct commit access to mainline. In includes the fact that we have releases branched from mainline, and process around that. I am completely uninterested in the linux kernel model, which assumes that everyone is trying to break things and which requires hierarchical pulling of trees. Perhaps that models makes sense when the community is full of assholes :), but I'd rather solve the root problem and have a nice community instead developing a workflow around jerks. Let me say this again: We are not fundamentally changing the development policy around LLVM. If git doesn't offer advantages over SVN for our current workflow, then we should not switch to it. -Chris
> On Sat, Jul 23, 2011 at 01:02:10AM +0200, Óscar Fuentes wrote: > What can you do by moving everything to Git that you > couldn't do in the current worldGet the history of a piece of code that was refactored to a different file. SVN cannot do this, git can. No network latency, i.e. faster operations and less interruptions of the train of thought.> with svn as master repository and the > additional git mirror?More alternate workflows as they are useful.> If the argument is better branching, I would like to see it clarified > for how this improves the workflow. I have dealt with many open source > projects and many VCS variants. I don't see a noticable improvement from > using Git compared e.g. to SVN for sane usage of branches -- be it > short-term feature branches, mid-term restructoring or long-term release > branches. The exception may be doing wild cross branch merging and long > dependency chains between branches like done in the Linux kernel -- but > I don't think that's a sane development model and I certainly don't see > that agreeing with the development policy of LLVM.The Linux people would probably strongly disagree that their development policy is insane. And they have a history of success to back up their claims.> If the argument is doing detached development, that is already possible. > Approaches include the Git mirror, SVN mirroring solutions etc.Slow, so done less often than what people would want to do.> Advocats of DVCS tend to ignore the cost of the move. The linear commit > graph and associated properties is the biggest one.You don't have a linear commit graph unless you disallow merges in the project policy. Independently of whether you use svn or git. svn does present you with a "trunk" branch that runs linearly, but that's just a convention, and can even be misleading (when the most important changes in a piece of code were done in a branch and merged later).> This can be dealt > with as part of a defined workflow, but that is far more work than just > saying "use tool XXX"Yep, switching to git would require a lot of work on the project maintainers' side. Commit hooks, setting up repositories, rewording policies in terms of the commands of the new tools, and that only to regain the status the project already has - to actually reap benefits in the form of workflow flexibility, there's even more investment in trying that out. The one instant benefit that I see is content tracking instead of by-file tracking. Still, there's a learning curve. In the end, I guess it's the team's decision :-)
Lot of good points.> Yep, switching to git would require a lot of work on the project > maintainers' side. Commit hooks, setting up repositories, rewording > policies in terms of the commands of the new tools, and that only to > regain the status the project already has - [...]All of which could be done on a mirror, with pushes to svn during the transition. Once it can be treated as the "official mainline", turn off svn. If it turn out ugly, keep svn.