Svn Basic Tutorial

SVN BASIC TUTORIAL Formatvorlage des Untertitelmasters Avoiding headaches ™ durch Klicken bearbeiten

Direct deploy Developer 1 Staging Live Developer 2 Staging Live Designer 1 Staging Live Designer 2 Staging Live

Removal of direct deploy Developer 1 Staging Live Developer 2 Staging Live Designer 1 Staging Live Designer 2 Staging Live

Why not to directly deploy • Can’t check the status of the environment • Race conditions (DEV1 and DEV2 work on a same file => collisions) • Can’t easily update the environment (full replace of the entire working copy needed)

SVN • Subversion (SVN) is a SCM (Software Configuration Management) implementation • It allows to track changes in files and directories • It allows concurrent development on the same files • It is centralized (one server)

SVN Interaction Designer 2 Designer 1 Staging Server Developer 2 Issue Tracker Developer 1 SVN Server Production Server

SVN development cycle Get last project status from SVN server Send work to SVN server Develop/Design Test

SVN development (in SVN terms) svn update svn commit edit files Test

How it works Will make some examples with TortoiseSVN and the command line to explain SVN

Fetching an existing project The «.svn» directory is used by subversion to keep track of changes in the current directory tree. Do not change it, copy it somewhere else or delete it!

Adding some files to the project

Deploy with SVN When having SSH access to a server, deploying and updating becomes as easy as: $ ssh user@server.com $ cd path/to/project $ svn update (Or "svn co" if the project is not yet deployed)

Merging and conflicts In the following schema, two developers try to commit changes to a same file: echo ‘hello to’; Developer 1 echo $username; echo ‘hello world ’; Developer 2 echo $_GET[‘username’]; RED = changed by developer

How merging works When Developer 2 tries to commit, SVN will tell him that his copy is outdated, he will have to update it

How merging works Merging won’t cause any changes on the server, you will first get all the changes locally, so that you can review them. Here’s the result of this merge case: We can then $ svn commit -m "Merged changes of marco’s commit"

Merging workflow svn commit Developer verifies merge Can’t commit (outdated working copy) svn tries to merge svn update

What if SVN can’t merge? svn commit SVN couldn’t merge Can’t commit (outdated working copy) ???????? svn tries to merge svn update

SVN Conflicts SVN conflicts happen when two developers act on a same file in the same line: echo ‘hello everybody’; Developer 1 echo $_GET[‘username’]; echo ‘goodbye everybody’; Developer 2 echo $_GET[‘username’]; RED = changed by developer

SVN Conflicts • index.php is a merged view of the conflict: • • index.php.r8 is the version before the update • index.php.r9 is the version as in SVN server • index.php.mine is the version you had in your directory before committing

SVN Conflicts We can edit the files until all conflicts are solved, then tell SVN it should accept our new working copy:

SVN Conflicts svn commit Mark conflicts as resolved Can’t commit (outdated working copy) Manually edit conflicts svn update SVN couldn’t merge svn tries to merge

SVN branching Main project Next major version update The main project and it’s features Bugfix for a known bug Keeps track of changes to be merged into the next major release of the software New feature that has to be added Work in progress to fix a known bug Alternate version to show to the customer A new feature that requires some work without being influenced b A slightly different version of the site that t

This is actually how git-flow by nvie.com handles development, but SVN could also use it!

What is a branch? In SVN terms, a branch is just a copy of a current tree. Let’s create a branch to develop an alternate layout for the site: svn copy -m “creating green site dev branch” svn://path/to/repo/trunk svn://path/to/repo/branches/wide-layout (in TortoiseSVN it is under “branch/tag” in context menu)

Switching working copy Given that you checked out: svn://project/path/trunk You can now switch to a branch by doing svn switch svn://project/path/branches/red and you will be working on that copy

Merging branches Once completed developing on a branch, you may want to merge changes back:

Merging branches Like normal conflict merging!

First you switch to the branch you want changes to be merged to: $ svn switch svn://path/to/target/branch

Then you merge a set of revision from the branch you developed on (here 25 to latest): $ svn merge -r25:HEAD svn://path/to/merged/branch

Then SVN will merge any conflicts or set conflicted state and allow you to check what happened. After fixing conflicts: $ svn ci -m “merging changes from new-layout branch”

Tags Tags are markers used for deployment, mainly for major release versions:

Tags Tags are copies, exactly like branches: $ svn copy -m “tagging version 1.1 of the project” svn://path/to/project svn://path/to/tags/1.1 Except that you NEVER commit on tags!

svn:externals Externals are “links” to other repositories: $ svn propset svn:externals “css/common svn://company/common/css/files” ./ Externals are not part of the repository, they are just fetched with the repository (useful for deploying applications!)

Update your projects before working

Do not commit broken code/functionality! (Test before committing if possible!)

Commit as soon as a piece of the functionality is completed

Branch life should not be too long Long living branches increase merge conflicts! This forces you to keep small units of work

Every commit should have a purpose. Commits with no purpose to be avoided! If possible, avoid multiple commits on separate files being part of one functionality

Never commit generated code/data! Generated code can produce dozens of useless commits, conflicts and generally, headaches!

EVERY COMMIT MUST HAVE DESCRIPTION

Examples of BAD commit messages: - “Fixed bug” - “Updated” - “Saved work” - “Updating” - “Merging changes” - “Saving work of 10/3/2010”

Examples of GOOD commit messages: - “Adding CSS definitions needed to create a lightbox overlay when focus is on the offers iframe” - “Fixed bug with session expiring after browser restart on IE7” - “Updated the logo with the new colors provided” - “Adding interfaces for the new blog feature The interfaces are still quite lightweight, but should be refreshed in the next days” -

If using an issue tracker (Jira, Trac, Bugzilla, Redmine, etc.), write the issue ID in the commit message: «Fixed iframe width causing scrollbars to appear when not needed as of PRJ-123»

Update working copy Build (test first) If there’s errors, fix them first! (do not work on broken projects) Develop Test changes Commit (with appropriate message) Resolve conflicts immediately

Svn Basic Tutorial

More Related Content

What's hot

Viewers also liked

Similar to Svn Basic Tutorial

Recently uploaded

Svn Basic Tutorial

Editor's Notes