4 ms·

I think the main issue there is that the trunk is not stable, not that people forked off unstable points. We only land tested, verified code in the trunk. Each

by lt 16y ago

I think the main issue there is that the trunk is not stable, not that people forked off unstable points. We only land tested, verified code in the trunk. Each trunk revision is pretty much a separate release. Features are developed in feature branches and multiple features are merged into an acceptance branch for testing. Once accepted, they are merged into the trunk and put in production. This is using SVN though. I wonder how it compares to a git workflow.

jedbrown 16y ago
they are merged into the trunk Do you mean to say that this process never introduces bugs? With subversion's merge model?
- Goosey 16y ago
  I can't speak for the grandparent, but we use a similar system here and also on SVN. We have a 'core' team and a number of 'project' teams. Every team works in it's own branch, which is branched off of the trunk. The trunk is kept in a stable state. No one really uses 'feature branches', which I find to be a shame (but hey, it is SVN so feature branches are not convenient). Rather the core team creates a new branch each sprint (scrum here - 3 week sprints) and at the end of each sprint merges it back into trunk, after it has been verified as stable by QA. Project teams can either branch from trunk and stay off in la-la land until the end of time, or they can try to keep up to date. The way they keep up to date is by merging back into trunk and then starting a new branch. This process is hand-held by the core team and goes through the same QA process to verify it is stable. How does this work out? Well merging is a major event. Aside from the stability verification work that goes into it a core team member (usually the lead) will generally spend about a day on a merge/branch cycle. So it feels slow and big, but we do maintain a very stable trunk. SVN merge issues are a pain, but so long as we never do double-merges (that is, merging a branch into trunk, continuing work on the branch, then merging it a 2nd time into trunk) we seem to avoid the most common gotcha. This system would be improved if a DVCS was used instead. The issues to adoption of that are both user and technical. We have a wide range of users of widely varying technical skill levels so the ecosystem of SVN clients is going to be difficult to usurp. We also store a LOT of very large binary data in the repository and would find it very inconvenient to separate it out (code version and asset version matching is essential), and in my tests of using git-svn (for example) it simply choked. Like an exception thrown from the bowls of the client type of choke.
SkyMarshal 16y ago
It works similarly if you're using the gitflow extension: https://github.com/nvie/gitflow https://github.com/nvie/gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo... Or doing that manually. Git is pretty flexible.
InclinedPlane 16y ago
I detect a bit of arrogance on Linus' part here. The conclusions follow directly from the notion that whatever Linus does is right and others should accommodate to that. In my experience and observation the correct solution to this problem is as you've said, keep the trunk branch stable to as high a standard as you can. That way the cost of stability is pushed to the people making unstable changes, rather than onto every developer.

by lt 16y ago

jedbrown 16y ago

they are merged into the trunk Do you mean to say that this process never introduces bugs? With subversion's merge model?

Goosey 16y ago
I can't speak for the grandparent, but we use a similar system here and also on SVN. We have a 'core' team and a number of 'project' teams. Every team works in it's own branch, which is branched off of the trunk. The trunk is kept in a stable state. No one really uses 'feature branches', which I find to be a shame (but hey, it is SVN so feature branches are not convenient). Rather the core team creates a new branch each sprint (scrum here - 3 week sprints) and at the end of each sprint merges it back into trunk, after it has been verified as stable by QA. Project teams can either branch from trunk and stay off in la-la land until the end of time, or they can try to keep up to date. The way they keep up to date is by merging back into trunk and then starting a new branch. This process is hand-held by the core team and goes through the same QA process to verify it is stable. How does this work out? Well merging is a major event. Aside from the stability verification work that goes into it a core team member (usually the lead) will generally spend about a day on a merge/branch cycle. So it feels slow and big, but we do maintain a very stable trunk. SVN merge issues are a pain, but so long as we never do double-merges (that is, merging a branch into trunk, continuing work on the branch, then merging it a 2nd time into trunk) we seem to avoid the most common gotcha. This system would be improved if a DVCS was used instead. The issues to adoption of that are both user and technical. We have a wide range of users of widely varying technical skill levels so the ecosystem of SVN clients is going to be difficult to usurp. We also store a LOT of very large binary data in the repository and would find it very inconvenient to separate it out (code version and asset version matching is essential), and in my tests of using git-svn (for example) it simply choked. Like an exception thrown from the bowls of the client type of choke.

SkyMarshal 16y ago

It works similarly if you're using the gitflow extension: https://github.com/nvie/gitflow https://github.com/nvie/gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flo... Or doing that manually. Git is pretty flexible.

InclinedPlane 16y ago

I detect a bit of arrogance on Linus' part here. The conclusions follow directly from the notion that whatever Linus does is right and others should accommodate to that. In my experience and observation the correct solution to this problem is as you've said, keep the trunk branch stable to as high a standard as you can. That way the cost of stability is pushed to the people making unstable changes, rather than onto every developer.