I could use some feedback about a problem I'm having with the behavior
of subversion 1.1.0-rc1 on my Fedora Core 1 box. I made the subversion
rpm myself, and made certain choices regarding the supporting packages
-- details on all that below.
The reason I wanted to move up to 1.1.0 is that the project I'm actively
developing has quite a number of symlinks that I wanted subversion to
handle for me. Subversion 1.1.0-rc1 appeared to be working absolutely
fine until yesterday, when I exercised it in ways I hadn't before.
Here's the problem I ran into. I have a repository that is being served
only by Apache httpd using ssl (not that this detail should matter for
this problem, as far as I can imagine...). Right now the working
directory and server are on the same machine, so both sides are
I wanted to rename a directory that contains symlinks. So I did
svn mv not-yum configure-system
and that command completed fine. But then if I do 'svn st' I see:
A + configure-system
~ + configure-system/cf.imports
~ + configure-system/cfagent.test
~ + configure-system/cfagent.run
Note the '~' and the fact that configure-system/cf.not-yum.imports is
not listed, even though it does exist after the 'svn mv'.
Instead of symlinks in the new directory, I have files with the contents
of the files pointed to by the old symlinks. In other words,
subversion seems to have dereferenced the symlinks when it shouldn't
This caused a pretty big headache (and one I'm sure subversion
developers don't want users to see). Not only do I now have files
where I wanted symlinks, but the repository got hosed when I committed
When I committed these changes, the commit printed out errors. But on
the server side, it appeared to have made the changes -- there was a
new revision and the configure-system directory was in the new
revision. But now I cannot checkout a new working copy -- the checkout
fails partway through, bombing while working on the configure-system
I ended up doing a dump of the database up to the previous revision, and
reloading it into a new repository -- the old one was hosed by the last
revision. I'm not fluent enough in subversion to figure out how to
resurrect it other than with a dump/load cycle.
Now, I know well that this problem may be due to my particular setup, so
I'll describe it below. Meanwhile, I'd be interested to know whether
others can reproduce the problem on other OSes. If you have 1.1.0-rc1
installed, it should be a pretty quick test.
Appendix -- my setup
My machine is fully up to date with the latest Fedora Core 1 updates,
and has a small number of unofficial additions or updates.
I created a subversion 1.1.0-rc1 rpm starting with a recent Fedora Core
Development source rpm, either for 1.0.5 or 1.0.6, I forget. I had to
do a fair bit of fiddling to get the rpm to build and test cleanly; I
can detail my changes if asked (or just give you specfile, source rpm,
Here are the versions & origins of the other packages that subversion
The INSTALL docs for subversion-1.1.0-rc1 say we want apr-0.9.5, but I
couldn't find that version anywhere, so I'm using apr-0.9.4-2.1, the
latest version and release from Fedora Core 1 Updates.
INSTALL says 2.50 or newer; I have 2.57-3 from Fedora Core 1.
INSTALL says 1.4 or newer; I have 1.5-8 from Fedora Core 1.
INSTALL says 0.24.7; Fedora Core 1 Updates provides only 0.24.5-2.1. I
got a recent neon source rpm from Fedora development, version 0.24.7-3,
and rebuilt it for Fedora Core 1 and installed it (it rebuilt cleanly
with no modifications).
INSTALL says you need 4.x, that you should try to get the latest version
(4.2.52), and that 4.2.52 is strongly recommended over 4.0 or 4.1.
Fedora Core 1 comes with db4-4.1.25-14, and it would be a royal pain to
install 4.2.52. So I stayed with 4.1.25.
INSTALL says 2.0.49 or newer; I'm running 2.0.50-1.0 from Fedora Core 1
INSTALL says 2.0 or newer; Fedora Core 1 comes with 2.2.3-7.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Aug 4 06:18:17 2004