RSS feed [root] /SCM /weblog /software_engineering



title search:


Tue Aug 08 22:57:56 HKT 2017


Why merge often -[..]/cgi-bin/cmwiki/view/CM/BranchYesMergeNo

A lot of resource here -[..]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.[..]arent=16312&ixDiscussGroup=3&cReplies=11

Subversion branching technique and tips -[..]version-best-practices-branching_01.html[..]version_tips_dealing_with_branches.html/

Another discussion -

Branch visualization -[..]07/05/linus-torvalds-on-git-and-scm.html

One way of manage branching and merging, the summary is, frequency create new branch for pre-merge instead of one time big merge -[..]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...

No branch?[..]-of-code-in-a-single-repository/fulltext[..]s/2017/08/How-Google-build-Web-framework

(google search) (amazon search)
download zip of files only