Recently in SVN Category

This is another descriptive error message from SVN. “Retrieval of mergeinfo unsupported”

If you’re seeing this error message you’re probably trying to use the reintegrate merger feature in SVN. You probably just used a command like this one:

svn merge --reintegrate svn://foobranch .

This error is caused by a configuration issue on your server, or a significant version mismatch between your client and server. It’s OK, though, this can be worked around pretty easily. Just fall back to the more reliable SVN 1.4 style explicit merger technique.

To use this approach you’ll need to know what revision you either created your branch from, or, if you’ve merged the trunk into your branch since creation, the revision you last merged into your branch. In this example, that revision is revision 42 (being the answer to the ultimate question)

svn merge svn://trunk@42 svn://foobranch .

Another option is to do an explicit revision to revision merger. This more low level syntax can be used for all sorts of crazy mergers including roll-backs and nonsensical mergers that will mess up your code. For this command you’ll need the revision from which you’d like to start your merger and the end revision. In this case I’ll be merging revisions 42 to 87. I’ll be merging these changes from the trunk to my current local path.

svn merge -r42:87 svn://trunk ./

If you’re lazy, like me, you commit your changes using svn commit -m "my awesome bug free code is done". This is easy and fast, but does not work if your software project has a machine specific configuration file, or something else that when committed causes other people pain.

SVN has no direct solution to this problem, but you can abuse the changelist feature to solve the problem. Simply create a changelist for these files and never commit it.

svn changelist donotcommit configurationfile1.xml configurationfile2.xml

You can confirm that this has worked with svn stat. Once the changeset is crated, it should look something like this:

bobdole@/svn/foo_project$  svn stat
M       changedcode.c
?       project.log

--- Changelist 'donotcommit':
        configurationfile1.xml
        configurationfile2.xml

Now you can go ahead and use svn commit -m "i fixed everything" again without living in fear of terrible office pranks being committed against you.

CVSDude, you suck.

CVSDude, the hosting provider that I’m currently using for Subversion, has been down all day. Since we’re an active development team, this has caused some very serious problems.

The worst part of the problem is that I cannot get a word from them. Their status blog entry seems to downplay it as a minor issue, but it’s far from that. They haven’t replied to my support requests that I sent in early this morning making it very hard for me to mitigate the damage. If they can’t take the time even to send a bulk reply, I really question their reliability as a whole. I do not feel that my source code is safe any longer.

If they haven’t replied to my email by the time I go home, I’ll have to stop by their office in Palo Alto to see what’s up.

If you've found this entry, you probably ran into your first SVN Tree conflict. This is also called an 'evil twin conflict' in some other revision control systems.

The message generated by svn merge or later svn stat operations will look something like this:

A     C web-app/images/widget.png
      >   local obstruction, incoming add upon merge
...
Summary of conflicts:
  Tree conflicts: 1

The Cause

This special conflict message is created when the same file has been added to both the place your merging from as well as the place your merging to since the last merge. Since these evil twins both have completely different histories and no common state (as would exist if the image had been added before you branched), svn is totally unable to provide you advice. This is why you will see no merge-left or merge-right files.

The Solution

In the example above the same binary file has been added to both a branch and a trunk. Since the image is identical, the solution was simply to pick one. I picked the working copy.

svn resolve --accept working ./web-app/images/widget.png

Another possible case is that two totally different files have been checked in with the same name and path. In this case, you're going to need to rename one version and refactor the rest of your code to accommodate that name change. SVN has no easy way to do this so you'll need to do it manually.

The last case is that the same file has been created but you need a super set of the functionality provided by both versions. Again, SVN does not offer any speedy tools for this so you'll simply need to do a manual merger.