Tue Aug 08 22:57:56 HKT 2017
Why merge often - http://queue.acm.org/detail.cfm?id=1643030
A lot of resource here - http://www.cmcrossroads.com[..]i-bin/cmwiki/view/CM/BranchingAndMerging
At my company, we tag each CVS module and we use those tags to build releases. That way, we know exactly which code versions each deployment has. Also, developers can check in code at any point while controlling when they release it.
Branches are a major headache, which I avoid whenever possible. You have to worry about maintaining and testing each branch, along with merging changes. I prefer to release the latest and greatest code to each customer. If different customers require different behavior, if statements and configuration files are a lot better than CVS branches.
Branches do make sense if you want to release a minor change to an old release, but upgrading the entire code base is risky. However, high-quality code and testing should reduce that risk.
Subversion branching technique and tips - http://binkley.blogspot.com[..]version-best-practices-branching_01.html http://www.dehora.net[..]version_tips_dealing_with_branches.html/
Another discussion - http://www.codinghorror.com/blog/archives/000968.html
Branch visualization - http://codicesoftware.blogspot.com[..]07/05/linus-torvalds-on-git-and-scm.html http://www.youtube.com/watch?v=CABIi-Eu2zA
One way of manage branching and merging, the summary is, frequency create new branch for pre-merge instead of one time big merge - http://designbygravity.wordpress.com[..]old-you-about-svn-branching-and-merging/ My colleagues suggest subversion merge tracking can solve the problem without that pre-merge, but I am not sure how that can work... http://blogs.open.collab.net/svn/2007/09/what-subversion.html
No branch? https://cacm.acm.org[..]-of-code-in-a-single-repository/fulltext http://www.infoq.com[..]s/2017/08/How-Google-build-Web-framework
(google search) (amazon search)