> We wanted to rename a directory and one did the following:
> svn mv originals xml
> svn ci -m "omdoebt"
> When others did an update they got the following error:
> svn update
> A ./xml
> svn_error: #21066 : <Filesystem has no item>
> file not found: revision 15', path /xml/java.xml'
> The repository is at revision 34.
Okay, now I'm worried that there's something profoundly wrong with our
new vsn-rsc-urls. I don't know why none of us saw this coming. :-(
Here's what I did to reproduce this bug:
1. svn co -r33 http://www.gnulinux.dk/svn/gentoo-doc-dk
[because presuably r34 was the revision where the directory was
2. start ethereal
3. svn up [expecting to see a rename of 'originals' dir to 'xml']
I get the same error, and looking at the ethereal trace, I think I
You see, the server's response to the update REPORT request is a nice
dir_delta drive, part of which looks like this:
Okay, it makes sense that we're adding a new directory 'xml'... later
on there is a command to delete the 'originals' directory. And it
makes sense that it has a CR/path of "34/xml".
Now look at its child file 'java.xml'. That file has been around ever
since r15, thus its CR is 15. But the path part is wrong: there *is*
no path 'xml/java.xml' in r15, as the fs rightly complains.
It seems that when mod_dav_svn generates a new vsn-rsc-url, it needs
to find the *original* path of the file in r15... it can't go using
the newly renamed path of r34. Either that, or just use
'34/xml/java.xml' and screw the CR thing.
Cmpilato, is this easy to do? Obviously, we didn't used to have this
problem back when we used id_t's. The code that generates
vsn-rsc-urls is mod_dav_svn/util.c:dav_svn_build_uri(). It obviously
needs to do more work, it's very simple right now. :-)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Jun 9 05:54:13 2002