You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jamma Tino Schwarze <su...@tisc.de> on 2010/05/18 17:21:27 UTC
Possible svnsync bug
Hi there,
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
Re: Possible svnsync bug
Posted by Jamma Tino Schwarze <ja...@tisc.de>.
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
Re: Possible svnsync bug
Posted by Jamma Tino Schwarze <ja...@tisc.de>.
Thanks for the quick confirmation. I filed it under issue number 3641.
http://subversion.tigris.org/issues/show_bug.cgi?id=3641
Thanks,
Jamma Tino.
On Tue, May 18, 2010 at 06:09:08PM +0100, Philip Martin wrote:
> Jamma Tino Schwarze <su...@tisc.de> writes:
>
> > 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.
> [...]
> > 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?
>
> Yes. It's reproducible with trunk. Please file an issue.
>
> My slightly simplified recipe:
>
> svn mkdir -mm $url/A
> svn mkdir -mm $url/A/B
> svn mkdir -mm $url/A/B/C
> svn mkdir -mm $url/X
> svnmucc -mm cp head $url/A $url/H rm $url/H/B cp head $url/X $url/H/B
>
> gives me this log:
>
> ------------------------------------------------------------------------
> r5 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /H (from /A:4)
> R /H/B (from /X:4)
> ------------------------------------------------------------------------
> r4 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /X
> ------------------------------------------------------------------------
> r3 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /A/B/C
> ------------------------------------------------------------------------
> r2 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /A/B
> ------------------------------------------------------------------------
> r1 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /A
> ------------------------------------------------------------------------
>
> and the svnsync fails with
>
> svnsync init $copy $url/H
> svnsync sync $copy
>
> ../src/subversion/svnsync/main.c:1333: (apr_err=160013)
> ../src/subversion/svnsync/main.c:1278: (apr_err=160013)
> ../src/subversion/libsvn_ra/ra_loader.c:1079: (apr_err=160013)
> ../src/subversion/libsvn_delta/path_driver.c:254: (apr_err=160013)
> ../src/subversion/libsvn_repos/replay.c:446: (apr_err=160013)
> ../src/subversion/libsvn_repos/replay.c:242: (apr_err=160013)
> ../src/subversion/libsvn_repos/replay.c:242: (apr_err=160013)
> ../src/subversion/libsvn_repos/replay.c:175: (apr_err=160013)
> ../src/subversion/libsvn_fs_fs/tree.c:1010: (apr_err=160013)
> ../src/subversion/libsvn_fs_fs/tree.c:1010: (apr_err=160013)
> ../src/subversion/libsvn_fs_fs/tree.c:825: (apr_err=160013)
> ../src/subversion/libsvn_fs_fs/tree.c:667: (apr_err=160013)
> svnsync: File not found: revision 5, path '/H/B/C'
>
> The replay editor attempts to convert the copy into an add, since the
> copy source is outside the sync, but as it traverses the copied tree
> something goes wrong. I'm not sure whether it should be looking for
> /H/B/C in the source, rather than the destination, or whether it
> should skip the deleted subdir.
>
> --
> Philip
--
"What we nourish flourishes." - "Was wir nähren erblüht."
www.lichtkreis-chemnitz.de
www.tisc.de
Re: Possible svnsync bug
Posted by Jamma Tino Schwarze <ja...@tisc.de>.
Thanks for the quick confirmation. I filed it under issue number 3641.
http://subversion.tigris.org/issues/show_bug.cgi?id=3641
Thanks,
Jamma Tino.
On Tue, May 18, 2010 at 06:09:08PM +0100, Philip Martin wrote:
> Jamma Tino Schwarze <su...@tisc.de> writes:
>
> > 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.
> [...]
> > 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?
>
> Yes. It's reproducible with trunk. Please file an issue.
>
> My slightly simplified recipe:
>
> svn mkdir -mm $url/A
> svn mkdir -mm $url/A/B
> svn mkdir -mm $url/A/B/C
> svn mkdir -mm $url/X
> svnmucc -mm cp head $url/A $url/H rm $url/H/B cp head $url/X $url/H/B
>
> gives me this log:
>
> ------------------------------------------------------------------------
> r5 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /H (from /A:4)
> R /H/B (from /X:4)
> ------------------------------------------------------------------------
> r4 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /X
> ------------------------------------------------------------------------
> r3 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /A/B/C
> ------------------------------------------------------------------------
> r2 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /A/B
> ------------------------------------------------------------------------
> r1 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
> Changed paths:
> A /A
> ------------------------------------------------------------------------
>
> and the svnsync fails with
>
> svnsync init $copy $url/H
> svnsync sync $copy
>
> ../src/subversion/svnsync/main.c:1333: (apr_err=160013)
> ../src/subversion/svnsync/main.c:1278: (apr_err=160013)
> ../src/subversion/libsvn_ra/ra_loader.c:1079: (apr_err=160013)
> ../src/subversion/libsvn_delta/path_driver.c:254: (apr_err=160013)
> ../src/subversion/libsvn_repos/replay.c:446: (apr_err=160013)
> ../src/subversion/libsvn_repos/replay.c:242: (apr_err=160013)
> ../src/subversion/libsvn_repos/replay.c:242: (apr_err=160013)
> ../src/subversion/libsvn_repos/replay.c:175: (apr_err=160013)
> ../src/subversion/libsvn_fs_fs/tree.c:1010: (apr_err=160013)
> ../src/subversion/libsvn_fs_fs/tree.c:1010: (apr_err=160013)
> ../src/subversion/libsvn_fs_fs/tree.c:825: (apr_err=160013)
> ../src/subversion/libsvn_fs_fs/tree.c:667: (apr_err=160013)
> svnsync: File not found: revision 5, path '/H/B/C'
>
> The replay editor attempts to convert the copy into an add, since the
> copy source is outside the sync, but as it traverses the copied tree
> something goes wrong. I'm not sure whether it should be looking for
> /H/B/C in the source, rather than the destination, or whether it
> should skip the deleted subdir.
>
> --
> Philip
--
"What we nourish flourishes." - "Was wir nähren erblüht."
www.lichtkreis-chemnitz.de
www.tisc.de
Re: Possible svnsync bug
Posted by Philip Martin <ph...@wandisco.com>.
Jamma Tino Schwarze <su...@tisc.de> writes:
> 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.
[...]
> 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?
Yes. It's reproducible with trunk. Please file an issue.
My slightly simplified recipe:
svn mkdir -mm $url/A
svn mkdir -mm $url/A/B
svn mkdir -mm $url/A/B/C
svn mkdir -mm $url/X
svnmucc -mm cp head $url/A $url/H rm $url/H/B cp head $url/X $url/H/B
gives me this log:
------------------------------------------------------------------------
r5 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
Changed paths:
A /H (from /A:4)
R /H/B (from /X:4)
------------------------------------------------------------------------
r4 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
Changed paths:
A /X
------------------------------------------------------------------------
r3 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
Changed paths:
A /A/B/C
------------------------------------------------------------------------
r2 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
Changed paths:
A /A/B
------------------------------------------------------------------------
r1 | pm | 2010-05-18 17:53:46 +0100 (Tue, 18 May 2010)
Changed paths:
A /A
------------------------------------------------------------------------
and the svnsync fails with
svnsync init $copy $url/H
svnsync sync $copy
../src/subversion/svnsync/main.c:1333: (apr_err=160013)
../src/subversion/svnsync/main.c:1278: (apr_err=160013)
../src/subversion/libsvn_ra/ra_loader.c:1079: (apr_err=160013)
../src/subversion/libsvn_delta/path_driver.c:254: (apr_err=160013)
../src/subversion/libsvn_repos/replay.c:446: (apr_err=160013)
../src/subversion/libsvn_repos/replay.c:242: (apr_err=160013)
../src/subversion/libsvn_repos/replay.c:242: (apr_err=160013)
../src/subversion/libsvn_repos/replay.c:175: (apr_err=160013)
../src/subversion/libsvn_fs_fs/tree.c:1010: (apr_err=160013)
../src/subversion/libsvn_fs_fs/tree.c:1010: (apr_err=160013)
../src/subversion/libsvn_fs_fs/tree.c:825: (apr_err=160013)
../src/subversion/libsvn_fs_fs/tree.c:667: (apr_err=160013)
svnsync: File not found: revision 5, path '/H/B/C'
The replay editor attempts to convert the copy into an add, since the
copy source is outside the sync, but as it traverses the copied tree
something goes wrong. I'm not sure whether it should be looking for
/H/B/C in the source, rather than the destination, or whether it
should skip the deleted subdir.
--
Philip
Re: Possible svnsync bug
Posted by Jamma Tino Schwarze <ja...@tisc.de>.
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