Source Control Management 201 - Repository Design for efficient code management using any source control

Source control management is an essential part of the development. It should be just as critical part of the developer’s toolbox as a good text editor. There is no project that is small enough not to deserve one. There is no such thing as bad source control management system. While there are probably hundreds SCM systems out there, some are more user developer friendly then others. Some of the more common ones you hear about today are Subversion, CVS, Git, Visual SourceSafe, Rational ClearCase.

A goal of a source control system is to answer the following questions:

• What code is currently running in production?
• What is the latest code a developer should be looking at?
• What code was used to compile version X.XX.XXX?
• How can a developer make changes without affecting other developers?
• What changed between version X.XX.XXX and X.XX.XXY?
• How can a developer incorporate changes between X.XX.XXX and X.XX.XXY to make X.XX.XXZ?
• How can a developer rollback changes from X.XX.XXY to get back to X.XX.XXX?

All source control versions that I’ve worked with can answer all of the above questions. It does take some organizational skills on the developer to allow it to do so. SCM system stores code in a repository. It is up to the developer and SCM team to organize the layout of the repository. Some of the more common strategies are Trunk Focused

All development is done on the trunk. When the code is stable enough to be ready for QA/Production Testing it is brunched into a Beta/Release Candidate branch. The trunk version is incremented. The RC branch should have only minor bug fix related changes applied to it. All major changes are done in the trunk. As bugs are fixed in the RC branch, the changes are migrated into the trunk. When a version is released, the RC branch is moved into a Release branch. CHANGES ARE NEVER MADE IN THE RC BRANCH. IT IS READ ONLY! If a bug fix must be made to the already released version, a branch is created, and a change is done on the branch. The fix is then merged into the trunk.

This repository allows to easily answering developer’s question

• What is the latest code I should develop from: Trunk
• What code is currently running in production: Latest Read Only branch
• How to make changes to version X.XX.XXX: Make a new branch from the version X.XX.XXX. After finishing your changes, merge them into the trunk.

Another strategy is to organize the repository around production version.

Main trunk has the currently released production version. The trunk IS READ ONLY! For development, a branch is created, and development is done on the branch. After the version is released to production, the trunk is replaced with the copy of the released branch, and is again made read only. To develop the next version, another branch is created. If a fix has to be made to the production release, a branch for the fix is created. Once fix is released, a new trunk is created from the fix branch. The changes are merged into the branch under current development.

This layout answers the same questions slightly differently:

• What code is currently running in production: Trunk
• What is the latest code I should develop from: Latest branch
• How to make changes to version X.XX.XXX: Make a new branch from the version X.XX.XXX. After bug fix is released into production, the branch is copied and becomes the new trunk. Changes are merged into the latest development branch.

There are other repository layouts available, and / or your team might make design changes around above structures.

Technorati Tags: Development,Source Control,SCM,Tools,Tips

Source Control Management 201 - Repository Design for efficient code management using any source control

Subversion 1.6 is released

Subversion 1.6 (And so is TortoiseSVN 1.6 and Subclipse 1.6) is released.

New Functionality includes

• Improved handling of authentication data
• Repository root relative URLs
• Improvements to svn:externals
• Detection of tree conflicts
• Filesystem storage improvements
• Ctypes Python Bindings
• Improved interactive conflict resolution
• Sparse directory exclusion
• Logging support for svnserve
• New public HTTP URI syntax for examining history
• Command-line client improvements
• API changes, improvements, and much language bindings work
• More than 65 new bug fixes, enhancements
  

TortoiseSVN includes a completely rewritten Revision Graph

Get it while its hot www.tigris.org

Technorati Tags: Subversion,TortoiseSVN,Tools,Source Control

Subversion 1.6 is released

Batch converting Unicode files to ASCII in Subversion (utilizing Powershell)

Recently we’ve worked on importing our database structure into subversion. After scripting out the database schema into thousands .SQL files, and checking them in, we’ve realized that the files were creating in Unicode. Subversion used binary encoding when sending the files into the repository. Even though client side tools were able to work on files without any problems, all server-side tools (like FishEye, Bamboo, etc…) considered them binary, and were not able to properly process them. Batch converting them to ASCII took a little research, but overall was relatively straightforward.

After checking the structure out to the local drive, I’ve used a 1 line Powershell script convert the files to binary (note: this is one lone line)

dir --recurs -include *.sql | foreach {$FileName = $_; $fileData = get-content -path $_; out-file -filePath $FileName.FullName -inputObject $fileData -encoding ascii}

After having all files changed to ASCII, we had to remove the svn:mime-type property. To do that, run the following:

snv propdel svn:mime-type –R *.sql

Finally, we checked in the changes back into the repository.

Technorati Tags: Subversion,Tips

Batch converting Unicode files to ASCII in Subversion (utilizing Powershell)

Subversion pre-revprop-change hook

Another small batch file hook for those running subversion on windows. This hook will allow users to update a log message on the old check-in.

Note: Property changes are not versioned, so you will permanently loose the old message.

Place this in a pre-revprop-change.cmd
-------------
IF %5 EQU M GOTO CONT1
GOTO FAIL
:CONT1
IF %4 EQU svn:log GOTO OK
:FAIL
echo "Changing revision properties other than svn:log is prohibited" >&2
exit 1
:OK
exit 0
------------

 

Technorati Tags: Subversion, Tips, Windows

Subversion pre-revprop-change hook

Subversion pre-commit hooks

I am using a wonderful source control product Subversion. More information is available on http://subversion.tigris.org

A great future of subversion is an ability to run a server script before the check-in is committed . The script has the ability to rollback the check-in. We are using this functionality to enforce comments for every check-in.

To create a script, place any executable file into a hooks folder in the repository. You can start with a pre-commit.tmpl template file that is located there already. The template is a perl script that accomplishes exactly that functionality.

Our subversion runs on a windows system, so we converted the perl script into a batch file

"c:\Program Files\Subversion\bin\svnlook.exe" log -t %2 %1 | FindStr [a-zA-Z0-9]
IF %ERRORLEVEL% EQU 0 GOTO OK
echo "Commit Comments are Required" >&2
exit 1
:OK
exit 0

Place the code into a pre-commit.bat batch file in the hooks directory.

Technorati Tags: Development,Subversion,Tips,Tools

Subversion pre-commit hooks

AnkhSVN 1.0 released!

This is a great milestone. AnkhSVN is released. For those who do not know, AnkSVN is an add-in for Visual Studio that provides SVN Integration. I've been using it for the last 2 years as beta and it was great. Definitely a step above prior VSS integration. Read about it here Or download it here

AnkhSVN 1.0 released!