On Jul 22, 2011, at 2:02 PM, Andrew Trick wrote:>> Of course, if you've used SVN extensively, you've been trained to think >> that history has to be somewhat linear, and perhaps even that the trunk >> branch is the only one needing QA attention. Migration from SVN to Git >> is hard because you have to change the mental model, not just command >> names and how revisions are named. > > > You've mistaken me for someone who doesn't understand why DVCS is important. Please stop using this list to evangelize git. > > My point is that we have QA and release engineering processes that work on each branch independently and work best with chronological build #s *per branch*. > > I would like to think that git generation numbers are sufficient for this so we don't need to resort to timestamps or tags. Mercurial has local revision numbers for this purpose, which I thought were quite handy. Comments on that point are welcome.I completely agree. The "branch" I most care about is mainline, and losing the ability to say "fixed in r1234" (with some sort of monotonically increasing number) would be a tragic loss. -Chris
Chris Lattner <clattner at apple.com> writes:> I completely agree. The "branch" I most care about is mainline, and > losing the ability to say "fixed in r1234" (with some sort of > monotonically increasing number) would be a tragic loss.The monotonically increasing number is useful for giving you a fuzzy idea about how that change relates to other changes wrt the order it was applied and, similarly, the approximate timeline. The usefulness of having this information on an immediate form is amplified by *not* appreciating the advantages of a distributed version control system (DVCS). Once the community starts using DVCS, answering the question "is revision X in branch Y?" will be far more important, and that is something that a monotonically increasing revision number do not solve. I understand your views and doubts, because I had the same ones at some point on the past. After using some propietary systems, then CVS, then svn, then Bazaar (which is a DVCS wich supports revision numbers, a feature that weighted on its favor for choosing it after using svn for several years) and finally git, the advantages of a DVCS over a svn-like system are so compelling that the convenience of revision numbers is insignificant in comparison. On the other hand, I guess that you being so mainline-centered (and the root explanation of some LLVM developer policies) is, in part, a consequence of how hard branching and merging is with CVS and svn. After git, mainline will still be the most important branch for the *project*, but you will work with quite a few branches on parallel.
> After git, mainline will still be the most important branch for the > *project*, > but you will work with quite a few branches on parallel. > >Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". The git workflow works really really great, but it does require getting rid of mainline thinking. It doesn't exist. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110723/fb3584ab/attachment.html>
On Jul 22, 2011, at 3:33 PM, fly language wrote:> > After git, mainline will still be the most important branch for the *project*, > but you will work with quite a few branches on parallel. > > > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". > > The git workflow works really really great, but it does require getting rid of mainline thinking. It doesn't exist.I strongly disagree with this. Having a mainline, whether enforced by the VCS or not, is crucial to our incremental development philosophy. For example, we need small, incremental patches going into one mainline branch in order for our buildbots to usefully identify regressions. We also bisect performance regressions quite a lot, but if someone goes off and does a bunch of development on a branch and then lands it in mainline all at once, we'll be completely unable to pinpoint the source of any regressions from that branch. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110722/c3344357/attachment.html>
fly language <flylanguage at gmail.com> writes:>> After git, mainline will still be the most important branch for the >> *project*, >> but you will work with quite a few branches on parallel. >> >> > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to > maintain the "mainline". > > The git workflow works really really great, but it does require getting rid > of mainline thinking. It doesn't exist.This is not quite true. At least for LLVM. `mainline' here is "from where release branches are created." 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. I was involved on the Emacs transition to Bazaar from CVS. Converting the repositories was a minor task in comparison to the educational effort to adapt people's mindset to a DVCS. Some years after the migration, people is still not thinking on terms of a DVCS, making fundamental mistakes along the way. LLVM developers have a very different profile and I'm sure that things will settle down after just a few rough weeks if the right decisions are made from the start.
On Jul 22, 2011, at 3:04 PM, Óscar Fuentes wrote:> Chris Lattner <clattner at apple.com> writes: > >> I completely agree. The "branch" I most care about is mainline, and >> losing the ability to say "fixed in r1234" (with some sort of >> monotonically increasing number) would be a tragic loss. > > The monotonically increasing number is useful for giving you a fuzzy > idea about how that change relates to other changes wrt the order it was > applied and, similarly, the approximate timeline.Yes, I care about the order they are applied, to mainline.> The usefulness of having this information on an immediate form is > amplified by *not* appreciating the advantages of a distributed version > control system (DVCS). Once the community starts using DVCS, answering > the question "is revision X in branch Y?" will be far more important, > and that is something that a monotonically increasing revision number do > not solve.I actually do appreciate distributed systems. For the overall success and longevity of the LLVM project, mainline is the most important branch. -Chris
On Jul 22, 2011, at 3:45 PM, Bob Wilson wrote:> > On Jul 22, 2011, at 3:33 PM, fly language wrote: > >> >> After git, mainline will still be the most important branch for the *project*, >> but you will work with quite a few branches on parallel. >> >> >> Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". >> >> The git workflow works really really great, but it does require getting rid of mainline thinking. It doesn't exist. > > I strongly disagree with this. Having a mainline, whether enforced by the VCS or not, is crucial to our incremental development philosophy. For example, we need small, incremental patches going into one mainline branch in order for our buildbots to usefully identify regressions. We also bisect performance regressions quite a lot, but if someone goes off and does a bunch of development on a branch and then lands it in mainline all at once, we'll be completely unable to pinpoint the source of any regressions from that branch.Bob is spot on here. The part I agree with in concept is: "I agree that changing from SVN to GIT could be beneficial". I specifically *do not* think that we should fundamentally change our development methodology. Mainline should exist, it should be where code reviews happen, and the existing policies around it should continue to exist. Release branches should be made from it every ~6 months, etc. I really do appreciate distributed VCS, but only as staging. Incremental development is crucial for the project and "take this git push with 100K of code" will never be acceptable. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110722/de5db7d5/attachment.html>
Bob Wilson <bob.wilson at apple.com> writes:> I strongly disagree with this. Having a mainline, whether enforced by > the VCS or not, is crucial to our incremental development philosophy. > For example, we need small, incremental patches going into one > mainline branch in order for our buildbots to usefully identify > regressions. We also bisect performance regressions quite a lot, but > if someone goes off and does a bunch of development on a branch and > then lands it in mainline all at once, we'll be completely unable to > pinpoint the source of any regressions from that branch.git bisect. The development done on the individual branch should still be done in an incremental fashion. If the merge to mainline fails, git bisect can be run on the branch to identify the culprit. -Dave
Chris Lattner <clattner at apple.com> writes:> I really do appreciate distributed VCS, but only as staging. > Incremental development is crucial for the project and "take this git > push with 100K of code" will never be acceptable.I'm a little confused. To me "staging" means incremental development, getting things integrated correctly, etc. The final merge to "mainline" is little more than a formality. You don't really want each individual commit from the local branch cherry-picked on-by-one to mainline, do you? -Dave
Chris Lattner <clattner at apple.com> writes:> I really do appreciate distributed VCS, but only as staging. > Incremental development is crucial for the project and "take this git > push with 100K of code" will never be acceptable.Incremental development is probably promoted by DVCS far more than others. Your comment seems to imply that only the tip of each push is important. In the Git world, it usually isn't. The flow promoted by Git is precisely to make sure each and every commit passes the tests. So, the granularity of "incremental development" is really the commit, not how often you merge. "git bissect" is a good illustration of this. It does not only bissect accross the mainline, but it does all along the DAG. For example, if you bisect a regression between linux-2.6.38 and linux-2.6.39, you may well end up with a guilty commit that was written long before linux-2.6.38, but merged in the window between 2.6.38 and 2.6.39. In a world where only merges are important, it's acceptable to have a history like merge feature A +- start feature A +- oops, typo +- oops, forgot a svn add +- continue feature A +- oops, another fix in first commit merge feature B ... With Git's best practice, you may have such history locally, but you should not push it as it is. You usually rework your history (things like "git rebase -i" are just great for that) to clean it up, and then have it accepted by upstream. Ideally, you make sur the testsuite passes for each commit before pushing. If you like incremental development, you're going to love DVCS. -- Matthieu Moy http://www-verimag.imag.fr/~moy/
>>> After git, mainline will still be the most important branch for >>> the *project*, >>> but you will work with quite a few branches on parallel. >>> >>> >>> Who's mainline? :) Be prepared to assign a super-merger, like Linus, >>> to maintain the "mainline". >>> >>> The git workflow works really really great, but it does require >>> getting rid of mainline thinking. It doesn't exist. >> >> I strongly disagree with this. Having a mainline, whether enforced by >> the VCS or not, is crucial to our incremental development philosophy. >> For example, we need small, incremental patches going into one >> mainline branch in order for our buildbots to usefully identify >> regressions. We also bisect performance regressions quite a lot, but >> if someone goes off and does a bunch of development on a branch and >> then lands it in mainline all at once, we'll be completely unable to >> pinpoint the source of any regressions from that branch. > > Bob is spot on here.Yes, but who's mainline? Is the plan to have a centralized repo with a mainline branch that everybody pushes to, or the a linux style model where some person has an official mainline to which he pulls? It's quite different things.
On Jul 23, 2011, at 5:37 AM, FlyLanguage wrote:> Yes, but who's mainline? Is the plan to have a centralized repo with a mainline branch that everybody pushes to, or the a linux style model where some person has an official mainline to which he pulls? > > It's quite different things.>From my interpretation of what Chris has said about this, it would be the former (centralized repo with a master branch that everyone pushes to). I agree with that. We have a development process that works well, and I see no compelling reasons to change it.Personally I think our current system is a very nice middle ground. We get nice sequential revision numbers from svn, and behind the scenes everyone can go crazy with git. It's a little awkward to set up a new repo that pulls from the git mirrors and also lets you use git-svn dcommit to push back, but that's a minor nuisance AFAICT.
Yes, I do. -Chris On Jul 22, 2011, at 10:45 PM, greened at obbligato.org (David A. Greene) wrote:> Chris Lattner <clattner at apple.com> writes: > >> I really do appreciate distributed VCS, but only as staging. >> Incremental development is crucial for the project and "take this git >> push with 100K of code" will never be acceptable. > > I'm a little confused. To me "staging" means incremental development, > getting things integrated correctly, etc. The final merge to "mainline" > is little more than a formality. You don't really want each individual > commit from the local branch cherry-picked on-by-one to mainline, do > you? > > -Dave
Den 23.07.2011 20:38, skrev Bob Wilson:> > On Jul 23, 2011, at 5:37 AM, FlyLanguage wrote: >> Yes, but who's mainline? Is the plan to have a centralized repo with a mainline branch that everybody pushes to, or the a linux style model where some person has an official mainline to which he pulls? >> >> It's quite different things. > >> From my interpretation of what Chris has said about this, it would be the former (centralized repo with a master branch that everyone pushes to). I agree with that. We have a development process that works well, and I see no compelling reasons to change it. > > Personally I think our current system is a very nice middle ground. We get nice sequential revision numbers from svn, and behind the scenes everyone can go crazy with git. It's a little awkward to set up a new repo that pulls from the git mirrors and also lets you use git-svn dcommit to push back, but that's a minor nuisance AFAICT. >I totally agree; when using a centralized repo, you might as well slap git on top of svn (maybe with some pre-central mainline sanity checks on the git pulls.) In that case, no need to change the current setup IMO.
On Jul 23, 2011, at 4:34 AM, Matthieu Moy wrote:> Chris Lattner <clattner at apple.com> writes: > >> I really do appreciate distributed VCS, but only as staging. >> Incremental development is crucial for the project and "take this git >> push with 100K of code" will never be acceptable. > > Incremental development is probably promoted by DVCS far more than > others. Your comment seems to imply that only the tip of each push is > important. In the Git world, it usually isn't. > > The flow promoted by Git is precisely to make sure each and every commit > passes the tests. So, the granularity of "incremental development" is > really the commit, not how often you merge.Again, to reiterate, I don't care. This model is based on the idea of some trusted maintainer doing code review of the branch and then pushing it to mainline as a huge batch when everything is happy and working. This is fundamentally in tension with the LLVM model and I have no desire for us to switch. -Chris> > "git bissect" is a good illustration of this. It does not only bissect > accross the mainline, but it does all along the DAG. For example, if you > bisect a regression between linux-2.6.38 and linux-2.6.39, you may well > end up with a guilty commit that was written long before linux-2.6.38, > but merged in the window between 2.6.38 and 2.6.39. > > In a world where only merges are important, it's acceptable to have a > history like > > merge feature A > +- start feature A > +- oops, typo > +- oops, forgot a svn add > +- continue feature A > +- oops, another fix in first commit > merge feature B > ... > > With Git's best practice, you may have such history locally, but you > should not push it as it is. You usually rework your history (things > like "git rebase -i" are just great for that) to clean it up, and then > have it accepted by upstream. Ideally, you make sur the testsuite passes > for each commit before pushing. > > If you like incremental development, you're going to love DVCS. > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/
On Jul 23, 2011, at 5:37 AM, FlyLanguage wrote:>>>> After git, mainline will still be the most important branch for >>>> the *project*, >>>> but you will work with quite a few branches on parallel. >>>> >>>> >>>> Who's mainline? :) Be prepared to assign a super-merger, like Linus, >>>> to maintain the "mainline". >>>> >>>> The git workflow works really really great, but it does require >>>> getting rid of mainline thinking. It doesn't exist. >>> >>> I strongly disagree with this. Having a mainline, whether enforced by >>> the VCS or not, is crucial to our incremental development philosophy. >>> For example, we need small, incremental patches going into one >>> mainline branch in order for our buildbots to usefully identify >>> regressions. We also bisect performance regressions quite a lot, but >>> if someone goes off and does a bunch of development on a branch and >>> then lands it in mainline all at once, we'll be completely unable to >>> pinpoint the source of any regressions from that branch. >> >> Bob is spot on here. > > > Yes, but who's mainline? Is the plan to have a centralized repo with a mainline branch that everybody pushes toThis one.> , or the a linux style model where some person has an official mainline to which he pulls?Not this one. This shouldn't be a mysterious concept, our policies are well documented here: http://llvm.org/docs/DeveloperPolicy.html#policies -Chris
>> Yes, but who's mainline? Is the plan to have a centralized repo with a mainline branch that everybody pushes to > > This one. > >> , or the a linux style model where some person has an official mainline to which he pulls? > > Not this one. > > This shouldn't be a mysterious concept, our policies are well documented here: > http://llvm.org/docs/DeveloperPolicy.html#policiesNo mystery, just nice to know which setup llvm will have.
Chris Lattner <clattner at apple.com> writes:> On Jul 23, 2011, at 4:34 AM, Matthieu Moy wrote: > >> Chris Lattner <clattner at apple.com> writes: >> >>> I really do appreciate distributed VCS, but only as staging. >>> Incremental development is crucial for the project and "take this git >>> push with 100K of code" will never be acceptable. >> >> Incremental development is probably promoted by DVCS far more than >> others. Your comment seems to imply that only the tip of each push is >> important. In the Git world, it usually isn't. >> >> The flow promoted by Git is precisely to make sure each and every commit >> passes the tests. So, the granularity of "incremental development" is >> really the commit, not how often you merge. > > Again, to reiterate, I don't care. > > This model is based on the idea of some trusted maintainer doing code > review of the branch and then pushing it to mainline as a huge batch > when everything is happy and working. This is fundamentally in tension > with the LLVM model and I have no desire for us to switch.This is simply not true. There's no relation between considering each commit as important and the idea of a central maintainer. -- Matthieu Moy http://www-verimag.imag.fr/~moy/
Bob Wilson <bob.wilson at apple.com> writes:> It's a little awkward to set up a new repo that pulls from the git > mirrors and also lets you use git-svn dcommit to push back, but that's > a minor nuisance AFAICT.No to people who use git regularly, it isn't. git-svn imposes all sorts of restrictions on what kind of commits it wants to see and the git user ends up having to work around them. Things that are trivial with git (merges) become more complicated with git-svn. This in turn fundamentally changes how git can be used by the developer. -Dave
Chris Lattner <clattner at apple.com> writes:> On Jul 22, 2011, at 10:45 PM, greened at obbligato.org (David A. Greene) wrote:>> I'm a little confused. To me "staging" means incremental development, >> getting things integrated correctly, etc. The final merge to "mainline" >> is little more than a formality. You don't really want each individual >> commit from the local branch cherry-picked on-by-one to mainline, do >> you?> Yes, I do.Why? -Dave
Chris Lattner <clattner at apple.com> writes:> On Jul 23, 2011, at 4:34 AM, Matthieu Moy wrote: > >> The flow promoted by Git is precisely to make sure each and every commit >> passes the tests. So, the granularity of "incremental development" is >> really the commit, not how often you merge.> This model is based on the idea of some trusted maintainer doing code > review of the branch and then pushing it to mainline as a huge batch > when everything is happy and working. This is fundamentally in > tension with the LLVM model and I have no desire for us to switch.Ah. Here is where I think we have some miscommunication happening. Here's how I am thinking about things. Reviews should keep happening the way they are. In fact, what we are doing now is exactly the same work one would have to do to review a git branch, but that's immaterial. There are great tools in git for sending a patch stream to the mailing list. To me, there isn't a compelling reason to change the current review system. I think the disagreement (if we can call it that) is really over what actually gets pushed to "mainline" which I assume would be defined as "master" on llvm.org. Chris wants the commits to happen in sequence, in exactly the same order as patches sent to the review list. It is not very difficult to do this in git. It's slightly more involved, but not overly burdensome. Others (like me) have argued that once patches have been reviewed on a branch, merging the branch directly to master is not functionally different than a stream of commits. It is semantically different in the way history gets presented on master, which is where I think the root of the disagreement lies. But either way, git bisect, etc. should be able to ferret out any problems. I'm not going to push hard against a "cherry-pick every commit to merge" approach if it means we can move to git. The benefits of a switch to git far outweigh any downsides of the slightly increased merge work relative to a "pure merge" approach. That said, down the road after we get some experience with git, I would hope we could open a discussion about merge policy. But not after quite some time. -Dave