You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ronald Simmons <Va...@thesimmonses.net> on 2002/06/11 03:36:16 UTC
problem with dump/load conversion
I "svnadmin dumped" my repository with R2092 compiled on solaris 8 with
apr from the cvs tree this past friday. The dump went fine, no error
messages.
I then went to "svnadmin load" with R2142 compiled with exactly the same
APR on solaris 8 and get the following:
------- Committed new rev 14 (loaded from original rev 14) >>>
<<< Started new txn, based on original revision 15
* editing path : Development/Perl/cgi/Credit/spreads.pl ... done.
------- Committed new rev 15 (loaded from original rev 15) >>>
<<< Started new txn, based on original revision 16
svn_error: #21066 : <Filesystem has no item>
file not found: transaction `g', path `Test/Perl/cgi/Credit/spreads.pl'
* deleting path : Test/Perl/cgi/Credit/spreads.pl ...Broken Pipe
Interestingly this file exists in this location because of an earlier
svn cp from the file which is edited in Rev 15. It's as if load is
confused about rm'ing a copied file? anyone have any thoughts on where
in the source I can start to track this one down or what other
information I can provide to help?
rvs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: problem with dump/load conversion
Posted by Ronald Simmons <Va...@thesimmonses.net>.
On Wednesday, June 12, 2002, at 05:24 PM, Philip Martin wrote:
> Ronald Simmons <Va...@thesimmonses.net> writes:
>
>> IMHO, 'svn cp URL URL' should either do a replace for both dirs and
>> files if the target exists, or it should fail for both, with my
>> preference for the replace (after all I'll just do the 'svn rm' first
>> if it doesn't behave that way). I suspect that failing for both is
>> going to be the preference of other people here, though, since
>> otherwise the URL->URL semantics might become inconsistent with the
>> WC->WC semantics.
>
> Yup :) I don't think replace should be the default, if I mistype the
> second URL I don't want to accidentally delete some existing URL. If
> replacing is allowed it should only be enabled with a --force flag
>
As soon as I hit send on that previous message, I thought: "you know, a
--force flag would actually be what you want." :^)
rvs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: problem with dump/load conversion
Posted by Philip Martin <ph...@codematters.co.uk>.
Ronald Simmons <Va...@thesimmonses.net> writes:
> IMHO, 'svn cp URL URL' should either do a replace for both dirs and
> files if the target exists, or it should fail for both, with my
> preference for the replace (after all I'll just do the 'svn rm' first
> if it doesn't behave that way). I suspect that failing for both is
> going to be the preference of other people here, though, since
> otherwise the URL->URL semantics might become inconsistent with the
> WC->WC semantics.
Yup :) I don't think replace should be the default, if I mistype the
second URL I don't want to accidentally delete some existing URL. If
replacing is allowed it should only be enabled with a --force flag
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: problem with dump/load conversion
Posted by Ronald Simmons <Va...@thesimmonses.net>.
On Wednesday, June 12, 2002, at 12:24 PM, Ben Collins-Sussman wrote:
>
>
> A. 'svn cp' behavior
>
> Apparently libsvn_fs cheerfully allows destination overwrites when
> copying things. That is, if you use svn_fs_copy() to copy a file or
> directory, any entry which has the same name in the destination will
> be *removed*, and *overwritten* with the new item.
>
> According to cmpilato, this is an intentional fs design decision; I
> wasn't aware of it, but whatever. So be it.
>
> Because of this fs behavior, our client libraries do a number of
> "sanity checks" to prevent this behavior, when doing 'svn cp URL
> URL' in particular. The client libs will throw an error if the
> destination file already exists. However, the libs are *not*
> detecting the case when a destination directory already exists!
> Directories are just silently replaced.
>
> I don't like this at all. This is backwards from unix cp
> semantics. IIRC, unix cp allows you to overwrite files, but not
> dirs. Why are we doing it the other way around? I'm going to file
> an issue on this.
>
Actually unix "cp -r" of a directory does something similar to svn merge
(which I didn't fully appreciate until I just played with it). Without
the -r flag it just won't copy a directory at all. So I agree that the
current behavior seems either totally backwards or at least
inconsistent, depending on your point of view.
IMHO, 'svn cp URL URL' should either do a replace for both dirs and
files if the target exists, or it should fail for both, with my
preference for the replace (after all I'll just do the 'svn rm' first if
it doesn't behave that way). I suspect that failing for both is going
to be the preference of other people here, though, since otherwise the
URL->URL semantics might become inconsistent with the WC->WC semantics.
This problem goes beyond the dumper/loader issue, though. The bigger
problem for me is that the client doesn't deal well at all with the
current server side behavior. Replacing a whole dir via 'svn cp URL
URL' then doing an 'svn up' in another WC, just causes a client side
failure which then needs manual intervention to deal with. It seems to
me that legal operations on the server side should, as a rule, not cause
the client to automatically fail a legal client operation.
Usually what I do with the current 'svn cp URL URL' behavior, is, on the
client side, go and rename the dir that has been replaced to get it out
of the way, then 'svn cleanup; svn up'. lather/rinse/repeat for every
directory that may have been promoted. A nicer thing would be for the
client to detect the server side replace, automagically do the rename
for me (maybe to something.svn-backup for example), tell me it did that,
and successfully complete the 'svn up'. Again, I can see where others
might prefer something else.
The current behavior is a problem for my users though since they never
understand the client side failure message they see when this happens
(after every promotion I do) and I have to go and fix it for all of them
as well.. :^(
>
> B. Two kinds of 'replace'.
>
> Ronald Simmons thought that it was totally normal for 'svn cp URL
> URL' to overwrite destination directories. He was issuing this
> command over and over as a way of promoting code from one branch to
> another, rather than using 'svn merge' to port changes.
>
Don't know that I thought it was totally normal, but I kinda liked the
way it worked. :^)
rvs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: problem with dump/load conversion
Posted by Ben Collins-Sussman <su...@collab.net>.
Ronald Simmons <Va...@thesimmonses.net> writes:
> I "svnadmin dumped" my repository with R2092 compiled on solaris 8
> with apr from the cvs tree this past friday. The dump went fine, no
> error messages.
>
> I then went to "svnadmin load" with R2142 compiled with exactly the
> same APR on solaris 8 and get the following:
OK Ron, I fixed the dumper in both HEAD and in our r2092 branch. What
you need to do is checkout the r2092 branch, build it statically, and
try re-dumping your repository with its svnadmin. No more bogus
dumpfile.
Then presumably you'd build HEAD, create a new-style repository, and
'svnadmin load' the dumpfile into it. Let us know how it goes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: problem with dump/load conversion
Posted by Ben Collins-Sussman <su...@collab.net>.
Ronald Simmons <Va...@thesimmonses.net> writes:
> I "svnadmin dumped" my repository with R2092 compiled on solaris 8
> with apr from the cvs tree this past friday. The dump went fine, no
> error messages.
>
> I then went to "svnadmin load" with R2142 compiled with exactly the
> same APR on solaris 8 and get the following:
>
>
> ------- Committed new rev 14 (loaded from original rev 14) >>>
>
> <<< Started new txn, based on original revision 15
> * editing path : Development/Perl/cgi/Credit/spreads.pl ... done.
>
> ------- Committed new rev 15 (loaded from original rev 15) >>>
>
> <<< Started new txn, based on original revision 16
>
> svn_error: #21066 : <Filesystem has no item>
> file not found: transaction `g', path `Test/Perl/cgi/Credit/spreads.pl'
> * deleting path : Test/Perl/cgi/Credit/spreads.pl ...Broken Pipe
>
> Interestingly this file exists in this location because of an earlier
> svn cp from the file which is edited in Rev 15. It's as if load is
> confused about rm'ing a copied file? anyone have any thoughts on
> where in the source I can start to track this one down or what other
> information I can provide to help?
Can we see your dumpfile?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org