My current job (which I’m loving to bits) involves looking after a piece of software that started life in VB6 with no source management to be seen. The primary author, and my boss, is not hip-to-Subversion. This presents a problem for me as Subversion is my poison of choice for supplying the metaphorical “safety net” when I tightrope walk out into unexplored software change territory.
Right now, we’re trying to find a sweet-spot between version control, and the free-form copy model that he’s been using to date. We’re not there yet, but today’s blog entry captures yesterday’s win on using TortiseSVN to give me a quick rundown on the differences between two branches in a repository. One with revision history, one without.
First off, I built a sandpit repository, and dropped both versions of the codebase in as separate branches. The trunk branch was taken from the “blessed” repository, with complete revision history. The other branch is my bosses copy, with no revision history available. Once the branches were loaded, I pulled the repository browser for my sandpit repository:
I then marked the trunk branch for comparison, as below:
Next, I compared the trunk branch URL against the branch I want to merge against:
Finally, TortiseSVN spits out a complete list of differences between both branches. At this point I can step into each file with TortiseMerge and get a feel for what I’m facing before I do the merge proper.
As a closing note, the actual automated merge failed miserably via TortiseSVN. I have a vague memory of walking a similar path to this before. Back then I gave up on the GUI, and went back to the SVN command-line for merges to give me that extra control over what I needed to do. One of the complicating factors this time around is that this strikes me as being similar to dealing with vendor branches, except that the entire codebase could be considered a vendor branch.