You were correct about the working copy. After running svn update,
svn cat was no longer able to print the deleted file.
I guess I should have read the whole book. The command reference
chapter gives command syntax as svn cat TARGET[@REV] and lists the
switch --revision (-r) REV, but does not hint that the two ways of
specifying REV mean different things. Oh well, now I know. Thanks
On Apr 30, 2007, at 7:04 PM, Ryan Schmidt wrote:
> On Apr 30, 2007, at 17:27, Andrew Miller wrote:
>> I have a file, say "stuff.txt" that existed in my repository in
>> revision 10 that was subsequently deleted in revision 11.
>> If I run
>> svn cat file:///repository/stuff.txt --revision 10
>> svn cat file:///repository/stuff.txt -r 10
>> I get a message saying:
>> svn: File not found: revision 11, path 'stuff.txt'
>> on the other hand running
>> svn cat file:///repository/stuff.txt_at_10
>> works fine and prints the content of the file stuff.txt
>> Other svn subcommands, for example svn info or svn log exhibit the
>> same behavior.
>> Putting the command switches before the URL had no effect.
> This behavior is correct. It's the difference between the operative
> revision and the peg revision. There's a whole chapter on this in
> the book:
>> Running svn cat stuff.txt -r 10 on a working copy did cause the
>> file to be printed.
>> Seems like this is a bug in handling the --revision and -r options
>> for deleted files in the repository.
> I was initially confused why -r 10 would have shown you revision 10
> of the file when in the working copy. But I imagine this is because
> your working copy is not at revision 11 yet. Try "svn up" to update
> the working copy to revision 11. Then "svn cat stuff.txt -r 10"
> should no longer work, which would be expected.
> To reply to the mailing list, please use your mailer's Reply To All
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue May 1 02:32:27 2007