During a normal development cycle, multiple branches of trunk may exist simultaneously with different features/fixes being developed within each. In order to keep trunk relatively stable at all times, it is a good idea to merge any changes to trunk since the branch was created into that branch when the branch is ready to be pushed into trunk. Confusing? The process is as follows
branchbranch (other developers are doing the same in their respective branches)branch
trunk since the branch was created into the branchtrunk changesbranch back into trunkThis is by no means the only way to manage development of a new feature/fix within Subversion, and I make no claim that it is the best. This is simply what works for my team at work presently. The end of the process described above (starting with 3) looks as follows
$ cd /path/to/branch
$ svn log --stop-on-copy # Run this from within the branch root - notice the revision # when the log output stops
$ svn merge -r ###:HEAD /path/to/trunk . # Here ### is the revision number from above
# Resolve any conflicts and test all code again in the branch
# Now to get the changes from the branch merged successfully back into trunk
$ cd /path/to/trunk
$ svn merge /path/to/branch -r ###:HEAD --accept theirs-full
$ svn resolve -R --accept working *
$ svn ci -m "Merging branch ____ into trunk" # Commit the branch merge into trunk
The 2nd and 3rd from last lines above are the ones of interest; they are the ones responsible for getting the work back into trunk. These lines are really only necessary since we had first merged work from trunk into the branch. The first line
$ svn merge /path/to/branch -r ###:HEAD --accept theirs-full
merges all changes from the branch since it was created back into trunk. This includes all code merged from trunk to the branch, so we are guaranteed that the branch has the latest and greatest of all code. As such, we force SVN to resolve all conflicts by accepting the branch copy’s version of every file within our working trunk copy. The next line
$ svn resolve -R --accept working *
Resolves any tree conflicts that have been introduced.
The source code for D4core is maintained in and SVN repository. I have found it helpful to create a .cleanup and .commit Bash script in the root directory of our framework’s repository.
.cleanup has the task of removing cached files, temporary files, and log files which are no longer relevant to the current development cycle. It also use it currently to reformat our XML configuration file with pretty whitespace using xmllint.
#!/bin/bash
echo "Cleaning D4core..."
rm -f D4core/Content/Cache/Smarty/*
rm -f D4core/Content/Compile/Smarty/*
rm -f D4core/Content/Cache/Minify/*
rm -f D4core/Config/Backup_*
rm -f D4core/Log/Error/*
rm -f D4core/Log/Logs/*
xmllint -format D4core/Config/Config.xml -output D4core/Config/Config.xml
echo 'Running `svn status`...'
svn status
echo "Cleaning D4core completed."
.commit (which calls .cleanup initially) is responsible for managing the commit process. This file is run only after all project files have been added/removed/moved within the working copy and we are ready to commit to SVN.
#!/bin/bash
./.cleanup
svn commit
echo "D4core SVN commit complete."
By running ./.cleanup before committing code to the repository it becomes a lot easier to ensure the status and location of all files within the working copy are correct. These simply scripts easily save me 5 minutes a day in shell.
When recompiling SVN 1.5.5 from source, making sure to include the swig-py bindings to allow Trac to read from local SVN repositories, I used the following ./configure command
./configure --prefix=/usr/local/svn-1.5.5/ --with-apr=/usr/local/apr/bin --with-apr-util=/usr/local/apr/bin --with-neon=/usr/bin --with-apxs=/usr/local/apache/bin/apxs
When trying to view my repository I was presented with the following error in my trac.log file
SubversionException: ("Can't set position pointer in file '/var/svn/db/revs/135': Invalid argument", 22)
After some research1 I found the most common cause of this error is that Subversion was compiled against a different version of apr and apr-util than apache was. I found apache compiled with cPanel’s EA3 uses
/usr/local/apache/bin
as it’s path for apr and apr-util. Changing the flags to reflect this when compiling Subversion I was left with
./configure --prefix=/usr/local/svn-1.5.5 --with-apr=/usr/local/apache/bin --with-apr-util=/usr/local/apache/bin --with-neon=/usr/bin --with-apxs=/usr/local/apache/bin/apxs
make swig-py
make install
make install-swig-py
cd /usr/local/svn-1.5.5/lib/svn-python/
cp -r libsvn/* /usr/lib/python2.4/site-packages/libsvn
cp -r svn/* /usr/lib/python2.4/site-packages/svn
service httpd restart
I also ran the following out of habit after recompiling SVN before restarting httpd.
trac-admin TRAC_ENV_PATH resync