Flashmark

Subversion has been giving me a few headaches lately - it seems to coincide with upgrading both repository and clients to 1.5, but i’ve not tried downgrading so can’t be sure. The latest problem is occurring when trying to merge some trunk bug fixes (from a single changeset, the latest revision in the trunk) into a feature branch we’re working on.

This is the error message we are seeing:

Command: Merging revisions 1-HEAD of svn+ssh://host/repos-path into R:\, respecting ancestry, Test Only
Error: Working copy path ‘folder/file.txt’ does not exist in repository
Finished!:

I’m using TortoiseSVN 1.5.1 and the repository is running Subversion 1.5.0. I’ve done quite a few merges into this branch since upgrading to 1.5, so there is some tracked merge-history. I get this error when I instruct Subversion to merge all revisions - i.e. not specifying the revision range to merge and allowing the server to work out the revisions which require merging. I wonder if 1-HEAD is the correct revision range to use? The file it is complaining about is present in the working copy, trunk and branch. It is also not modified in the revision I want to merge - however it was modified about 3 revisions earlier. Perhaps Subversion is trying to merge already-merged changes?

I have checked using the –show-revs eligible switch to svn mergeinfo to view which changesets it is eligible to receive, and this shows me the single revision that I was expecting.

When I use Show log to select the revision range, and choose just that single revision, the merge works without any problems, which leads me to think that the problem is to do with my merge-history.

I should mention at this point that we are actually using TortoiseSVN to check out our working copies onto Samba network shares. This is officially an unsupported configuration, however it has worked flawlessly for us for the last couple of years but since upgrading to Subversion 1.5 we have started getting various problems with corrupted working copies after successful commits - with TortoiseSVN reporting ‘permission denied’ errors when moving files around in the .svn folders. One thing I tried when fixing this was to allow readonly files to be deleted in the samba config file:

[global]
delete readonly = yes

That is the only thing that has changed since the last merge all revisions operation I tried. I have just tried to merge another trunk changeset to the branch with the merge all revisions option and it has worked without any problems! I can’t be certain that this is to do with the above samba settings, or whether some broken mergeinfo was eventually fixed in the last merge commit to the branch, or even if it was to do with the specific file which was being merged originally - but it may be worth a try.

Update: August 27th 2008
It looks like the above setting has solved all our Subversion-related problems; we’re no longer experiencing trashed working copies and merging seems to be working perfectly with Subversion tracking mergeinfo as it should.