tag:blogger.com,1999:blog-27232680.post5880594748286759314..comments2024-03-20T06:54:32.435+01:00Comments on Plastic SCM blog: Branch per task workflow explainedF3RD3Fhttp://www.blogger.com/profile/11524626976811746062noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-27232680.post-69468854626003371612012-04-24T08:05:17.197+02:002012-04-24T08:05:17.197+02:00@Michael: sure, I'd love to hear about it. CC ...@Michael: sure, I'd love to hear about it. CC was our initial source of inspiration.Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-74319892895455275722012-04-18T21:55:42.816+02:002012-04-18T21:55:42.816+02:00Just a historical point: ClearCase has had branch...Just a historical point: ClearCase has had branches since about 1990. I've been using them since 1996.<br /><br />We have evolved a method at my site for handling really tricky merges involving extensive changes that might be worth passing on. Projects like this are often out on development branches for long periods of time which makes the problem worse. In such a case we will have one person merge the main line and the development branch to an integration branch and then a second person merge the integration branch to main. That way all changes are inspected by two sets of eyes.Michael Fnoreply@blogger.comtag:blogger.com,1999:blog-27232680.post-75400516725167017122011-11-11T23:55:52.023+01:002011-11-11T23:55:52.023+01:00Excellent post .. very well explained scenarios an...Excellent post .. very well explained scenarios and a strong argument :)Paul Haymanhttps://www.blogger.com/profile/03383409288379541129noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-37542777221178802722011-11-11T23:54:21.040+01:002011-11-11T23:54:21.040+01:00Excellent post.. very well explained!Excellent post.. very well explained!Paul Haymanhttps://www.blogger.com/profile/03383409288379541129noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-78839849323399680352010-09-30T20:31:45.569+02:002010-09-30T20:31:45.569+02:00Hi Maxim,
Glad to see you came to us through awes...Hi Maxim,<br /><br />Glad to see you came to us through awesome's Acuary's translation! Great!<br /><br />About your question/remark: well, I don't think there's a rule of thumb here, it's more a matter of choice, a matter of taste if you prefer.<br /><br />The model you propose is: ok, you do your change on a branch, then merge it yourself, then you push the main branch.<br /><br />When that happens, you'd have to:<br /><br />a) Resolve any conflicts happened on the "master" while you were disconnected -> the burden of the integration goes back to you<br /><br />b) You can potentially "destabilize" (not sure if that's a correct word! ;O) the remote master in case you break something. An alternative for this is a "pull request" as you'd do with GitHub, but then we end up with something "closer" to replicating the task branches although admitedly not exactly the same.<br /><br />I normally recommend teams to keep all the task branches. Normally it is very good on commercial environments (companies) but I guess it doesn't make a lot of sense in the OSS world (and that's why Linus is saying that).<br /><br />I've a huge respect (it can't be otherwise!) for Torvalds, he's a genius, so if he says he doesn't want to keep task branches, there must be a reason. But, I also understand Linux kernel development is not exactly the same scenario as the one companies face on a daily basis.<br /><br />I totally agree with the approach of having "lieutenants" (integrators) doing the merges, because in a lot of scenarios it helps developers stay focused on what they do, and having someone "reviewing" the whole thing is pretty good.<br /><br />So, you can also do (with Plastic) the same scenario of keeping task branches private. I'd always prefer to push them back to the main server so you've on single place with a "whole view" of what happened (sometimes correctly committed branches, done in steps, help understanding changes, even bisecting and so on), but that could be just a personal preference based on my own experience.<br /><br />Thanks,<br /><br />pabloPablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-40584462580234836492010-09-30T18:13:44.654+02:002010-09-30T18:13:44.654+02:00Hi pablo,
read Aquary's russian translation a...Hi pablo,<br /><br />read Aquary's russian translation and got some questions.<br /><br />First - I think there is obvious difference between your approach and what "DVCS practitioners" offer.<br /><br />Consider an example from here<br />http://nvie.com/posts/a-successful-git-branching-model/<br /><br />$ git checkout develop<br />Switched to branch 'develop'<br />$ git merge --no-ff myfeature<br />Updating ea1b82a..05e9557<br />(Summary of changes)<br />$ git branch -d myfeature<br />Deleted branch myfeature (was 05e9557).<br />$ git push origin develop<br /><br />Same thing I read in Linus Torvalds speech about git ( in russian ) - he dislikes to store working ( per- task) branches in central repository.<br /><br />Conclusion - integrator role whose intent is to merge task-branches into trunk is very arguable, since "normally" task-branches exist on local copies only.<br /><br />Did I get something wrong ?Maxim Gehttps://www.blogger.com/profile/07231359245681331044noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-39345344943477773192010-09-07T01:11:24.757+02:002010-09-07T01:11:24.757+02:00Hi Pablo, just FYI - I've translated this post...Hi Pablo, just FYI - I've translated this post, here it is:<br /><br />http://scm-notes.blogspot.com/2010/09/branch-per-task-workflow-explained.html<br /><br />Now you have international publication ;)Aquaryhttps://www.blogger.com/profile/10690422971056030987noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-62628871512407410002010-08-26T23:30:23.701+02:002010-08-26T23:30:23.701+02:00Hi Pablo... I become annoying ;) , but you've ...Hi Pablo... I become annoying ;) , but you've introduced cset 10474 without mentioning it; still cset 10475 is referred to as a cset with query changes which is supposed to be exactly 10474.<br /><br />And - no, I'll just refer to your original figures in my translation :)Aquaryhttps://www.blogger.com/profile/10690422971056030987noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-38945691221490709622010-08-26T19:59:16.559+02:002010-08-26T19:59:16.559+02:00Guys: fixes are done:
- I removed Dick and put Pa...Guys: fixes are done:<br /><br />- I removed Dick and put Pat instead :)<br /><br />- I fixed the issues on images (thanks Acuary!)Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-77019874983201782652010-08-26T18:36:41.648+02:002010-08-26T18:36:41.648+02:00@Acuary: thanks for the remark! I'll try to ge...@Acuary: thanks for the remark! I'll try to get it fixed ASAP. Question: do you need the visio files to translate to Russian?? Feel free to ask.Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-64053473678766435812010-08-26T14:53:26.981+02:002010-08-26T14:53:26.981+02:00Pablo,
there's a typo in yours figures where ...Pablo, <br />there's a typo in yours figures where you get the single line and a number of changesets.<br /><br />Check figure 2 for example - there are 2 cset:10476 made by different users... Isn't that supposed to be 2 different csets like 10475 and 10476 ? I guess you can't do one cset using 2 users, can you?Aquaryhttps://www.blogger.com/profile/10690422971056030987noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-52391422208919134612010-08-06T17:01:37.786+02:002010-08-06T17:01:37.786+02:00Hi Aquary!
Thanks for the kind words! :)
Yes, fe...Hi Aquary!<br /><br />Thanks for the kind words! :)<br /><br />Yes, feel free to translate it to Russian, we'll love to see it! Send us the link!<br /><br />Regards,<br /><br />pabloPablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-79766836669250093292010-08-06T14:37:29.986+02:002010-08-06T14:37:29.986+02:00Pablo, that's a brilliant post! Short essay th...Pablo, that's a brilliant post! Short essay that can replace tons of texts about SCM.<br /><br />This one should be carved in marble :) :<br /><i>FAQ: But, weren’t branches supposed to be evil?<br />ANSWER: Who told you that? I bet you found that on some Subversion guide, forum or manual, maybe even at some other SCM website, didn’t you? </i><br />True. So true :) I see a lot of people using wrong tools and saying that branching is evil.<br /><br />Do you mind if I translate it in Russian?Aquaryhttps://www.blogger.com/profile/10690422971056030987noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-67046108687144476152010-08-06T02:07:22.743+02:002010-08-06T02:07:22.743+02:00@Andrew: thanks!! The image is plain Visio, nothin...@Andrew: thanks!! The image is plain Visio, nothing fancy I'm afraid... Just tweaking colors a little bit :-)Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-51974761262672429692010-08-06T02:06:09.686+02:002010-08-06T02:06:09.686+02:00X-DDDDDD. Ok, ok, I'll uppercase Dick!! Promis...X-DDDDDD. Ok, ok, I'll uppercase Dick!! Promised! Thanks. :)Pablo Santoshttps://www.blogger.com/profile/08083682682597484025noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-54328521588951061282010-08-06T01:18:19.751+02:002010-08-06T01:18:19.751+02:00I must say your product quality/polish is nothing ...I must say your product quality/polish is nothing short of impressive.<br /><br />What tool did you use for the image:<br /><br />http://2.bp.blogspot.com/_z6qpykplUvI/TFrDxOeBk5I/AAAAAAAAA1E/0XLmUJTJRBk/s1600/taskcycle.png<br /><br />Its clean/clear like your gui design.<br /><br />Very impressive.CastleSofthttps://www.blogger.com/profile/08066957979037057570noreply@blogger.comtag:blogger.com,1999:blog-27232680.post-11023784576478249052010-08-05T22:25:09.032+02:002010-08-05T22:25:09.032+02:00You should really uppercase 'dick':
"...You should really uppercase 'dick':<br /><br />"dick introduces a bug" turns out a bit ugly otherwise... (even though it might be true :)Anonymousnoreply@blogger.com