New - cannot checkout directly removed directories

http://subversion.tigris.org/issues/show_bug.cgi?id=2943

                 Issue #|2943
                 Summary|cannot checkout directly removed
directories
               Component|subversion
                 Version|1.4.x
                Platform|All
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P2
            Subcomponent|libsvn_client
             Assigned to|issuessubversion
             Reported by|fabien






------- Additional comments from fabientigris.org Mon Sep 24 01:32:59 -0700 2007 -------
With 1.4.4, the --revision option seems ignored by checkout
and ls
for path which have been removed...

The same bug occurs with "http:" urls.

#! /bin/sh
# $Id: bug_checkout_old.sh 537 2007-09-24 08:17:48Z coelho
$

REPOS=/tmp/repos
REPURL=file://$REPOS

test -d $REPOS && rm -rf $REPOS
svnadmin create $REPOS
svn mkdir -m 'mkdir ...' $REPURL/trunk $REPURL/branches
$REPURL/tags
svn co -r $REPURL/branches /tmp/b1
# ok

svn rm -m 'rm branches' $REPURL/branches

svn ls -r 1 $REPURL
# ok, see trunk, branches and tags

svn co -r 1 $REPURL/branches /tmp/b2
# svn: File not found: revision 2, path '/branches'
# it seems that the revision number is ignored
# although branches does exists at revision 1

svn ls -r 1 $REPURL/branches
# svn: File not found: revision 2, path '/branches'
# idem

#rm -rf /tmp/b1 /tmp/b2

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2943




User malcolm changed the following:

                What    ld value 
               |New value
============================================================
====================
                  Status|NEW                      
|RESOLVED
------------------------------------------------------------
--------------------
              Resolution|                         
|WORKSFORME
------------------------------------------------------------
--------------------




------- Additional comments from malcolmtigris.org Mon Sep 24 01:54:14 -0700 2007 -------
In all cases, you need to specify a peg revision.  (and
since the operative
revision defaults to the peg revision, you can omit the -rN
as well).

e.g.
svn co $REPURL/branches1 /tmp/b2

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2943




User fabien changed the following:

                What    ld value 
               |New value
============================================================
====================
                  Status|RESOLVED                 
|REOPENED
------------------------------------------------------------
--------------------
              Resolution|WORKSFORME                |
------------------------------------------------------------
--------------------




------- Additional comments from fabientigris.org Mon Sep 24 07:18:02 -0700 2007 -------
You are telling me that there exists another syntax which
works fine.
Thus it is to say that

  svn ls URLN

and

  svn ls -r N URL

are not the same, this looks like a bug to me anyway,
because ISTM that they
should, or the error message should be much clearer about
where the problem is,
or the -r option should be rejected by "svn ls",
or whatever...

For instance the -r options works properly for the first
directory.

fabien> svn -r 1 ls file:///tmp/repos/
branches/
tags/
trunk/

Okay, there is a "branches", let us have a look...
well no.

fabien> svn -r 1 ls file:///tmp/repos/branches
svn: File not found: revision 2, path '/branches'

So I disagree with the "Works For Me" point of
view.
I rather see it as a "I can get around it", which
is not the same.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2943




User malcolm changed the following:

                What    ld value 
               |New value
============================================================
====================
                  Status|REOPENED                 
|RESOLVED
------------------------------------------------------------
--------------------
              Resolution|                          |INVALID
------------------------------------------------------------
--------------------




------- Additional comments from malcolmtigris.org Mon Sep 24 07:33:38 -0700 2007 -------
'svn ls -r N URL' is the same as 'svn ls -r N URLHEAD',
i.e. 'list the contents
of the directory identified by URL in the current HEAD as it
was as rN'.  Since
URL doesn't exist in HEAD, you get the error message
"File not found: revision
2, path '/branches'".

You're right that it could be clearer about what it's doing
(telling you that
it's implicitly looking up /branches at HEAD, and that HEAD
is r2 in this case),
but at some point we need to assume that the user
understands what's going on.

A fuller description of the issue is in the Subversion book,
e.g.
http://svnbook.red-bean.com/en/1.4/svn.advanced.pegr
evs.html

As you point out, this isn't WORKSFORME; it's INVALID. 
Re-closing as such.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2943







------- Additional comments from fabientigris.org Mon Sep 24 08:50:10 -0700 2007 -------
Thanks for the pointer, I'll read that carefully.

> 'svn ls -r N URL' is the same as 'svn ls -r N URLHEAD':

I would intuitively, as you have guessed, have expected the
default to be "svn
ls -rN URLN", and that this "intuitive behavior"
(from my point of view of
doing a simple ls descent and getting stuck in the
filesystem) would be the
default, and the "surprising behavior" (mixing two
different revisions, one for
the location and one for the file status) would have to be
required explicitely. 
I cannot see any practical situation where I would actually
want that. 
I guess I lack imagination.

Thanks again anyway.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org