tag:blogger.com,1999:blog-27232680.post2361467882290875184..comments2024-03-20T06:54:32.435+01:00Comments on Plastic SCM blog: Linus on branching...F3RD3Fhttp://www.blogger.com/profile/11524626976811746062noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-27232680.post-66771790196116251532015-08-28T18:59:00.413+02:002015-08-28T18:59:00.413+02:00The link to the original email from Linus is broke...The link to the original email from Linus is broken. Here's the Internet Archive's version:<br /><br />https://web.archive.org/web/20101203061221/http://lkml.org/lkml/2010/9/28/362Farrellhttps://www.blogger.com/profile/00917823303170288738noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-33719180916686291092011-03-21T06:15:16.732+01:002011-03-21T06:15:16.732+01:00Thanks very much for this post. It well explains a...Thanks very much for this post. It well explains a simple solution to a fundamental problem.trevnorrishttps://www.blogger.com/profile/03061732493466968427noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-7812345817691801912010-12-01T01:24:27.721+01:002010-12-01T01:24:27.721+01:00@Anonymous: "I *do* have experience with...&q...@Anonymous: "I *do* have experience with..."<br /><br />Absolutely. Tools are just... tools. Then you still need to use them correctly.<br /><br />What we try to do with plastic is to offer the most powerful possible SCM... but still, if you don't do things in a meaningful way... you're toasted!Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-4690702950234074332010-12-01T01:19:21.472+01:002010-12-01T01:19:21.472+01:00@Anonymous: "whether and when to merge from t...@Anonymous: "whether and when to merge from trunk to get other contributions" True, but in my experience branches tend to be much more independent than we initially think, so merging between branches happen but not that often.<br /><br />That's why I like pure <a href="http://www.plasticscm.com/infocenter/quick-start.aspx" rel="nofollow">branch per task so much</a>, because branches are so short lived that you almost never branch between task branches.<br /><br />And even if you do, ok, then of course you can be hit by others bugs, but you still have the integration for review and you are less concerned about starting from a broken point even under these circumstances.Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-57527497813570818992010-12-01T01:18:10.984+01:002010-12-01T01:18:10.984+01:00I *do* have experience with several codebases comp...I *do* have experience with several codebases comparable in size to the linux kernel, with about 40 genuinely active (and a few hyper-active) developers. Always merge from a known good label. But don;t expect that to make life easy. There is no substitute for thinking about every single branch and merge. Good tools and good practices just make it easier to do the right thing. But everyone has to be thinking, all the time.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27232680.post-74333436060107488142010-12-01T01:14:49.467+01:002010-12-01T01:14:49.467+01:00The advice here is worth thoughtful consideration....The advice here is worth thoughtful consideration. But it really oversimplifies reality -- for many shops -- by neglecting the fact that even those branches from a common stable point all need to be merged back into trunk at some later time. And they're not all going to be merged at the same time. Someone has to to be first, and the longer-lived branches are faced with a choice: whether and when to merge from trunk to get other contributions. As soon as they do that once, the idea of passing around simple, obvious-to-inspection diffs is seen to be a fallacy. Merging from a stable revision is always a good idea, but not necessarily for the reasons claimed here.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27232680.post-15992572957551842302010-11-30T21:47:52.323+01:002010-11-30T21:47:52.323+01:00@Anonymous: yes, this one. I had to pay extra $300...@Anonymous: yes, this one. I had to pay extra $300 to get the auto-exclamation feature! :PPablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-7679122405310213192010-11-30T21:45:55.036+01:002010-11-30T21:45:55.036+01:00@Pablo, the special version that adds gratuitous e...@Pablo, the special version that adds gratuitous exclamation marks to the labels.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27232680.post-79054039163225853142010-11-30T20:33:37.841+01:002010-11-30T20:33:37.841+01:00This is actually exactly how development of OpenOf...This is actually exactly how development of OpenOffice.org works (with one additional step): http://wiki.services.openoffice.org/wiki/Mercurial/Cws<br /><br />"child workspace"/cws is just a feature branch. Once a feature branch is ready it gets merged into the "DEV300_next" branch. After a set of feature branches have been merged and survived basic testing, "DEV300_next" gets tagged as a stable milestone and is pushed to "DEV300" (the master). As:<br />- no development is done on the master, - branches are only based on the master - and the push to the master is an atomic transaction<br />the master is reasonably save.<br /><br />There is just one exception to the "no development on the master" rule and that is buildbreakers (might happen when those where triggered by raceconditions). If something like that sneaks into the master and there is a trivial patch for it the changeset gets pushed to _both_ DEV300_next and DEV300.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27232680.post-32707542503021824422010-11-30T19:39:28.847+01:002010-11-30T19:39:28.847+01:00The branch development works fine, but the integra...The branch development works fine, but the integration is the part that bites. A follow up article on the best practices for integration would be a good follow-up to this article.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27232680.post-68839036060648948602010-11-30T18:30:01.515+01:002010-11-30T18:30:01.515+01:00If you have an automated test suite, you can have ...If you have an automated test suite, you can have it tag the mainline every time it passes; then you can keep stable from getting too far out-of-date from the head, which is the biggest downside to this scheme.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27232680.post-73464077635920308622010-11-30T18:28:52.371+01:002010-11-30T18:28:52.371+01:00master <- next <- feature
Assume master is ...master <- next <- feature<br /><br />Assume master is always fully tested and 'stable', branch 'feature' from there, and integrate on 'next'. That's an interesting approach I've seen even in the linux kernel itself.blackxoredhttps://www.blogger.com/profile/15908645650082155538noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-21251075801896493342010-11-30T17:11:08.847+01:002010-11-30T17:11:08.847+01:00@Anonymous: believe it or not... I just use Visio!...@Anonymous: believe it or not... I just use Visio! :PPablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-86262852256928342642010-11-30T17:10:17.089+01:002010-11-30T17:10:17.089+01:00@Phil: I do agree, the problem is that sometimes i...@Phil: I do agree, the problem is that sometimes is good to have intermediate checkins when you're merging branches back to trunk. Starting from a tagged cset or label is a good practice and it doesn't take that much to get used to it.Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-61137936700894485192010-11-30T15:29:54.806+01:002010-11-30T15:29:54.806+01:00Insightful post. Will keep this in mind.
An as...Insightful post. Will keep this in mind. <br /><br />An aside: what did you use to create your illustrations?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27232680.post-23664168681833895202010-11-30T14:01:37.052+01:002010-11-30T14:01:37.052+01:00The problem seems to be caused by not documenting ...The problem seems to be caused by not documenting the assumptions about the branches carefully enough (as in whether a branch's commits can be broken or not). I guess nothing prevents you from having a breakable master as long as that is documented somewhere. Unless there is some clearly labeled "production" branch most people will probably assume that the master should be in working condition at all times. So either, a) Linus doesn't use branches correctly, b) the kernel developers haven't documented the fact that the master may be broken or c) none of the above, ie something related to maintaining a project of the Linux Kernel's size which I personally don't have much practical experience of.Samuhttps://www.blogger.com/profile/12186701275237033617noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-51146058422833413802010-11-30T12:16:40.022+01:002010-11-30T12:16:40.022+01:00Or you do what we do: keep trunk pristine - no dev...Or you do what we do: keep trunk pristine - no development should EVER occur in your trunk and it should always be possible to push a stable release from it.<br /><br />Yes, it takes discipline, but IMHO it's easier to maintain than getting people to all branch from the same revision.Philnoreply@blogger.com