Upgrading to SVN 1.5

Question

From the little I understand, svn 1.5 provides much better support for merge operations. So I'm considering upgrading from svn 1.4. The repository sits in a local file (more or less), and I use svn from the command line.

What hurdles can I expect and how will svn 1.5 handle the existing repository without the merge data?

edit: In particular, after I run svnadmin upgrade, how will svn handle merges from branches who were last merged in the 1.4 era?

And does svn-populate-node-origins-index have anything to do with this?

Reference: http://subversion.tigris.org/svn_1.5_releasenotes.html

Answer 1

Upgrading is straightforward. Subversion is backwards-compatible in most regards. However, you should upgrade your repository using svnadmin upgrade.

As far as I understand this, merge tracking will only work for merges after the upgrade. There is no real way to reconstruct the missing information.

Also, svn-populate-node-origins-index should be run on that repository, but for the reason laid out in the linked file (see usage_summary).

Answer 2

Depending on your development environment you might need updated bindings. Netbeans 6.2 for example doesn't work with SVN 1.5.

Answer 3

There is many tools to convert a repository from subversion/cvs to a completly different kind. Trying hardest not to be argumentative, I suggest you look at all the other options and decide for yourself if any can make life any easier like distributed version control systems for example. Git is one that claims to be better.

Answer 4

The upgrade should be smooth, however you won't get any magical merge benefits until the merge-info stuff is populated - which doesn't happen until you start using it.

The only tangible benefit of the merge info I've found is being able to see a list of potential merges between two branches and know which revisions have already been merged. It doesn't directly affect things like the number of conflicts that are generated, but does allow you to keep sane when tracking what's gone where. The merges performed before the upgrade don't cause problems, they just show up again as potential merges even though they've already been done.

That said, the merge info is just an svnproperty called svn:mergeinfo, of the format:

/Project/name/trunk:1355-3985,4019,4026-4437,4478,4481

This is the actual merge-info on one of our project release branches and tells us exactly what revisions from trunk are about to be released. This means that, where you need it, and where you can work it out, you can populate the mergeinfo manually and get all the benefits - that's what we did for the early revisions, above.

It might also be worthwhile looking at reshard.py, especially if the repository is large and on windows. The 1.4 fsfs repository format put all the revisions in separate files in the same folder, windows starts crawling with this after a few thousand revisions. 1.5 sharding groups revisions into separate folders of 1000 each. 1.6 will allow us to combine the old revisions into a single large revision file.