Archive for October, 2008

I’m sure that tons of flex developers has already used SVN during the development of their projects but I have seen sometimes great difficulties when during the development of a project different coders need to modify the same file or add a file to a project. In the first situation the way to handle merge is not really intuitive, in the second one most of the times the file is not committed.

For this reason I decided to write some notes on SVN and TortoiseSVN 1.5.4 that has been recently released.

First of all please be sure to use a sane repository layout. There are many ways to lay out your repository. Because branches and tags are ordinary directories, you’ll need to account for them in your repository structure. The Subversion project officially recommends the idea of a “project root”, which represents an anchoring point for a project that contains exactly three subdirectories: /trunk, /branches, and /tags.

“trunk” is supposed to signify the main development line for the project. You could call this “main” or “mainline” or “production” or whatever you like.

“branches” is obviously supposed to be a place to create branches. People use branches for a lot of purposes. You might want to separate your release or maintenance branches from your feature branches or your customer modification branches etc.

“tags” are not treated as special by Subversion either. They are a convention, perhaps enforced by hook script or authoring rules, that indicate you are creating a point in time snapshot. Typically the difference between tags and branches is that the former are not modified once they are created. You might call your tag folders “releases” or “snapshots” or “baselines” or whatever term you prefer.

Be sure to Commit logical change set. When you commit a change to the repository, make sure your change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. Your commit will create a new revision number which can forever be used as a “name” for the change. You can mention this revision number in bug databases, or use it as an argument to SVN merge should you want to undo the change or port it to another branch.

Merging changes sounds simple enough, but in practice it can become a headache. The problem is that if you repeatedly merge changes from one branch to another, you might accidentally merge the same change twice. When this happens, sometimes things will work fine. When patching a file, Subversion typically notices if the file already has the change, and does nothing. But if the already-existing change has been modified in any way, you’ll get a conflict.
Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible. Unfortunately, Subversion is not such a system. Like CVS, Subversion 1.0 does not yet records any information about merge operations. When you commit local modifications, the repository has no idea whether those changes came from running SVN merge, or from just hand-editing the files.
What does this mean to you, the user? It means that until the day Subversion grows this feature, you’ll have to track merge information yourself. The best place to do this is in the commit log-message.

Let’s take a look to a practical Flex development situation, first of all you have to install Tortoise SVN on your machine and create an empty folder for your project (I’m supposing that you have already started to work on some stuff and that is the time to go under source control and that you are the one that will create the repository).
Right click on the folder and select the import option

In the dialog that appears insert the data for the remote repository

Right click again and perform the check out, now your folder is synchronized with the remote repository.
Copy the files you need in the folder and perform a commit, you’ll be prompted to select the files you want to commit

It’s a good habit to remove properties, project, bin-debug, bin-release, etc. in order to perform this task you can deselect the files from this dialog or you can select a specific file, right click and remove it or all the files with the same extension from the synchronization of the repository

Now you are able to work quite easily with SVN but remember that

·         in order to rename a file or a folder you must first checkout the file or folder to your machine. Once it’s on your machine, right-click on the file or folder, and select the menu option SVN Rename,

·         in order to delete a file or folder, simply right-click on it, and select the Delete… option from the Tortoise SVN menu

·         to add a file or folder, check out the repo (if you haven’t already done so). move the new file(s) and folder(s) to the location you want them in the repository (for e.g. to add the file newfile.mxml to the mxml/trhunk/newclient/ folder, move newfile.mxml to that folder). Now, with everything in its place, right-click on the file(s) and folder(s) you want to add to the repository, and select the SVN Add… menu option

Basically all the usual operations of an operating system needs to be performed trough the Tortoise SVN contextual menu.

SVN is not a back-up system, is a way to handle versioning and conflict, what happens if you make some changes to a file and another developer make the changes to the same file and both of you make a commit at the end of your working day?
SVN will try to make a merge but sometimes it’s not possible so be careful when you do the commit and use the Check for modifications function from the Tortoise SVN menu option

If something goes wrong during the merge you’ll keep your work safe because in the file you are committing SVN will add the change log in the code

<<<<<<< .mine
                var beautiful:int = 5;
=======
                var ugly:int = 5;
>>>>>>> .r10

and in your folder you get a copy of the file with the release name.
I wasn’t a fun of SVN the first time I used but now I am happy to say “It works!”.

Resources
http://electricjellyfish.net/garrett/talks/oscon2004/svn-best-practices/
http://blog.evanweaver.com/articles/2007/08/15/svn-branching-best-practices-in-practice/
http://www.iovene.com/5-svn-best-practices/
http://svnbook.red-bean.com/en/1.4/svn.tour.cycle.html
http://www.changelogic.com/SvnProjectSetup
http://svnbook.red-bean.com/en/1.0/ch05s04.html#svn-ch-5-sect-6.1