Re: svn commit: rev 2030 - branches/issue-654-dev/subversion/svnadmin branches/issue-654-dev/subversion/include branches/issue-654-dev/subversion/libsvn_subr branches/issue-654-dev/subversion/libsvn_repos

cmpilato@collab.net writes:

> > (I discovered a really silly bug while dreaming about svn last night.
> > I woke up, tried out my test-case, and indeed the bug was there.
> > :-) )
>
> Um...dude?

No need for panic.

The parser has two modes: require copy sources to exist, or not.

If a node in the dumpfile says it has copy history, then the parser
calls svn_fs_copy() when the flag is set, and screams and chokes if
the copy source isn't available. If the flag isn't set, that's
fine... instead of attempting to make a copy, it just adds the whole
file or subtree as "new" items. (Items in the dumpfile are always
present as fulltexts). No big deal, you just lose the copy history,
not the data.

The bug is this: after successfully copying a subtree, it continues
to parse the dumpfile, and sees nodes within the subtree, all marked
as "things to add". Obviously, it should *skip* these items if the
initial copy was successful. Right now, it tries to re-add them and
the fs rightly errors out.

'Twill be fixed in a jif.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:25:31 2002