Subversion branching with less Pain™No matter how good of a source control system you use, branching can always cause loads of problems, and even painful merge days. At Slide, and other companies I've worked with that use Subversion, branching has been particularly painful because Subversion just doesn't maintain branch history like some commercial source control systems (like Perforce), in fact "branching" is quite literally making a copy of the trunk in Subversion. Depending on the lifespan of a particular branch, and how often you refresh your branch from the mainline branch, merging back down to the main branch can go from bad, to even worse. Interestingly enough, running an `svn diff $BRANCH $MAIN` will give you the correct changes on the appropriate files that have been modified in the branch, where as running an `svn merge -r $START:$END $BRANCH ./` (whereas ./ is your working copy of main) can break in tremendously painful ways causing mis-merges and unintended rollbacks of previous changesets. While merging down to the main branch today I decided to mix and match both svn diff and svn merge such that I would only merge changes down to the main branch that had been modified in my development branch, ensuring that nothing was changed on the main/stable branch that wasn't intended. The end result was a Python script that would execute the appropriate commands and merge the files one by one from one branch to the other, allowing the developer or QA engineer to check each file before commencing the merge. After some serious tweaking and a couple of test branches in Slide's Subversion repository, merge-safe.py was born. The script is a bit hackish right now in that it executes svn(1) instead of using Py-Subversion bindings (which haven't ever worked the way I had hoped). There is definitely room for improvement as well, but the basic flow is there such that merge-safe.py will diff the two branches and aggregate a list of files that have been modified since the branch was originally cut from the main/stable branch, then iterate through the file list and either merge (if the file has been edited) or copy (if the file has been added) to the main branch as is necessary. The script should always be run from the base directory of your working copy of the mainline branch, so if your main working copy is in /home/tyler/slide/main, this script could be run from that directory like: You can check the code out with: Usage
|
Recent comments
|
svnmerge
Check out svnmerge at http://www.orcaware.com/svn/wiki/Svnmerge.py
only for *nix
The idea seems interesting, but by looking at the script I have figured out it will only work on *nix machines as it relies on grep/sed.
But I think it may be an easy fix for it: instead of using os.popen use os.popen3 so that you get the output stream and you can grep/sed it with Python API.
./alex
--
.w( the_mindstorm )p.
Get Cygwin
Alex: get cygwin! Programmers need a programmers' command line.
get cygwin
I've been using cygwin for a long time and I was happy when I was able to give it away. But I don't want to start a discussion on this direction. I will rewrite the parts of the scripts that are using additional command line tools to use Python API. Even if performance may degrade I prefer it this way. I am not sure how can I send it back to you though.
bests,
./alex
--
.w( the_mindstorm )p.