You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Hanchrow <of...@blarg.net> on 2004/10/04 20:43:44 UTC
[BUG]: "svn: Two top-level reports with no target"
I'm not sure what this means, but ghudson suggests it's a genuine
bug. So:
* 1.1.0 configured with ``./configure --disable-shared --enable-all-static --prefix=/usr/local/stow/svn-1.1.0''
* run on recent Debian sarge
* do these commands
# svn, version 1.1.0 (r11180)
# compiled Oct 4 2004, 13:00:22
rm -rfv /tmp/silly
mkdir -vp /tmp/silly/directory
rm -rf /tmp/bug
svnadmin create /tmp/bug
svn co file:///tmp/bug
cd bug
svn import /tmp/silly file:///tmp/bug/vendor/silly/current -m
"importing silly vendor drop"
cd vendor/silly
svn up
# svn: Two top-level reports with no target
And you'll see the message.
--
Tobacco: It's not just for killing children anymore.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [BUG]: "svn: Two top-level reports with no target"
Posted by Eric Hanchrow <of...@blarg.net>.
>>>>> "Greg" == Greg Hudson <gh...@MIT.EDU> writes:
Greg> (1) What is the desired behavior here?
An error. I'm not entirely sure what "obstructed update" means, so I
don't know if that's the appropriate error, but I cannot think of a
good reason why someone would do what I did -- I think it's always a
mistake, and therefore svn should do nothing except inform the user of
their mistake.
Greg> We could make the client notice that the current directory
Greg> is locally added and do nothing, or error out.
The error seems preferable.
--
Google is using guile to re-create a guileless world ...
-- James Surowiecki
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [BUG]: "svn: Two top-level reports with no target"
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 4, 2004, at 4:33 PM, Greg Hudson wrote:
>
> (1) What is the desired behavior here? If you were to "svn up foo"
> from the parent, you'd either get a no-op update or an obstructed
> update, depending on whether foo exists in the repository's head.
If the schedule-add directory is either the explicit anchor or explicit
target of an update, then I think we should print an error. It's
nonsensical to try to update something that only exists in a working
copy.
If a schedule-add directory is encountered while sending a recursive
report, then it should be skipped over, I think.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [BUG]: "svn: Two top-level reports with no target"
Posted by Greg Hudson <gh...@MIT.EDU>.
Here's a simpler reproduction recipe. Within any existing svn working
directory:
svn mkdir foo
cd foo
svn up
So, the bug is that updates from within a locally-added directory don't
work. svn_wc_crawl_revisions() generates a report which reporter.c
doesn't like. The API documentation in svn_ra.h says you can only make
two report calls on the top-level path "if the target of the operation
is deleted or switched relative to the anchor," which isn't true in this
case.
Two questions, then:
(1) What is the desired behavior here? If you were to "svn up foo"
from the parent, you'd either get a no-op update or an obstructed
update, depending on whether foo exists in the repository's head.
(2) Based on the answer to (1) above, what's the appropriate code
change? We could make the client notice that the current directory is
locally added and do nothing, or error out. We could make reporter.c
tolerate this kind of report, but I think that would result in a
locally-added directory with updated repository contents, which would be
bizarre and would probably fail later on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [BUG]: "svn: Two top-level reports with no target" -- corrected
repro recipe
Posted by Eric Hanchrow <of...@blarg.net>.
I left out a couple of crucial lines in that recipe. Here's the
corrected version:
# svn, version 1.1.0 (r11180)
# compiled Oct 4 2004, 13:00:22
cd /tmp
rm -rfv silly vendor bug
mkdir -vp silly/directory
svnadmin create bug
svn co file:///tmp/bug
cd bug
svn mkdir vendor
svn mkdir vendor/silly
svn import /tmp/silly file:///tmp/bug/vendor/silly/current -m
"importing silly vendor drop"
cd vendor/silly
svn up
# svn: Two top-level reports with no target
--
The whole point of loud music is to make it possible
to date without talking.
-- Roger Ebert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [BUG]: "svn: Two top-level reports with no target"
Posted by Philip Martin <ph...@codematters.co.uk>.
Eric Hanchrow <of...@blarg.net> writes:
> I'm not sure what this means, but ghudson suggests it's a genuine
> bug. So:
>
> * 1.1.0 configured with ``./configure --disable-shared --enable-all-static --prefix=/usr/local/stow/svn-1.1.0''
> * run on recent Debian sarge
> * do these commands
>
> # svn, version 1.1.0 (r11180)
> # compiled Oct 4 2004, 13:00:22
>
> rm -rfv /tmp/silly
> mkdir -vp /tmp/silly/directory
>
> rm -rf /tmp/bug
> svnadmin create /tmp/bug
>
> svn co file:///tmp/bug
> cd bug
> svn import /tmp/silly file:///tmp/bug/vendor/silly/current -m
> "importing silly vendor drop"
> cd vendor/silly
The line above doesn't make sense, vendor/silly doesn't exist.
Are you perhaps checking out over an existing working copy? That's a
mistake as you have recreated the repository, although I seem to
recall a bug that means we don't check the UUID?
> svn up
>
> # svn: Two top-level reports with no target
>
> And you'll see the message.
What message?
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org