Subversion Branching and Merging. Jan Skalický

Transcription

1 Subversion Branching and Merging Jan Skalický

2 Changeset A collection of changes with a unique name The changes might include textual edits to file contents, modifications to tree structure, or tweaks to metadata In more common speak, a changeset is just a patch with a name you can refer to

3 Global revision number Global revision number N names a tree in the repository It's the way the repository looked after the Nth commit It's also the name of an implicit changeset If you compare tree N with tree N-1, you can derive the exact patch that was committed

4 Standard repository layout / Project1 trunk branches tags Project2 trunk branches tags

5 Creating a branch $ svn copy ^/proj/trunk ^/proj/branches/my-branch -m message Creates new branch my-branch in folder branches

6 Keeping a branch in sync Sync every time there are important changes in project s /trunk Keeping your branch in sync with the main development line helps prevent surprise conflicts when the time comes for you to fold your changes back into the trunk Sync: Commit all changes in branch test with $ svn status Merge changes from trunk $ svn merge ^/proj/trunk Resolve conflicts Commit

7 Revert Serious problems with merge => run $svn revert. -R It reverts all local changes It does not revert committed changes!!!

8 Reintegrating a Branch Parallel development has finished and we must merge changes back to the /trunk Process Make sure branch is up to date and all changes are committed Merge changes from trunk (see Keeping a branch in sync) Commit Switch working copy to /trunk $ svn switch ^/proj/trunk Reintegrate $ svn merge --reintegrate ^/proj/branches/my-branch Commit

9 Traversing branches svn switch command superset of the update command moves working copy through time and space (versions and directories) $ svn switch ^/proj/my-branch r 100

10 Cleaning Feature branches has ended and are already integrated back If we delete branch it is still in svn history We should delete these branches svn delete ^/proj/branches/my-branch -m message It is almost impossible to delete branch from history Branches can be resurrected svn copy ^/proj/branches/ 99 is number of revision in which my-branch was deleted

11 Merge tracking From release 1.5 Newer versions many bug fixes Helps merge command to recognize, what has been already merged Easy merging Uses property mergeinfo

12 Mergeinfo Property attached to files and directories Which changes have been merged to which branches Maintained by svn merge command How to examine property? $ svn propget svn:mergeinfo. How to find out what is already merged? $ svn mergeinfo ^/calc/trunk How to find out what has not been merged until now? $ svn mergeinfo ^/calc/trunk --show-revs eligible

13 Typical merging scenarios Release Branches Feature Branches

14 Release Branches Software life cycle: code, test, release, repeat Problems with this process New work cannot halt while the supposedly stable version of software is tested Team must support older, released versions of software Possibility to repair a bug in released versions Version control can help

15 Release Branches The typical procedure looks like this: 1. Developers commit all new work to the trunk changes are committed to /trunk: new features, bug fixes, The trunk is copied to a release branch When the team thinks the software is ready for release (say, a 1.0 release), /trunk might be copied to /branches/ Teams continue to work in parallel One team begins rigorous testing of the release branch Another team continues new work (say, for version 2.0) on /trunk If bugs are discovered in either location, fixes are ported back and forth as necessary At some point, however, even that process stops. The branch is frozen for final testing right before a release

16 Release Branches 4. The branch is tagged and released When testing is complete, /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot The tag is packaged and released to customers 5. The branch is maintained over time While work continues on /trunk for version 2.0, bug fixes continue to be ported from /trunk to /branches/1.0 When enough bug fixes have accumulated, management may decide to do a release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released

17 Feature Branches Temporary branches created to work on a complex changes without interfering with the stability of /trunk Life cycle: Branch is created Branch is used and continuously updated from trunk Branch is merged back to the trunk Branch is deleted

18 Feature Branches Approaches to feature branches Never use feature branches Simple method but /trunk is often unstable or unusable Use branch for each change Exceptionally stable but there is huge working overhead Middle-of-the-road approach Feature branch is required only when a change requires a large number of destabilizing commits Most projects use this approach

19 Questions Any questions?

20 End