Ca va ENCORE parler de bits!

2014-01-27  |  Tips 'n' Tricks  |  project management repositories svn

Initially, a business is like any other. It comes from the phenomenon of "start-up" or a matured idea. It seeks its place Upsets concurrency when there are and often starts as a bomb under the impulse of joy and novelty. Strong competition and lower prices for the hardware development allows companies who wish to conquer new market to equip in material quickly and easily. It was the same for the workforce. Number of students passionate ready to sweat water and blood to prove their capabilities and their mastery of the virtual world.

But it goes without saying that only the well-organized business and master of their efforts experiencing stable growth. To do this, in the context of an IT project, it is essential to establish a quasi-industrial system. This saves time and not losing (Hoo My F****** God I Used "rm *" ! [I know you know]).

Of course, this tutorial "Tips & Tricks" is just one example but it can proves useful in the context of a single project website. Then let your instincts do the rest ;-)

Well, now that we begin the technical part. You should know that to industrialize an IT project must define test points on your assembly line. The most frequent model is as follows: 

  • Distribution, the project being sold or online version of avaialble for your client. 
  • The quality assurance, a position that provides a test phase in depth. 
  • The beta is here that the developers pooling their development efforts.
We will build this assembly line. Go, it starts!
Note : If your are looking to install your SVN server, look at this page gist.github.com/42antoine.
 

First, checkout your empty SVN.

1.png
 

Create "trunk", "tags" and "branches" directories

and commit them on you repository. If you already get "trunk", "tags" and "branches" directories jump this step.

2.png
 

Now we will create branch dependencies

To build our branch infrastructure, we will use "svn copy". This will create a copy of the branch we choose and create a relationship. Each child branch will later merge its content into its parent.

3.png
 
Well, thanks to these first manipulation we design our architecture file. Now we have a trunk directory that has a daughter qa branch (in the same way, you can create branches you want).
Finally. We will create the branch for development too.
 
$> svn copy svn+ananas://antoine@192.168.0.2/home/repositories/svn/example/branches/qa \
svn+ananas://antoine@192.168.0.2/home/repositories/svn/example/branches/beta \
-m "The dev branch."

Although we ended architecture for folders.

 

The daily use

The approach is simple. Each developers will checkout development branch ("beta"). They will work on and communicate together about what they will commit.

For example: Peter, Paul and Jacque working together on a project. 
 
They all work on a personnal checkout of beta branch and they are working on an assigned task.
Peter ends his task the first.
  • He will update his repo to check if there is no conflict with previous version and others commitments.
    $> svn up
  • He will warn both camarrades to inform them he push file to quality assurance environment.
  • He will commit his work with a clear message.
    $> svn commit -m "#taskNumber : That do the job!"
  • He will note the version number of the commit ("Committed revision 14.")
  • Next, he will go into the quality assurance directory, to merge files at the right revision.
    $> svn merge \
    svn+ananas://antoine@192.168.0.2/home/repositories/svn/example/branches/beta@14 \
     . 
  • And finally commit quality assurance change with a new clear message.
    $> svn commit -m "#ticketNumber : Now that do the job in quality assurance!"

Paul and Jacque have to follow the same process to commit in quality assurance branch.

 

What's happen in the quality assurance branch?

This branch have to be linked to a copy of the distribution environement. This space will allow quality assurance manager to make test and validate new product process. This step is no longer about the software code but only the "client" result. The new feature could be :

  • Accepted (to pass to distribution), in trunk directory we simply merge the right revision
    $> svn merge \
    svn+ananas://antoine@192.168.0.2/home/repositories/svn/example/branches/qa@15 \
     . 
    $> svn commit -m "#taskNumber : QA passed, go to Trunk."
  • Refused (back in development), in the quality assurance we will merge back all files.
    $> svn merge -rCURRENT_REVISION:OLD_REVISION \
    svn+ananas://antoine@192.168.0.2/home/repositories/svn/example/branches/qa/path/to/file \
     ./path/to/file 

 

And after the trunk, nothing more?

Now we have the latest revision in the trunk. But sometime, an IT product could not be sell each time to the latest revision. By example, for desktop software we have to propose software release.

To make release with SVN, it is as simple as copy. We will copy the trunk in the "tags" directory like following:

$> svn copy svn+ananas://antoine@192.168.0.2/home/repositories/svn/example/trunk \
svn+ananas://antoine@192.168.0.2/home/repositories/svn/example/tags/v0.1.500 \
-m "Fix software to version 0.1.500."

Now you only have to export this tags and make your distribution process.

 

Resources

Basic merging
Basic SVN Commands
Topic : Merging a branch back to the trunk Common Use-Cases from Subversion Book - CollabNet Community SVN book by red bean
TortoiseSVN (Windows UI for SVN)
TortoiseSVN (Mac UI for SVN)

 


Share this article :

blog comments powered by Disqus

© 2012-2017 Ca va ENCORE parler de bits! All Rights Reserved.