Summary


In the "Primary Releases" section, we discussed using share and pin, branch, label, and clone to create new kinds of releases. In general, I recommend branching only when creating new minor releases. You must decide which technique to apply in different instances, but the guidelines in this chapter should offer a good foundation for those decisions. It's often worthwhile to use a combination of techniques.

You might want to decide which technique to use for creating new releases on a subsystem-by-subsystem basis. Visual Studio .NET encourages an approach to development in which a .NET source project is used to contain a subset of related functionality, or a subsystem. It is likely for new release versions that some subsystems will remain unchanged, whereas others will change significantly. In cases like this, the recommendation is to share and pin the subsystems that require no changes and either branch or clone the subsystems that are expected to change the most. If you discover changes in pinned subsystems, branch only the files that require changes. This keeps excessive branching and merging to a minimum.

Furthermore, choosing the right technique takes the burden off individual developers to keep accurate track of files that are shared and pinned. Because you cannot check out pinned files, developers have to complain to the designated release manager if they try to modify a file in a subsystem that is not expected to change. After the release manager approves the file, he can unpin or branch it as needed.



The Build Master(c) Microsoft's Software Configuration Management Best Practices
The Build Master: Microsofts Software Configuration Management Best Practices
ISBN: 0321332059
EAN: 2147483647
Year: 2006
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net