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