1 / 27

ClearCase Branching, Labeling, and Building

ClearCase Branching, Labeling, and Building. High-Level and Low-Level Branching. High-Level Branching Main branch. Release branch. Emergency branch. Low-Level Branching CR branch. User CR branch. Rapid development branch User rapid development branch. High-Level branching.

breena
Download Presentation

ClearCase Branching, Labeling, and Building

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ClearCase Branching, Labeling, and Building

  2. High-Level and Low-Level Branching High-Level Branching • Main branch. • Release branch. • Emergency branch. Low-Level Branching • CR branch. • User CR branch. • Rapid development branch • User rapid development branch.

  3. High-Level branching • Branch only when necessary. • Branch late. • Emergency change on release branch. • Specific customer changes on new release branch. • Keep propagation under control.

  4. One release line per major version • Isolate logically distinct efforts. • Each branch has a logical coherent purpose. • Easy to automate process. • Easy to verify. • Easy to understand.

  5. One release line per major version mainline sw8 line /sw8sp2 /sw9 /sw9sp1

  6. Each release is a branch /main /sw8 /sw8sp1 /sw8sp2 /sw9 /sw9sp1

  7. Cumulative ECN on the same branch /main /sw8 Development 8.02-GA ECN001 Maintenance ECN002

  8. Non cumulative ECN on a specific branch /main /sw8 8.02-GA /ecn003 ECN003 ECN001 /ecn004 ECN002 ECN004

  9. Branch only when necessary and late. • Purpose: • Reduce number of merge and propagation. • Do not pollute the tree version. • Solution: • Wait until new release branch is needed. • Do not create a branch on each element, only on changed elements. • For a particular release branch create all logical previous branches.

  10. Branch only when necessary and late. Item modified for each release, each branch are existing.. /main 0 /sw8 0 1 8.02-GA /sw8sp1 0 8.02-SP1-GA 1 /sw8sp2 0 8.02-SP2-GA 1

  11. Branch only when necessary and late. Item modified for 8.02, not for 8.02SP1, branch sw8sp1 does not exist. /main 0 /sw8 0 8.02-SP1-GA 1 8.02-GA

  12. Branch only when necessary and late Item modified for 8.02 release, not for 8.02SP1, then later for 8.02SP2. Sw8sp1 and sw8sp2 branches has been created at the same time. /main 0 /sw8 0 8.02-GA 1 /sw8sp1 8.02-SP1-GA 0 /sw8sp2 1 8.02-SP2-GA 0

  13. Branch only when necessary and late Item modified for 8.02 release, and for ECN 001, later 8.02SP1 has been created without specific change, sw8sp1 branch does not exist. /main /sw8 8.02-GA 8.02-SP1-GA ECN001

  14. Branch only when necessary and late Item modified for 8.02 release, and for ECN 001, not for 8.02SP1, then a 8.02SP1 ECN has been implemented. /main /sw8 8.02-GA 8.02-SP1-GA /sw8sp1 ECN001 ECN002

  15. Branch only when necessary and late Item modified for 8.02 release, ECN 001, between ECN 001 and 8.02SP1 a change specific 8.02SP1 has been implemented. /main /sw8 8.02-GA ECN001 /sw8sp1 8.02-SP1-GA

  16. Low-Level branching • Branch only when necessary and late. • One branch per CR. • Merge in major branch with another environment, then unit test. • Keep merges under control.

  17. One branch per CR. • Changes are isolated. • No impact on other developers. • No impact on integration. • Going back before merge is made easily. • Integrate only changes made for the CR.

  18. One branch per CR. Each change request has a branch. This branch exists only for modified items, then it is merged back to the major branch. /main 0 sw8 0 cr0002 cr0001 0 0 1 1 CR0001 1 CR0002 2

  19. Merge only changes made for the CR main sw8 • Purpose: • Developer merges only his change. • Don’t propagate changes from another CR. cr11000 CR11000 cr12000 = CR1100 Merge only these changes CR12000 Unit tested

  20. Merge on major branch in another environment, then unit test. main • Purpose: • Avoid forgotten private files. • Avoid forgotten checkins. • Avoid wrong merges. • Avoid wrong labels. • Solution: • Set an integration environment according to the CR. • Merge from cr branch latest. • Unit test. • Check in. • Lock cr branch and label. sw8 cr12000 CR12000 Unit tested

  21. Keep merges from cr branch to major branch under control. Trivial merge: from cr121110 to sw8 Non-trivial merge: from cr13000 to sw8 main main sw8 sw8 cr12000 cr12000 cr13000 • Purpose: • Do not accept automatic merge for a non-trivial merge. • Merge early. • Solution: • Trivial merge can be automatic. • Non–trivial merge must not be automatic. • Changes on major branch are accepted automatically. • Changes on cr branch must be integrated by hand.

  22. Emergency change on release branch. EECNxxx on SW8.02 release. main sw8 cr12000 • Purpose: • Branch are not duplicated. • Same process as release branch. CR12000 SW8.02 cr13000 EECNxxx CR13000

  23. Specific customer changes on new release branch. Specific ECNXXX on SW8.02 release. main sw8 cr12000 • Purpose: • Isolate specific customer changes. • Same process as release branch. • Be careful: • Integrate this specific branch into a normal release branch as soon as possible. • Limit the number of these branches and their live. CR12000 SW8.02 sw8ecnXXX sw8sp1 SW8.02_SECNxxx SW8.02SP1

  24. Propagate only when necessary. CR12000 is for all releases, sp1 and sp2. CR13000 is SP1 specific. • Sp2 branch does not exist • Sp2 branch exists main main main sw8 sw8 sw8 sw8sp1 sw8sp1 sw8sp2 sw8sp1 sw8sp2 CR11000 CR12000 CR13000 CR12000 Child 12000 • Do not propagate CR12000, sw8sp2 branch does not exist, even if sp2 release exists. • Propagate CR12000, because next release branch exists. • Propagate only changes made for 12000 CR. • Changes must not appear in sw8sp2, don’t propagate sw8sp2. • Purpose: • Reduce number of propagation.

  25. Keep propagation under control. on CR branch • Purpose: • Changes are isolated. • No impact on other developers. • No impact on integration. • Solution: • Propagate as soon as possible. • Set an environment according to the child CR. • Merge from the major branch of the parent CR. • Then handle the child CR as a normal CR. main sw8 sw8sp1 Child 12000 CR12000 Child 12000

  26. Cumulative ECN on the same branch /main /sw8 Development 8.02-GA /sw8sp1 ECN001 8.02-SP1-GA Maintenance ECN002 ECN002

More Related