Subversion User Training Branching & Merging Author: Polarion Software E-Mail: info@polarion.com Web: http://www.polarion.com

Why do I need branches? Merging with subversion Different branching strategies Dangerous merging Do’s and dont‘s

Why do I need branches?

Why do I need branches? What is a branch? A branch is ... + independent line of development, sharing a common history with other lines a branch starts always a copy of a specific folder/file branch + svn cp trunk time

Why do I need branches? Who needs branches? 3 kinds of SVN users: svn add/delete svn checkout svn status svn commit svn update svn log SVN !! svn cp svn switch svn propset svn propget svn proplist SVN svn merge svn mergeinfo No need for branches (yet!) branching and merging support needed branching strategy needed

Why do I need branches? code stability release preparation traceability (integration of change/defect management) increasing complexity parallel development research support different platforms

When not to use branches? Why do I need branches? When not to use branches? Never use branches for: multiple project support of your software product will lead to maintenance hell!

Merging with subversion

Merging with subversion a merge will always apply a “patch” to a workingcopy a patch is always a difference between two versions/trees in this sample below we create the patch between revision 4 and 7 6 7 6 7 4 branch branch 4 merge 8=6+7 2 3 5 8 5 8 trunk (wc)‏

Merging with subversion Reintegrate branch

Merging with subversion Reintegrate branch reintegrate branch will keep track of all previous merged revisions and will not try to merge them back conditions apply: no switched working copy If revisions from trunk have been merged to the branch If so, make sure we've merged contiguously (so example below will only work if either no revision, 5 or both 5 and 7 have been merged to the branch)‏ featurebranch 6 9 4 6 8 9 10 8 10 branch 11=6+9 4 merge 3 trunk (wc)‏ 11 5 7 5 7

Merging with subversion Cherry picking choosing specific revisions to merge no need for continous range mergetracking avoids double merges you need interactive conflict resolution, if first rev. causes a conflict 6 8 9 10 featurebranch 4 6 8 9 10 branch 11=8+10 4 merge 3 trunk (wc)‏ 11 5 7 5 7

+ + Merging with subversion ignore ancestry X ancestry means two object share same history as SVN supports deletion of files, filenames are no indication for ancestry on merge two files which share same name, but are not ancestors files will not be merged, but replaced Vendor branches may depend on „ignore ancestry“ + A A X 3 5 7 replaced! + A A 1 2 4 6 8 9

Merging with subversion ignore white spaces SVN will not merge changes in amount of whitespaces (>>) def increment(x): >> if type(x)==type(1): >> >> x+=1; >> >> if x>10: >> >> >> print „max reached!“ >> >> >> x=10 >> return x def increment(x): >> x+=1; >> if (x>10): >> >> print „max reached!“ >> >> x=10 >> return x def increment(x): >> if type(x)==type(1): >> >> x+=1; >> >> if x>10: >> >> >> print „max reached!“ >> >> >> x=10 >> return x

Merging with subversion Tree conflicts SVN cannot rename files/folder SVN will delete old file and add new file with deleted file as ancestor Prior to svn 1.6 merging was difficult and dangerous, if renames occurred on branch avoid renaming on branches to avoid tree conflicts

Merging with subversion Tree conflicts 1/3 Demonstration of a tree conflicts : create a project (trunk) with 1 file named „readme.txt“: first line. This is initial some Text Alice: there is a last line but not here. bob added a new line here.. Alice: this is the last line.. create a branch called „dangerous_merge“ check out branch and append a single line to readme.txt: appending a new line at the end in branch commit changes to branch

What do you expect? Merging with subversion Tree conflicts 2/3 in trunk: insert a new 1st line of text to readme.txt: *** This is the line added in trunk *** commit these changes as well. in branch: rename readme.txt to readme2.txt and commit in trunk: merge last 2 revisions from branch into trunk What do you expect?

Why? Merging with subversion Tree conflicts 3/3 In SVN 1.6 you get a „tree conflict, prior to SVN 1.6 the content of „readme2.txt“ was: first line. This is initial some Text Alice: there is a last line but not here. bob added a new line here.. Alice: this is the last line.. appending a new line at the end in branch Changes from trunk just vanished! Why?

Merging with subversion Tree conflicts readme.txt: *** This is the line added in trunk *** merge trunk branch readme.txt: appending a new line at the end in branch copy readme.txt readme2.txt delete readme.txt

Different branching strategies

Different branching strategies unstable vs. stable trunk 2 different kind of branching strategies: unstable trunk (late branching) stable trunk (early branching)

