Posted by: peteinman | December 23, 2008

Subversion Migration from VSS and some Merge Issues

Earlier this year we moved our source control system from Visual Source Safe (VSS) to Subversion 1.4.

That was probably one of the best ideas we’d had this year! VSS was hopelessly inadequate to handle any sort of branching model that suited java development and our project structure.

When we originally created our subversion repository, we were running SVN 1.4 and after a few months ended up suddenly finding out what all the fuss was with the future plans for SVN1.5 and merge tracking. Keeping track of merges manually wasn’t much fun.

We run a stable trunk approach to subversion and all work on a release is done on a branch.

Release builds at the moment are actually built from the branch, which arguably isn’t good practice, but at the moment it works for us.

Once the release has been performed, the branch is merged down to the trunk – and we *should* run unit tests and a build on the trunk to verify it’s actually ok. In practice that doesn’t happen as much as it should but it is in our plans to do that formally.

1.5 Upgrade

The 1.4.* -> 1.5 upgrade was the smoothest upgrade I’ve done for some time, it worked beautifully.

I’m not sure why, but it took me a few days to find the "svnadmin upgrade" command to actually upgrade the repository to the 1.5 format which enabled merge tracking etc.

For some reason I seemed to miss the "svnadmin upgrade" command, so once that was run, the repository was at 1.5.

What else was there to do?

When I started doing the first branch-branch merges, I found I was having to specify revision numbers and wondered where the benefit of merge tracking came in.

After a few merges needing revision numbers, things started to improve and my branch-branch merges are done simply using the merge tracking features in the following command

>>svn merge http://mysvnserver/mysourceurl .

What was different?

I suddenly started to spot directories being updated in my commits and found that these had the mergeinfo property set, and it was this that was controlling what had merged and what hadn’t.

Cool, so merge tracking had started to work.

Anyway, the time came to merge down to the trunk after a release

Woah, loads of files merged and conflicted going back right to revision 1, what had happened?

Seems that the mergeinfo property wasn’t set on any of the trunk folders and after some digging found that the "–record-only" option of "svn merge" was the feature which would update all my folders in the trunk and mean that I could finally use the full merge tracking features of 1.5.

Not sure why I’ve written this now, but I have so may as well publish it!!!

Technorati Tags: ,,
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: