You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by William Uther <wi...@cs.cmu.edu> on 2002/06/07 18:41:58 UTC
svnadmin load error
Hi,
I just started playing with switching to the new repository format.
"svnadmin dump" worked fine. I only had ~120 revisions so I didn't bother
redeltifying. Anyway, "svnadmin load" dies...
------- Committed new rev 62 (loaded from original rev 62) >>>
<<< Started new txn, based on original revision 63
* adding path : trunk/Papers/Thesis/fig/introb ...COPIED... done.
subversion/libsvn_fs/tree.c:200
svn_error: #21073 : <Item already exists in filesystem>
file already exists: filesystem `svnroot/db', transaction `1r', path
`trunk/Papers/Thesis/fig/introb/rawMaze.graffle'
I don't have time to play with it (I feel bad about not contributing more,
but I have this little thesis thing to write...). If someone is interested
I can send them the gzipped dump file and/or the .tar.gz repository (they
are 6.3 and 14.3 Mb respectively). I'm wondering if there is some
repository corruption as that was about the time I discovered issue 667.
I'm not having any issues using the repository in particular, using svnlook
on the old repos gives:
% svnlook svnroot rev 63
will
2002-04-11 16:34 GMT
52
Moved Thesis/fig/intro to introb on the way to Intro
/
trunk/
[snip rest of repository listing]
Later,
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 07, 2002 at 05:10:38PM -0400, William Uther wrote:
>...
> Updated to new repos format. That seems to work now. And I can commit to
> it straight from my old working copy :).
Yup. Your WC will fix itself whenever you do a commit, or some kind of
change is pulled down during an 'update'.
> Quick question: There was much talk of a grad re-checkout for changing $svn
> to !svn. Does this apply at all to ra-local working copies? I can't see
> $svn or !svn in my entries files anywhere.
Not for ra_local. Only if you've checked out over the network. But even on a
WC from the network, it isn't "required". It will simply help out with some
performance issues.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by Ben Collins-Sussman <su...@collab.net>.
William Uther <wi...@cs.cmu.edu> writes:
> Quick question: There was much talk of a grad re-checkout for changing $svn
> to !svn. Does this apply at all to ra-local working copies? I can't see
> $svn or !svn in my entries files anywhere.
ra_local doesn't cache secret urls in your working copy; that's an
ra_dav feature. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by William Uther <wi...@cs.cmu.edu>.
On 7/6/02 2:58 PM, "Ben Collins-Sussman" <su...@collab.net> wrote:
> I'm 90% certain that I know what your problem is, because it looks
> exactly like what I've experienced myself.
>
> You see, 'svnadmin dump' used to dump all the files below a copied
> subtree, and 'svnadmin load' used to deliberately ignore these files
> if the copy went successfully.
>
> We tossed that plan: now 'svnadmin dump' just writes a *single* record
> into the dumpfile: "copy this directory", and 'svnadmin load' isn't
> deliberately ignoring any records anymore.
>
> The problem you're seeing (I'll bet) is that your dumpfile was
> produced by an older version of svnadmin -- it dumped too much data.
> And now you're trying to load the data with the latest svnadmin that
> doesn't want to see the data ("whattyamean add this file? it's
> already there, it was part of the copy!")
>
> Build yourself a static r2092 binary of svnadmin, and use *that* to
> make your dumpfile.
I'd just figured out something like this (rev 63 had an add under the copy)
when I got your email...
Having built the new old svn :) I just tried dumping and restoring the repos
(restoring to the old style). It works now.
Updated to new repos format. That seems to work now. And I can commit to
it straight from my old working copy :).
Quick question: There was much talk of a grad re-checkout for changing $svn
to !svn. Does this apply at all to ra-local working copies? I can't see
$svn or !svn in my entries files anywhere.
Thankyou for the help.
\x/ill :-}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by cm...@collab.net.
William Uther <wi...@cs.cmu.edu> writes:
> ------- Committed new rev 62 (loaded from original rev 62) >>>
>
> <<< Started new txn, based on original revision 63
> * adding path : trunk/Papers/Thesis/fig/introb ...COPIED... done.
>
> subversion/libsvn_fs/tree.c:200
> svn_error: #21073 : <Item already exists in filesystem>
> file already exists: filesystem `svnroot/db', transaction `1r', path
> `trunk/Papers/Thesis/fig/introb/rawMaze.graffle'
>
>
> I don't have time to play with it (I feel bad about not contributing more,
> but I have this little thesis thing to write...). If someone is interested
> I can send them the gzipped dump file and/or the .tar.gz repository (they
> are 6.3 and 14.3 Mb respectively). I'm wondering if there is some
> repository corruption as that was about the time I discovered issue 667.
Can you post the revision 63 portion of your dumpfile (if it isn't too
terribly large)?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by cm...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> > Shall I make the branch?
>
> Yes, please.
>
> Note: while I disagree with the fix to the undeltify command, we can
> certainly use that on the branch. I think the trunk should fix the
> svn_fs_deltify() function properly (and lose the change made to svnadmin).
Yeah, the `fix' is totally my fault. I made the patch as a quick test
to see if `svnadmin undeltify' worked better that way. Unfortunately,
by the time I'd tested the thing and finished being excited that it
actually worked, I had forgotten that it was the Wrong Fix. :-) I
should have fixed svn_fs_undeltify() instead. Will do, as soon as I
can find time to do so.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 07, 2002 at 02:55:16PM -0500, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
> > On Fri, Jun 07, 2002 at 01:58:28PM -0500, Ben Collins-Sussman wrote:
>...
> > If we branch 2092, then we could also apply fixes in the future to the dump
> > code (should they arise).
>
> That's a good idea. In fact, we *already* have a patch for svnadmin's
> 'undeltify' command that needs to be applied to r2092. It would make
> things a lot easier for folks. (It's mentioned in
> notes/repos_upgrade_HOWTO.)
Yup. I mentioned all that in my response to rev 2110. The above note was a
follow-on to that suggestion. (to mention the possibility that future bugs
on "dump" would have a home)
> Shall I make the branch?
Yes, please.
Note: while I disagree with the fix to the undeltify command, we can
certainly use that on the branch. I think the trunk should fix the
svn_fs_deltify() function properly (and lose the change made to svnadmin).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by Ben Collins-Sussman <su...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> On Fri, Jun 07, 2002 at 01:58:28PM -0500, Ben Collins-Sussman wrote:
> >...
> > The problem you're seeing (I'll bet) is that your dumpfile was
> > produced by an older version of svnadmin -- it dumped too much data.
> > And now you're trying to load the data with the latest svnadmin that
> > doesn't want to see the data ("whattyamean add this file? it's
> > already there, it was part of the copy!")
> >
> > Build yourself a static r2092 binary of svnadmin, and use *that* to
> > make your dumpfile.
>
> If we branch 2092, then we could also apply fixes in the future to the dump
> code (should they arise).
That's a good idea. In fact, we *already* have a patch for svnadmin's
'undeltify' command that needs to be applied to r2092. It would make
things a lot easier for folks. (It's mentioned in
notes/repos_upgrade_HOWTO.)
Shall I make the branch?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jun 07, 2002 at 01:58:28PM -0500, Ben Collins-Sussman wrote:
>...
> The problem you're seeing (I'll bet) is that your dumpfile was
> produced by an older version of svnadmin -- it dumped too much data.
> And now you're trying to load the data with the latest svnadmin that
> doesn't want to see the data ("whattyamean add this file? it's
> already there, it was part of the copy!")
>
> Build yourself a static r2092 binary of svnadmin, and use *that* to
> make your dumpfile.
If we branch 2092, then we could also apply fixes in the future to the dump
code (should they arise).
Oh. And in my previous mail, I suggested making tools/server. I note that
enable-dupkeys.sh could be moved into that directory. Hmm. cgi and cvs2svn
would also go in there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnadmin load error
Posted by Ben Collins-Sussman <su...@collab.net>.
William Uther <wi...@cs.cmu.edu> writes:
> Hi,
> I just started playing with switching to the new repository format.
> "svnadmin dump" worked fine. I only had ~120 revisions so I didn't bother
> redeltifying. Anyway, "svnadmin load" dies...
>
> ------- Committed new rev 62 (loaded from original rev 62) >>>
>
> <<< Started new txn, based on original revision 63
> * adding path : trunk/Papers/Thesis/fig/introb ...COPIED... done.
>
> subversion/libsvn_fs/tree.c:200
> svn_error: #21073 : <Item already exists in filesystem>
> file already exists: filesystem `svnroot/db', transaction `1r', path
> `trunk/Papers/Thesis/fig/introb/rawMaze.graffle'
I'm 90% certain that I know what your problem is, because it looks
exactly like what I've experienced myself.
You see, 'svnadmin dump' used to dump all the files below a copied
subtree, and 'svnadmin load' used to deliberately ignore these files
if the copy went successfully.
We tossed that plan: now 'svnadmin dump' just writes a *single* record
into the dumpfile: "copy this directory", and 'svnadmin load' isn't
deliberately ignoring any records anymore.
The problem you're seeing (I'll bet) is that your dumpfile was
produced by an older version of svnadmin -- it dumped too much data.
And now you're trying to load the data with the latest svnadmin that
doesn't want to see the data ("whattyamean add this file? it's
already there, it was part of the copy!")
Build yourself a static r2092 binary of svnadmin, and use *that* to
make your dumpfile.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org