Once the new Subversion repository was up and running, we used
svn switchto point our existing working copies at the new repository:
One potential gotcha is that Xcode sometimes seems to change the repository URL by inserting the username, so if you checked outsvn switch --relocate \ https://old.ablepear.repo/ \ https://new.cvsdude.repo/
https://old.ablepear.repo/, Xcode sometimes changes it to
https://email@example.com/. I'm not sure what the deal is with this, but a quick
svn infowill tell you what the current URL is for the working copy.
But the real fun began when I tried updating my Subversion client to 1.5. Subversion is actually fairly painless to build from source on a Mac, but I decided to go with precompiled binaries anyway. I don't have either MacPorts or Fink installed, so I downloaded the Subversion 1.5 installer from CollabNet. It's a standard Mac installer and it ran without a hitch, but it left me scratching my head -- after running, I opened a new terminal window and
svn --versionstill showed me on 1.4.4. Poking around, I discovered that the CollabNet installer puts the Subversion binaries in
Well, no problem, I added
developmentpaths file in
svn --versionnow shows 1.5.7.
After doing a
svn upsuccessfully on one of my Xcode project working copies from the terminal, I opened it in Xcode and tried to to SCM | Update Entire Project, which failed miserably -- Xcode complained that it's Subversion libraries were too old to work with the working copy. Subversion changed its working copy format between 1.4 and 1.5, and the new 1.5
svncommand automatically upgrades any working copy it touches.
After some furious googling, I found out that Xcode's Subversion plug-in expects to find the Subversion libraries in
/usr/lib, but CollabNet's installer puts them in
/opt/subversion/lib. I still had my old 1.4 Subversion commands and libraries in
/usr/librespectively. There's various schemes and scripts for copying or symlinking the Subversion 1.5 binaries into the correct places in
/usr: Duane Fields' blog, the Lemon Team blog and Apple's Mailing Lists archive are representative.
Well, rather than patch something that was kinda broken, I decided to "use the Source, Luke!" and downloaded the Subversion 1.5.7 source tarballs from Tigris.org. (Be sure to get both the source tarball and the dependencies tarball.)
Once you have the tarballs, building and installing is fairly easy but will take fifteen minutes or so. Unpack both tarballs in the same directory. If you unpack them from the Finder, you should have two directories: "
subversion-1.5.7" and "
subversion-1.5.7 2". (If you do it from the terminal, they should both unpack into the same directory). One of the directories will contain the dependencies:
apr-util(Apache Portable Runtime),
serf(HTTP clients) and
zlib(compression). Move these directories into the main Subversion source directory and delete the other one.
INSTALLfile in the Subversion directory doesn't make it clear that you need to run the included
autogen.shscript to create your
configurescript. Once you've created
configure --helpto see all the build options. Now you can follow the standard Unix configure/make/make install build process.
A couple of gotchas: Subversion is configured to install into
/usr/localby default, but to work with Xcode, we need to change that to
/usrinstead. Also, Neon, the default HTTP client, doesn't build SSL support by default. And since most Mac users don't have their
EDITORenvironment variable set, it's handy to set the default editor path.
Putting this all together, the Subversion build process looks like this:
Tip for TextMate users: create a symlink to thecd subversion-1.5.7 ./autogen.sh ./configure \ --prefix=/usr \ --with_editor=/usr/bin/nano \ --with-ssl make clean make sudo make install
ln -s /usr/local/bin/mate /usr/local/bin/mate_waitthen change
/usr/local/bin/mate_waitin the script above. (More about the
matecommand on the TextMate Blog.)
Tip for TextWrangler users: change
Now Xcode is happy with my working copies. So when is Subversion 1.6 going to be supported?