You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jason Kealey <jk...@shade.ca> on 2006/04/11 20:50:46 UTC
propget on deleted files... bug?
Hi, this is my second request to the list; the first one to users got no
replies. Please tell me if something is not clear.
Goal: I would like to know the svn:mime-type of a certain file that has been
deleted, without actually checking it out to the working folder.
I tried various command line arguments, for example:
svn propget svn:mime-type filename@rev
This works, if the file exists in the working folder. I can't seem to give a
URL instead of a relative path other than when asking for revision
properties (--revprop). Passing a URL worked for svn diff, for example, when
a file had been deleted. The command line tool has a -r option, but this
only works when asking for a revision property.
Is this a bug, a feature, or am I doing something wrong (when I first tried,
I was using the 1.3.0 command line client) ? My intuition is that this would
not yet be implemented and if so, I was wondering if it would be worthwhile
to file a feature request or if this was just one symptom of a whole series
of issues with deleted files.
Note: does buying Karl Fogel's newest book increase my changes of getting a
reply? :)
Thanks for your time,
Jason Kealey
jkealey@shade.ca
http://corp.shade.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: propget on deleted files... bug?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/17/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 4/16/06, Jason Kealey <jk...@shade.ca> wrote:
> > Here are some reproduction steps. I have prefixed the Output with ** in
> > order to quickly identify the problematic situations.
> >
> > The platform is Windows Server 2003 (repro steps can be trivially changed to
> > work on other OSes).
> >
> > I am using:
> > svn, version 1.3.1 (r19032)
> > compiled Mar 30 2006, 02:41:28
> >
> > In your main folder (ex: c:\svn\)
> > svnadmin create mockup
> > (setup auth with harry/harryssecret in conf directory)
> >
> >
> > In a temp folder (ex: c:\temp\)
> > svn co --username harry --password harrysecret svn://localhost/mockup
> >
> > cd mockup
> > svn propget svn:mime-type svn://localhost/mockup/not_here@0
> > ( **Output: svn: Unknown node kind for 'svn://localhost/mockup/not_here' )
> > ( Same happens if used bdb instead of fsfs)
> >
>
> Ok, that's a bit weird. I'll see what I can do about that.
Fixed in r19399.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: propget on deleted files... bug?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/16/06, Jason Kealey <jk...@shade.ca> wrote:
> Here are some reproduction steps. I have prefixed the Output with ** in
> order to quickly identify the problematic situations.
>
> The platform is Windows Server 2003 (repro steps can be trivially changed to
> work on other OSes).
>
> I am using:
> svn, version 1.3.1 (r19032)
> compiled Mar 30 2006, 02:41:28
>
> In your main folder (ex: c:\svn\)
> svnadmin create mockup
> (setup auth with harry/harryssecret in conf directory)
>
>
> In a temp folder (ex: c:\temp\)
> svn co --username harry --password harrysecret svn://localhost/mockup
>
> cd mockup
> svn propget svn:mime-type svn://localhost/mockup/not_here@0
> ( **Output: svn: Unknown node kind for 'svn://localhost/mockup/not_here' )
> ( Same happens if used bdb instead of fsfs)
>
Ok, that's a bit weird. I'll see what I can do about that.
> dir > file.txt
> svn add file.txt
> svn commit --message test
>
> svn propget svn:mime-type svn://localhost/mockup/not_here@0
> ( **Output: svn: Unknown node kind for 'svn://localhost/mockup/not_here' )
> svn propget svn:mime-type svn://localhost/mockup/not_here@1
> ( **Output: svn: Unknown node kind for 'svn://localhost/mockup/not_here' )
> svn propget svn:mime-type svn://localhost/mockup/file.txt@0
> ( **Output: svn: Unknown node kind for 'svn://localhost/mockup/file.txt' )
> svn propget svn:mime-type -r 0 file.txt
> ( Output: svn: Unable to find repository location for 'file.txt' in
> revision 0 )
> svn propget svn:mime-type -r 0 file.txt@0
> ( **Output: svn: Unknown node kind for 'svn://localhost/mockup/file.txt' )
> svn propget svn:mime-type svn://localhost/mockup/file.txt@1
> ( Output: is blank (okay because file.txt is not a binary file) )
> svn propget svn:mime-type file.txt@1
> ( Output: is blank (okay because file.txt is not a binary file) )
> svn propget svn:mime-type file.txt@0
> ( Output: is blank (looks odd to me, but it may be due to the fact I don't
> understand the difference between the -r REV and @REV issue) )
>
> copy c:\windows\notepad.exe .
> svn add notepad.exe
> ( Output: A (bin) notepad.exe (shows the file is binary) )
> svn commit --message test2
>
>
> svn propget svn:mime-type notepad.exe
> ( Output: application/octet-stream (confirmation, mime-type was set))
> svn propget svn:mime-type notepad.exe@0
> ( Output: application/octet-stream (See ### below) )
> svn propget svn:mime-type notepad.exe@1
> ( Output: application/octet-stream (See ### below) )
> svn propget svn:mime-type notepad.exe@1136253
> ( Output: application/octet-stream (See ### below) )
> svn propget svn:mime-type -r 2 notepad.exe
> ( Output: application/octet-stream (okay))
> svn propget svn:mime-type -r 1 notepad.exe
> ( Output: svn: Unable to find repository location for 'notepad.exe' in
> revision 1 (good error message))
> svn propget svn:mime-type -r 1 notepad.exe@1
> ( **Output: svn: Unknown node kind for
> 'svn://localhost/mockup/notepad.exe' )
> svn propget svn:mime-type -r 2 notepad.exe@1
> ( **Output: svn: File not found: revision 1, path '/notepad.exe' (See ###
> below) )
> svn propget svn:mime-type svn://localhost/mockup/notepad.exe@0
> ( **Output: svn: Unknown node kind for
> 'svn://localhost/mockup/notepad.exe')
> svn propget svn:mime-type svn://localhost/mockup/notepad.exe@1
> ( **Output: svn: Unknown node kind for
> 'svn://localhost/mockup/notepad.exe')
> svn propget svn:mime-type svn://localhost/mockup/notepad.exe@2
> ( Output: application/octet-stream )
> svn propget svn:mime-type svn://localhost/mockup/notepad.exe@3
> ( Output: svn: No such revision 3)
>
> svn delete notepad.exe
> svn ci --message deleted
>
>
> svn propget svn:mime-type notepad.exe
> ( Output: svn: 'notepad.exe' is not under version control)
> svn propget svn:mime-type notepad.exe@2
> ( Output: svn: 'notepad.exe' is not under version control)
> svn propget svn:mime-type svn://localhost/mockup/notepad.exe@2
> ( Output: application/octet-stream)
> svn propget svn:mime-type svn://localhost/mockup/notepad.exe@1
> ( **Output: svn: Unknown node kind for
> 'svn://localhost/mockup/notepad.exe')
> svn propget svn:mime-type -r 2 svn://localhost/mockup/notepad.exe
> ( Output: svn: File not found: revision 3, path '/notepad.exe' (See ###
> below))
>
> svn propget svn:mime-type --revprop -r 2 notepad.exe
> ( Output: svn: Either a URL or versioned item is required (this is the
> first thing I tried, before learning what --revprop was for)
> svn propget svn:mime-type --revprop -r 2 svn://localhost/mockup/notepad.exe
> ( Output: none. Confused me at first, I thought I had the right syntax,
> but the file didn't have an svn:mime-type)
It has nothign to do with the syntax, it's the fact that svn:mime-type
is not a revprop, so asking for a revprop by that name will get you
nothing.
> ###: These look odd to me, but it may be due to the fact I don't understand
> the difference between the -r REV and @REV issue; is there documentation
> somewhere so that I can read up on this?
There should be a section on peg revisions in http://svnbook.org/
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: propget on deleted files... bug?
Posted by Jason Kealey <jk...@shade.ca>.
Here are some reproduction steps. I have prefixed the Output with ** in
order to quickly identify the problematic situations.
The platform is Windows Server 2003 (repro steps can be trivially changed to
work on other OSes).
I am using:
svn, version 1.3.1 (r19032)
compiled Mar 30 2006, 02:41:28
In your main folder (ex: c:\svn\)
svnadmin create mockup
(setup auth with harry/harryssecret in conf directory)
In a temp folder (ex: c:\temp\)
svn co --username harry --password harrysecret svn://localhost/mockup
cd mockup
svn propget svn:mime-type svn://localhost/mockup/not_here@0
( **Output: svn: Unknown node kind for 'svn://localhost/mockup/not_here' )
( Same happens if used bdb instead of fsfs)
dir > file.txt
svn add file.txt
svn commit --message test
svn propget svn:mime-type svn://localhost/mockup/not_here@0
( **Output: svn: Unknown node kind for 'svn://localhost/mockup/not_here' )
svn propget svn:mime-type svn://localhost/mockup/not_here@1
( **Output: svn: Unknown node kind for 'svn://localhost/mockup/not_here' )
svn propget svn:mime-type svn://localhost/mockup/file.txt@0
( **Output: svn: Unknown node kind for 'svn://localhost/mockup/file.txt' )
svn propget svn:mime-type -r 0 file.txt
( Output: svn: Unable to find repository location for 'file.txt' in
revision 0 )
svn propget svn:mime-type -r 0 file.txt@0
( **Output: svn: Unknown node kind for 'svn://localhost/mockup/file.txt' )
svn propget svn:mime-type svn://localhost/mockup/file.txt@1
( Output: is blank (okay because file.txt is not a binary file) )
svn propget svn:mime-type file.txt@1
( Output: is blank (okay because file.txt is not a binary file) )
svn propget svn:mime-type file.txt@0
( Output: is blank (looks odd to me, but it may be due to the fact I don't
understand the difference between the -r REV and @REV issue) )
copy c:\windows\notepad.exe .
svn add notepad.exe
( Output: A (bin) notepad.exe (shows the file is binary) )
svn commit --message test2
svn propget svn:mime-type notepad.exe
( Output: application/octet-stream (confirmation, mime-type was set))
svn propget svn:mime-type notepad.exe@0
( Output: application/octet-stream (See ### below) )
svn propget svn:mime-type notepad.exe@1
( Output: application/octet-stream (See ### below) )
svn propget svn:mime-type notepad.exe@1136253
( Output: application/octet-stream (See ### below) )
svn propget svn:mime-type -r 2 notepad.exe
( Output: application/octet-stream (okay))
svn propget svn:mime-type -r 1 notepad.exe
( Output: svn: Unable to find repository location for 'notepad.exe' in
revision 1 (good error message))
svn propget svn:mime-type -r 1 notepad.exe@1
( **Output: svn: Unknown node kind for
'svn://localhost/mockup/notepad.exe' )
svn propget svn:mime-type -r 2 notepad.exe@1
( **Output: svn: File not found: revision 1, path '/notepad.exe' (See ###
below) )
svn propget svn:mime-type svn://localhost/mockup/notepad.exe@0
( **Output: svn: Unknown node kind for
'svn://localhost/mockup/notepad.exe')
svn propget svn:mime-type svn://localhost/mockup/notepad.exe@1
( **Output: svn: Unknown node kind for
'svn://localhost/mockup/notepad.exe')
svn propget svn:mime-type svn://localhost/mockup/notepad.exe@2
( Output: application/octet-stream )
svn propget svn:mime-type svn://localhost/mockup/notepad.exe@3
( Output: svn: No such revision 3)
svn delete notepad.exe
svn ci --message deleted
svn propget svn:mime-type notepad.exe
( Output: svn: 'notepad.exe' is not under version control)
svn propget svn:mime-type notepad.exe@2
( Output: svn: 'notepad.exe' is not under version control)
svn propget svn:mime-type svn://localhost/mockup/notepad.exe@2
( Output: application/octet-stream)
svn propget svn:mime-type svn://localhost/mockup/notepad.exe@1
( **Output: svn: Unknown node kind for
'svn://localhost/mockup/notepad.exe')
svn propget svn:mime-type -r 2 svn://localhost/mockup/notepad.exe
( Output: svn: File not found: revision 3, path '/notepad.exe' (See ###
below))
svn propget svn:mime-type --revprop -r 2 notepad.exe
( Output: svn: Either a URL or versioned item is required (this is the
first thing I tried, before learning what --revprop was for)
svn propget svn:mime-type --revprop -r 2 svn://localhost/mockup/notepad.exe
( Output: none. Confused me at first, I thought I had the right syntax,
but the file didn't have an svn:mime-type)
###: These look odd to me, but it may be due to the fact I don't understand
the difference between the -r REV and @REV issue; is there documentation
somewhere so that I can read up on this?
I also included a few steps that I had tried just in case someone likes to
update documentation after reading common user mistakes.
As you can see, the error message doesn't depend on the file being deleted,
it having a certain property set or even having ever existed. I am very
surprised by the inconsistencies, but this may be because of ###.
Thanks,
Jason
-----Original Message-----
From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of Garrett Rooney
Sent: April 14, 2006 2:17 PM
To: Jason Kealey
Cc: Jody Shumaker; dev@subversion.tigris.org
Subject: Re: propget on deleted files... bug?
On 4/13/06, Jason Kealey <jk...@shade.ca> wrote:
> Thank you both for your input. Doing more research, I discovered it was my
> mistake, as I had tried all of these before, but with an error in my URL.
I
> had written a half a dozen test cases, all with the same slip-up in the
> directory structure.
>
> To clear things up, it doesn't seem that the -r argument is required when
> using a URL; hence the documentation is correct.
>
> However, when I re-ran my (erroneous) test cases, I got the following
> output:
>
> svn propget svn:mime-type svn://yourserver/repo/any/path@1422
> svn: Unknown node kind for 'svn://yourserver/repo/any/path'
>
> I personally thought this cryptic error message meant the syntax wasn't
well
> understood and moved on to another attempt. Could this error message be
made
> clearer to prevent bumbling fools like myself from bothering you?
>
> Here are some examples of error messages that are much clearer:
> svn: Unrecognized URL scheme for 'dsvn://yourserver/repo/any/path'
> svn: Unknown hostname 'yourserver-invalid'
> svn: No repository found in 'svn://yourserver/typo/any/path'
>
> To an end user, the latter three messages make sense, but the first one
does
> not.
Can you give a reproduction recipie that produces that error message
(ideally a set of commands that creates a new repository, gets it into
the appropriate state, and then runs the command that shows the
problem). With that in hand it would be pretty simple to improve the
error message.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: propget on deleted files... bug?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/13/06, Jason Kealey <jk...@shade.ca> wrote:
> Thank you both for your input. Doing more research, I discovered it was my
> mistake, as I had tried all of these before, but with an error in my URL. I
> had written a half a dozen test cases, all with the same slip-up in the
> directory structure.
>
> To clear things up, it doesn't seem that the -r argument is required when
> using a URL; hence the documentation is correct.
>
> However, when I re-ran my (erroneous) test cases, I got the following
> output:
>
> svn propget svn:mime-type svn://yourserver/repo/any/path@1422
> svn: Unknown node kind for 'svn://yourserver/repo/any/path'
>
> I personally thought this cryptic error message meant the syntax wasn't well
> understood and moved on to another attempt. Could this error message be made
> clearer to prevent bumbling fools like myself from bothering you?
>
> Here are some examples of error messages that are much clearer:
> svn: Unrecognized URL scheme for 'dsvn://yourserver/repo/any/path'
> svn: Unknown hostname 'yourserver-invalid'
> svn: No repository found in 'svn://yourserver/typo/any/path'
>
> To an end user, the latter three messages make sense, but the first one does
> not.
Can you give a reproduction recipie that produces that error message
(ideally a set of commands that creates a new repository, gets it into
the appropriate state, and then runs the command that shows the
problem). With that in hand it would be pretty simple to improve the
error message.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: propget on deleted files... bug?
Posted by Jason Kealey <jk...@shade.ca>.
Thank you both for your input. Doing more research, I discovered it was my
mistake, as I had tried all of these before, but with an error in my URL. I
had written a half a dozen test cases, all with the same slip-up in the
directory structure.
To clear things up, it doesn't seem that the -r argument is required when
using a URL; hence the documentation is correct.
However, when I re-ran my (erroneous) test cases, I got the following
output:
svn propget svn:mime-type svn://yourserver/repo/any/path@1422
svn: Unknown node kind for 'svn://yourserver/repo/any/path'
I personally thought this cryptic error message meant the syntax wasn't well
understood and moved on to another attempt. Could this error message be made
clearer to prevent bumbling fools like myself from bothering you?
Here are some examples of error messages that are much clearer:
svn: Unrecognized URL scheme for 'dsvn://yourserver/repo/any/path'
svn: Unknown hostname 'yourserver-invalid'
svn: No repository found in 'svn://yourserver/typo/any/path'
To an end user, the latter three messages make sense, but the first one does
not.
Thanks again,
Jason Kealey
-----Original Message-----
From: Jody Shumaker [mailto:jody.shumaker@gmail.com]
Sent: April 13, 2006 10:54 PM
To: Garrett Rooney
Cc: Jason Kealey; dev@subversion.tigris.org
Subject: Re: propget on deleted files... bug?
> Peg revisions still respect the default -r setting, the @rev is only
> used to figure out what item you're getting the prop for, it still
> tries to get it from the version in HEAD (or BASE or something like
> that).
>
> -garrett
>
HEAD for a url and BASE from a working copy I believe. Which would
perfectly explain the behavior he describes, from a working copy where
the file works then the default -r BASE is a valid revision, but for a
url it never works without specifying something besides HEAD.
- Jody
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: propget on deleted files... bug?
Posted by Jody Shumaker <jo...@gmail.com>.
> Peg revisions still respect the default -r setting, the @rev is only
> used to figure out what item you're getting the prop for, it still
> tries to get it from the version in HEAD (or BASE or something like
> that).
>
> -garrett
>
HEAD for a url and BASE from a working copy I believe. Which would
perfectly explain the behavior he describes, from a working copy where
the file works then the default -r BASE is a valid revision, but for a
url it never works without specifying something besides HEAD.
- Jody
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: propget on deleted files... bug?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/11/06, Jason Kealey <jk...@shade.ca> wrote:
> Hi, this is my second request to the list; the first one to users got no
> replies. Please tell me if something is not clear.
>
> Goal: I would like to know the svn:mime-type of a certain file that has been
> deleted, without actually checking it out to the working folder.
>
> I tried various command line arguments, for example:
>
> svn propget svn:mime-type filename@rev
Try svn propget svn:mime-type -r rev filename@rev
Peg revisions still respect the default -r setting, the @rev is only
used to figure out what item you're getting the prop for, it still
tries to get it from the version in HEAD (or BASE or something like
that).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org