« New, security enchanced product! | Main | Learning by osmosis »

Dealing with subversion's question marks

Often when I make a commit with Subversion, the source control software I use, via the svn command line tool, I run into another not-so-helpful error message that takes me far longer than it should to resolve. These errors occur often enough to be very annoying, but rarely enough to be unfamiliar each time. So it seems worthwhile to document the resolution process I've discovered, for three of the most common errors I've run into.

The first two errors become apparent when a svn commit command returns something like this:

svn: Commit failed (details follow):
svn: Out of date: '/path/to/my/file/or/folder' in transaction '56-1'
typically obfuscated with interspersed lines of code that is surely of interest only to a subversion programmer.

Firstly, the misleading "out of date" message simply means that the version that has been edited locally is older than that in the repository. The most likely scenario leading to this situation is that there were two separate edits of revision A; editor B committed their copy; and editor A is now trying to commit their own changes. The intended resolution is to have editor A update to editor B's revision, resolve the conflicts, merge the changes, and commit their own version with both editor's changes.

Often I don't want to use this method - either I'm checking in files that I don't want to merge (Interface Builder nib's for example) or I want to overwrite whatever is in the repository with my local copy. Subversion deliberately does not have a "force" option on their commit, to save people shooting themselves in the foot. Instead, a workaround I've found is this:

% svn commit myFile.nib
svn has an "out of date" dummy spit
- backup myFile.nib using Finder
% svn revert myFile.nib
- replace everything in myFile.nib *except* the .svn folder with the version in the freshly made backup
% svn commit myFile.nib

The second problem might be that a svn status shows a question mark alongside the file in question, indicating the file is not under source control, but attempting an svn add on the file returns "File is already under source control"! Interface Builder .nib files again are a likely suspect. The problem can occur if a .nib file is duplicated and one copy changed to suit a new purpose. Seems like a reasonable way to create a new .nib file if there is already a similar one in existence, and it would be perfectly acceptable, if .nib weren't secretly directories! The issue is that in duplicating the .nib file, the enclosed .svn folder is also copied, which confounds Subversion. The resolution then, is to remove the .svn file, and then svn add the enclosing folder. Simple when you know!

Finally, the third error I often come across, also shows itself with a question mark against the file in a svn status. Again, the question mark indicates files that are not under source control, but in this case they are files that you don't want under source control. Despite creating a .svnignore file in the relevant directory, the files still appear in a svn status. The solution is to do a svn propset on the parent directory. If the .svnignore file is present and accurate, this is straightforward:

% svn propset svn:ignore -F parentFolder/.svnignore parentFolder

Setting a folder's propset is equivalent to modifying a file, and the folder will need to be checked in, so make sure this is done on an updated copy of the folder in question.


TrackBack URL for this entry:

Post a comment