I just tested Subversion trunk (r945683) and the issue persists.
On Tue, May 18, 2010 at 05:21:27PM +0200, Jamma Tino Schwarze wrote:
> I'm currently in the process of migrating a large CVS repository to
> Subversion. One of our use cases for Subversion is partially syncing the
> repository to our customers for read-only access.
>
> During testing svnsync I came across an issue which may be reproduced
> using the attached test script. It creates a repository (requires
> svnmucc for the critical step), then svnsync's the /mf path within the
> repository.
>
> The operation which seems to be critical looks like this in an svn dump
> (revision 5 according to attached script):
>
> Node-path: mf
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk
>
>
> Node-path: mf/d
> Node-kind: dir
> Node-action: delete
>
> Node-path: mf/d
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 4
> Node-copyfrom-path: branches/o/d
>
> -> a delete immediately followed by a copy to the same location.
>
> svnsync fails with at :
> svnsync: File not found: revision 5, path '/mf/d/m.txt'
>
> This file is not supposed to exist there because mf/d has been deleted
> first, then replaced by branches/o/d which does not contain the file (it
> is in /trunk/d/ though).
>
> The repository itself seems to be consistend - dumping and loading it
> works, even incremental dumping/loading.
>
> I googled for this issue and looked at the issue tracker but couldn't
> come up with any matching bug report. I tested against SVN 1.6.11 and
> will try again using trunk.
>
> Is it a bug?
>
> Thanks,
>
> Tino.
>
> --
> "What we nourish flourishes." - "Was wir nähren erblüht."
>
> www.tisc.de
--
"What we nourish flourishes." - "Was wir nähren erblüht."
www.lichtkreis-chemnitz.de
www.tisc.de
Received on 2010-05-18 18:51:50 CEST