When I got back to my personal project recently and tried to commit some files to its Subversion repository, I started getting an
Abort Trap error message. At this point, I was told by Subversion that I needed to use
svn cleanup in the local copy and
svnadmin recover /My/Repository on the repository to make things right.
I couldn’t find anything online about other people having these problems.
So I decided, if the repository was bad, I would dump and reload it, and maybe that would fix the problem. I used the Subversion commands I described in this previous post to do it.
What I discovered was that the reload process halted at an “Icon” file. Actually, the name of the original file was not “Icon”, but rather “Icon\r”, where the “\r” indicated a carriage return a.k.a. ASCII value 13 character, which is the old Macintosh linebreak character.
As described at on this page (but curiously, nowhere that I could find on Apple’s ADC Web site), “Icon\r” files are the way to specify that the enclosing folder should have a custom icon, and to specify what that custom icon should be. Such files are invisible due to a particular bit set in their HFS information. Update: in the original version of this post, I said they were just the OS 9 way of doing this, but I was wrong; OS X still uses this technique for everything except volume icons. (Thanks, Uli!)
In any case, they must have been sucked into the Subversion repository I made. If I used my original repository dump file, I could even make the “Icon\r” files show up in the Finder, since the hidden bit is not preserved by Subversion. But any attempt now to commit any changes while these “Icon\r” files existed made my repository go boom. (Why didn’t this show up during earlier commits? Dunno that, either.) This included any attempt to delete those “Icon\r” files. I was stymied.
However, there was a way to modify the dump file I had been able to make (though not re-load). Subversion dump files are human-readable text files, but the file I had was 80 Mb., basically unreadable in any text editor on my machine without a lot more RAM. Luckily, the Subversion authors saw just this possibility, and made a utility,
svndumpfilter, that can be used to filter specific files out of a dump file.
Simply give it either a list of paths you wish to keep, or a list of paths you wish to not keep, then pipe your repository dump data through this filter. The result will be a modified stream of dump data that contains only the versioned paths you (explicitly or implicitly) requested.
See the rest of the manual for more details: it’s quite nicely written.
Using that utility, I was able to remove the “Icon\r” files completely from my dump file (as if they had never existed), load the repository in again, and go from there, with no loss of history for the files I hadn’t removed.
One nice thing was that once I’d removed the “Icon\r” files from the
trunk area of my repository, they were also gone from the one
tag area I’d made. I didn’t have to manually remove the files from both places.
Updated: made corrections suggested by Uli in the comments.
I’ve spoken to two developers I know about my Subversion repository, and the reaction from both of them was:
You’re using the filesystem version, not the Berkeley DB version, right?
But while the first developer (hi, Wolf!) couldn’t give me a good reason not to use the default Berkeley DB version, which per the manual is better tested, the second developer (hi, Uli!) could.
On Mac OS X 10.3 Panther, Berkeley DB has a known corruption bug.
Good enough for me.
The manual actually does a really good job of explaining the steps needed to export your repository and then import it again in another format. Here are the steps I used:
svnadmin dump /My/Repository/ > dumpfile
// Move old repository somewhere else
svnadmin create --fs-type fsfs /My/Repository/
svnadmin load /My/Repository/ < dumpfile
I just rebuilt my entire project and ran it, and it looks great.
At least one of my commenters has mentioned various Subversion GUI-based clients. For now, I’m just using Xcode 1.5’s Subversion plugin. For the most part I like it, but there are two issues:
- Xcode expects the Subversion utilities in yet another location,
/usr/local/subversion/bin/. So I made that work.
- Xcode’s Subversion plugin doesn’t handle bundles like nib files correctly. Known problem. So I have to check in nib files from the command line.
Another commenter asks, why Subversion?
I’ve heard both good and bad things about Subversion. The good: it discards a lot of the cruft of CVS, and it has some new features, esp. atomic multiple commits. The bad: I vaguely remember reading someone’s opinion that as far as going in a new direction, Subversion gets it all wrong. Was that in a weblog somewhere?
I guess my main reason for trying it was that it looked like it would be easier than CVS.
Oh, and if I did run into problems, the Subversion partisans I know might be more enthusiast about helping me because it promotes a product they like.
Nobody likes CVS.
I’ve set up my first personal Subversion repository.
By all accounts, Subversion is much easier than CVS. But setting up a personal repository on Mac OS X involves little steps that nobody seems to have written down anywhere yet.
First of all, don’t bother with all the packages listed in the MacDevCenter.com article “Making the Jump to Subversion”. For 10.3 “Panther,” all you need is one of these two packages:
- Martin Ott’s packages containing statically linked binaries for Mac OS X 10.3 Panther
- Metissian’s Mac OS X Subversion Packages
Alas, neither works out of the box without further fiddling. What I discovered from Metissian’s README file is that it doesn’t install its utilities under any of the standard 10.3
PATH environment variable locations. Type
echo $PATH in a Terminal window to see these locations for yourself. Instead, without any explanation (though I’m sure some Unix expert could give me theories), it puts them in
/usr/local/bin. Under a standard 10.3 configuration, such utilities are not conveniently accessible.
There are perhaps half a dozen ways to add to your
PATH environmental variable. Ask the above-mentioned Unix experts about their various merits if you want to while away an hour or two. The one I use is a
.profile file in my home directory. See this sample profile.txt file. (Update: I accidently deleted the sample file. See the comments for other options.)
Now you can use Subversion utilities like
svn from a Terminal window. Have a look at the Subversion book to see the steps needed from there to set up and access a same-machine Subversion repository.
I’ve heard rumors you need a
~/.subversion/config file to prevent a Subversion import from sucking in
.DS_Store files, but my admittedly simple tests tonight show that this fear is unfounded.
I’m sure I’ll have more to say about Subversion, esp. about sample
config files, but for now, that’s it!