[BUGREPORT] svn move

[an...@gnulinux.dk]

Hello again

It's the danish translators again calling for your assistance. 

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. 

To test if it was a client or a server bug we did a new checkout of the
repository and it worked fine. Apperently something was wrong with the
client.

Hope this is sufficient info. If more is needed please ask! The repository
can be pulled from http://www.gnulinux.dk/svn/gentoo-doc-dk

-- 
Anders Rune Jensen
jabber: superduck@myjabber.net | email : anders@gnulinux.dk

Re: [BUGREPORT] svn move

[Blair Zajac <bl...@orcaware.com>]

anders@gnulinux.dk wrote:
> 
> Hello again
> 
> It's the danish translators again calling for your assistance.
> 
> 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'

I'm seeing the same thing with svn cp using revision 2128 to make a tag.
Here's how to reproduce it:

% cd /tmp
% wget http://www.cpan.org/modules/by-authors/id/B/BZ/BZAJAC/Proc-Background-1.07.tar.gz
% zcat Proc-Background-1.07.tar.gz | tar xvf -
% svn_load_dirs.pl -t '\d+\.\d+' http://URL.TO.YOUR.SVN/repos Proc-Background-1.07
.
.
.
Running svn cp -m Tag /repos/trunk as /repos/tags/1.07. http://svn.orcaware.com:8000/repos/trunk http://svn.orcaware.com:8000/repos/tags/1.07
blair's password:
Running svn update
/export/home1/blair/old: svn update failed with this output:

svn_error: #21066 : <Filesystem has no item>

file not found: revision `2', path `/tags/1.07/t/01proc.t'

D  ./trunk/proc_background
D  ./trunk/apache_configparser
D  ./trunk/math_interpolate1d
D  ./trunk/badblocks
D  ./trunk/orca
D  ./trunk/datetime_precise
D  ./trunk/web_log_manage
A  ./tags/1.07
A  ./tags/1.07/t


svn_load_dirs.pl is in the svn repository in tools/client-side/svn_load_dirs.pl.

Best,
Blair

-- 
Blair Zajac <bl...@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BUGREPORT] svn move

[Ben Collins-Sussman <su...@collab.net>]

anders@gnulinux.dk writes:

> 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
      renamed]

  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
understand why.

You see, the server's response to the update REPORT request is a nice
dir_delta drive, part of which looks like this:

<S:add-directory name="xml">
  <D:checked-in>
    <D:href>/svn/gentoo-doc-dk/!svn/ver/34/xml</D:href>
  </D:checked-in>
 <S:add-file name="java.xml">
    <D:checked-in>
        <D:href>/svn/gentoo-doc-dk/!svn/ver/15/xml/java.xml</D:href>
   </D:checked-in>

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.  :-)

Thoughts?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org