Subversion

Subversion Tricode Professional Services www.tricode.nl 22-08-2008 Patrick van Dissel

Index What is Subversion (SVN)? Subversion features Repository based versioning Metadata Properties Distinction Between Status and Update Conflict Resolution Updates and Commits are Separate Standard project structure Development/Release workflow Tips

An improved version of CVS Uses a filesystem tree; everything works the same way, everything is versioned (files, directories, renames, deletions, properties, …) Branches and Tags work exactly the same as the Trunk, everything has it’s place in the repository filesystem tree Repositories/Modules can connect to each other, like a symbolic-link in a *nix filesystem A revision contains a complete state of the repository filesystem tree Minimized network traffic only connects to the repository when really needed tranfers are based on differences between versions instead of sending whole files What is Subversion (SVN)?

Terms of how they improve upon CVS's design Directory versioning CVS only tracks the history of individual files, but Subversion implements a “virtual” versioned filesystem that tracks changes to whole directory trees over time. Files and directories are versioned True version history Since CVS is limited to file versioning, operations such as copies and renames—which might happen to files, but which are really changes to the contents of some containing directory—aren't supported in CVS. Additionally, in CVS you cannot replace a versioned file with some new thing of the same name without the new item inheriting the history of the old—perhaps completely unrelated—file. With Subversion, you can add, delete, copy, and rename both files and directories. And every newly added file begins with a fresh, clean history all its own Versioned metadata Each file and directory has a set of properties—keys and their values—associated with it. You can create and store any arbitrary key/value pairs you wish. Properties are versioned over time, just like file contents Subversion features (1)

Terms of how they improve upon CVS's design Atomic commits A collection of modifications either goes into the repository completely, or not at all. This allows developers to construct and commit changes as logical chunks, and prevents problems that can occur when only a portion of a set of changes is successfully sent to the repository Consistent data handling Subversion expresses file differences using a binary differencing algorithm, which works identically on both text (human-readable) and binary (human-unreadable) files. Both types of files are stored equally compressed in the repository, and differences are transmitted in both directions across the network Efficient branching and tagging The cost of branching and tagging need not be proportional to the project size. Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations take only a very small, constant amount of time Subversion features (2)

Repository based versioning A revision contains a complete state of the repository filesystem tree Revision numbering => CVS uses file based versioning, SVN uses repository based versioning. Metadata properties svn:ignore *.tmp svn:ignore ~* svn:keywords Id rev.2 svn:ignore *.tmp svn:keywords Id rev.1

Metadata Properties CVS uses .cvsignore files containing patterns of files/directories to exclude from CVS. In SVN, every file and directory can have metadata properties. SVN recognizes the following special properties but will store any arbitrary properties set: svn:ignore svn:keywords URL, HeadURL Author, LastChangedBy Date, LastChangedDate Rev, Revision, LastChangedRevision Id svn:executable svn:eol-style One of 'native', 'LF', 'CR', 'CRLF‘ svn:mime-type svn:externals svn:needs-lock If present, indicates that the file should be locked before it is modified Note: The svn:keywords, svn:executable, svn:eol-style, svn:mime-type and svn:needs-lock properties cannot be set on a directory. A non-recursive attempt will fail.

Metadata Properties – Usage (1) svn:ignore A newline separated list of file patterns to ignore For example: svn ps svn:ignore * cache This excludes all files within the cache directory from adding to SVN. Files still can be added by specifically adding them svn:keywords Keywords to be expanded (case-sensitive!) For example: svn ps -R svn:keywords Id . This sets the ‘Id’ keyword on all files recursively from current directory. After this, ‘$Id$’ will be replaced at commit with information of the last modification and looks something like: $Id: calc.c 148 2006-07-28 21:30:43Z sally $

Metadata Properties – Usage (2) svn:externals A newline separated list of module specifiers For example: Zend http://svn.tri...work/tags/1.5.2-tricode/library/Zend/ Tricode http://svn.tri.../tricode/branches/1.1/library/Tricode/ This connects the Zend directory to the specified 1.5.2-tricode repository and the Tricode directory to specified 1.1 branch. When you update your whole project, the externals will also be updated . When you commit your while project, the externals will NOT be committed . Commits to externals must be done explicitly.

One of the fundamental rules of Subversion is that a “push” action does not cause a “pull”, nor the other way around. Just because you're ready to commit new changes to the repository doesn't mean you're ready to receive changes from other people And if you have new changes still in progress, then svn update should gracefully merge repository changes into your own, rather than forcing you to publish them Updates and Commits are Separate

svn status Shows only information about current working-copy without needing to connect to the repository. Unless you specify the -u option, then the reposity is contacted to recieve update information (files are not updated!) svn update Updates current working-copy to the latest/given revision and shows information about the files that are updated Distinction Between Status and Update

Steps for merging: Open the project/working-copy you want to merge changes to For merging the ‘trunk’ to ‘cycle18’ branche, you open the ‘cycle18’ branche and then execute the ` svn merge ` on the { trunk url } Make shure you have NO local modifications (`svn status`) Execute merge Solve conflicts & mark resolved Commit changes to complete merge Merging

{projectname} branches => specific development versions tags => released versions trunk => latest development version Naming convention For branches: YYYY-MM-DD_ I ##### YYYY-MM-DD_ RFS ### YYYY-MM-DD_ RFC ### YYYY-MM-DD_ cycle ## For tags: YYYY-MM-DD_ cycle ## Standard project structure

{projectname} branches 2008-08-18_ cycle 18 2008-08-19_ I 7654321 2008-08-19_ RFC 0012345 2008-08-19_RFC0022386 2008-08-19_ RFS 0012345 tags 2008-08-18_ cycle 17 trunk Standard project structure

Development/Release workflow FA TA Build UAT 1 week 1 week 1 week 1 week trunk (prod + incidents/rfs) GoLive After GoLive previous cycle Create cycle branch Merge to cycle Merge to cycle NOK Fix NOK RFC Branch Create branch per Change Build Changes Decide which Changes will go in the release Tag Clean branches

Development/Release workflow symbolic-link switcher cron Auto remove branches which are not in HEAD SVN revision symbolic-link trunk ../trunk ../b1 ../trunk ../b1 ../ixxx /virtual/{project} /virtual/{project} /virtual/{project} LIVE TEST DEV

Use JIRA issue keys in commit messages If a commit is resolving an issue from the issue tracker, the issue KEY should be indicated in the commit comment (i.e. "This resolves ZF-2 ") Enable SVN Auto-props in SVN client config Config can be found at: %UserProfile%\Application Data\Subversion\config Set the following in the config: enable-auto-props = yes [auto-props] *.php = svn:keywords=Id Tips

Subversion

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Subversion (20)

More from Tricode (part of Dept) (20)

Recently uploaded (20)

Subversion