Subversion pain

I'm a firm believer in source control. I will not work for a company that refuses to use it. But, not all source control is created the same. At our office, we have been using subversion for some time since it was an easier transition from CVS. That's a shame, since in order to work in a branch as I often do, I've got to do the following contortions:

# work for a while, decide to merge changes in from the trunk
$ svn st -q
# oops, I have local changes and I don't want to commit them yet
$ svn diff > backup-my-changes.patch
# for each changed file
$ svn revert files
# review the logs to determine the last revision I merged from trunk, and the latest revision from trunk
$ svn log -v | less
$ svn merge -r123:456 ~/svn/trunk .
$ svn commit -m "Merge -r123:456 from trunk"
$ patch -p0 < backup-my-changes.patch
$ rm backup-my-changes.patch

On the other hand, I've been getting a lot of exposure to git over the past year or so and the equivalent workflow is something along these lines:

# work for a while, decide to merge changes in from the trunk
$ git rebase master

So you see, not all source control packages are created equally. Branching is so simple and useful in git that I never knew what I was missing until I started using it. My workflow is often:

• work on experimental changes
• receive request to work on another task
• finish task, return to experimental changes
• repeat

In git this is all taken care of for you by using git-branch and git-rebase as necessary. There's not nearly as much thinking involved as in the subversion workflow.

I don't think I can convince management to let us switch to git though, since it is a more radical change and some developers might not like change. Pity, that.