Different branching strategies unstable trunk you always commit into trunk. sometimes developer branch to develop features trunk shows always the current development state Releases: maintain a branch feature freeze on this branch fix bugs prepare release Feature X Bugfix A Bugfix A Release 1.1 trunk Release 1.0

Different branching strategies unstable trunk PRO easy to understand easy to maintain good overview of development status very few merges needed CON no traceability of codeartifacts no removal of features risky parallel development broken builds user will prevent commits complex defect analysis more conflicts seldom updates

Different branching strategies stable trunk you never commit directly to trunk you always merge from branches to trunk you need at least one specific branch strategy Releases: releases are always revisions on trunk Feature X Bugfix A trunk Release 1.0 Release 1.1

Different branching strategies stable trunk PRO feature is a single commit on trunk easy removal of features trunk always builds user can work on parallel tasks enhanced traceability conflicts only while integration base for most branching strategies CON complex concept maintainer needed overkill for small projects(?) difficult to get overview good versioning skills needed

Different branching strategies Feature (Task) branches Developer (Private) branches Bugfix (Task) branches Release branches Platform branches Experimental branch Vendor branches* *) Vendor branches are not a branching strategy,, but a development tool

Different branching strategies Feature branch implementation of a single feature single feature will be inserted into project exactly in 1 commit (rev. 8) undoing feature is easy Feature branch 3 5 7 1 2 4 6 8 9 trunk

Different branching strategies Developer branches each developer maintain his own branch tasks will be merged back by project lead developer (rev. 8) very stable trunk (is only writeable by project lead) developer must maintain branch by merging new revisions (rev. 4)(notifications!) Developer branch 3 5 7 merge 1 2 4 6 8 9 trunk

Different branching strategies Bugfix branches implementation of a single bugfix bugfix will be inserted into project exactly in 1 commit (rev 8) undoing feature is easy similar (equal) to feature branches, but usually smaller bugfix branch 3 5 7 1 2 4 6 8 9 trunk

Different branching strategies Release branch Release branch ends on release Code stabilization Bugfixes on release branch will be merged back to trunk No new features on release branch Release branch Release 1.0 3 5 7 Bugfix 1 2 4 6 8 9 trunk

Different branching strategies Platform branches Platform branches are living „forever“ You will alway have at least 2 platform branches branches are usually not very active, just receiving merges from trunk Platform branch WIN 4 7 Platform branch UX 3 6 1 2 5 8 9 trunk

X never! Different branching strategies Experimental branch Experimental branches are for testing different scenarios similar to developer branches without merge back you should not merge back into trunk! merge from trunk to keep experiment up-to-date should be deleted after getting results Experimental branch 3 5 7 X never! 1 2 4 6 8 9 trunk

+ + Different branching strategies Vendor branches Vendor branches are modified 3rd party code you keep a modified version of 3rd party code in /current/ folder (rev. 5) on new releases the changes between releases will be merged into trunk (rev. 7) + importing Vendor branch V2.0 + importing Vendor branch V1.0 2 merge delta V2.0 – V1.0 Vendor branch current (modified) 3 5 7 1 4 6 8 trunk

Summary & Appendix

Do’s and dont‘s Summary & Appendix Do’s define your branching strategy before start developing key part of a branching strategy should be a naming convention for branches describe integration with bugtracking / CM / PM Tools try to think of a merging concept, not a branching strategy define most important parts of merging process: TESTS unit test integration test system test change your branching strategy as soon as you experience problems merge only root of branch, do not merge subdirectories separately merge only to working copies without local modifications be careful with renames on branches

Do’s and dont‘s Summary & Appendix avoid Merge Paranoia — avoiding merging at all Merge Mania — spending too much time merging instead of developing Big Bang Merge — deferring branch merging and attempting to merge all branches Never-Ending Merge — continuous merging activity Wrong-Way Merge — merging a software asset version with an earlier version. Branch Mania — creating many too branches Cascading Branches — branching but never merging back Mysterious Branches — branching for no apparent reason. Temporary Branches — branching for changing reasons, so the branch becomes a permanent temporary workspace. Volatile Branches — branching with unstable software assets shared by other branches Development Freeze — stopping all development activities while merging Berlin Wall — using branches to divide the development team instead of work

Summary & Appendix Polarion TRACK & WIKI Get your free copy today!

Summary & Appendix Online resources http://subtrain.tigris.org http://www.brianlegros.com/blog/2007/10/12/ http://www.cmcrossroads.com/bradapp/acme http://subversion.apache.org http://svnbook.red-bean.com/ http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

Any Questions?

Please visit our website for more information www.polarion.com Thank You!