Posts tagged Subversion
The installer of version 1.6.10 (and 1.6.8) of TortoiseSVN has a bug that leads to an incomplete update. You must run the installer a second time and choose the second time the ‘Repair’ option for a proper upgrade. One of the symptoms of an incomplete installation is an exception when trying to compare office files due to missing Diff scripts in the Diff-Scripts directory.
Source control is off course an essential part of the development process and Subversion is an excellent system for that purpose. In the past, installation of subversion was a bit complicated because it involved several steps, an Apache webserver and not-so-accessible user management and repository configuration. However, nowadays installation and management can’t be easier, on whatever platform you are either with Collabnet Subversion Edge or with VisualSVN Server.
Subversion is a great source control system. One of the great features is it’s branching and merging support. Although many developers avoid it, branching is very powerful and useful and should not be something to be afraid off but something to be familiar with. And for the stable and controlled development is it almost a necessity to master it.
In general we can identify two types of branches: product and feature branches.
- The product branch is normally to support maintenance on a released version while development of the next version continues.
- A feature branch is normally a temporary branch to work on a (complex) change without interfering with the stability of the main development line (trunk) and in the end is incorporated back into the main line again.
Now, while you can work on isolation on the feature branch, there will come a time that you’ll have to integrate (merge) the changes with the trunk. And although subversion does provide extensive merge support, this might get messy with big changes. So it’s a real good idea to keep the feature branch in sync with the trunk and have the changes in the trunk regularly applied to the feature branch too. Actually, this is not so More >
Yesterday I was given a new assignment. Of a certain system all development was stopped a month ago. The latest version, deployed and tested on the test environment, will not continue to be deployed on the production environment. The current version running on production is almost a year old. All new functionality developed after this version will be withdrawn, except for two changes. The assignment is to implement only these two changes on the version current running in production.
All the Java code is nicely stored in subversion. There is a tag of the version current running on the production environment, as well as several tags of later versions which has not been deployed to production, only to the test environment. And the trunk is the latest developemnt code, as it should be. How are we going to this, so the trunk can be used in future to contitue development? (more…)