tags:

views:

229

answers:

4

In a subdirectory of my svn working copy, I do

svn list

I see that there are 6 files in the repository (same as I see with SVNX). Nice. But in my working copy, there are two files, which are from some historical point that I do not remember. So I do

svn update

and it says that all files are up to date to revision 122 (which is the head revision). How can there be a difference between doing an update and a list? More importantly, how can I get those files back without doing a fresh checkout?

I know that the answer will either reveal that I'm a complete newbie OR that svn is a terrible kludge. Personally, I just want to get back to work.

Edit: svn cleanup does nothing at all, and svn status reports nothing at all.

Edit: Here's exactly what I did, since one of the commenters asked.

root@Dans-13:/dans-data/php/nasa-secrets-revealed/trunk/images/testmenu$svn update
At revision 122.
root@Dans-13:/dans-data/php/nasa-secrets-revealed/trunk/images/testmenu$svn list
graph-big0.gif
graph-big1.gif
graph-big2.gif
graph0.gif
graph1.gif
graph2.gif
root@Dans-13:/dans-data/php/nasa-secrets-revealed/trunk/images/testmenu$ls
.svn     graph-big0.gif graph0.gif
+1  A: 

Is there a svn:ignore property set up in the directory?

svn pg svn:ignore .
laalto
No. Just ran svn status --no-ignore and there are no files listed.
Yar
+1  A: 

From what I know of SVN, this is completely impossible and should not happen.

Eventually I ended up doing this: Delete the entire directory from level up and run svn update. Sometimes, the answer is to walk around the problem.

Yar
SVN Clean up not working?
leppie
As I said in the question, I ran svn cleanup as well. Thanks!
Yar
This is equivalent to Stefan's answer. You probably encountered this known bug which causes unintended sparse working copies: http://stackoverflow.com/questions/866835/subversion-using-visualsvn-tortoise-refuses-to-pull-down-new-files/867839#867839
Wim Coenen
@wcoenen, thank you for your comment. The problem is really the time spent figuring out which directory was pointing to a different revision... there was no indication of this with svn info, nor svn list nor anything. Although debugging is fun, I'd prefer to debug when the code is wrong... is there any way to assure a good switch?
Yar
Also, I might mention that it's impossible that I experienced a tortoise bug since I'm using command-line svn in osx. I wish I had Tortoise :)
Yar
+3  A: 

You might have a sparse checkout. Try

svn update --depth infinity --set-depth infinity
Stefan
Yeah, but since I did the original checkout myself, I know that's not the case. I'll upvote you because my problem is with svn, not with helpful SO people.
Yar
a simple 'svn st -v' should show you whether you have a sparse checkout or not.
Stefan
so you're saying that even if I didn't DO a sparse checkout myself, it could happen accidentally?
Yar
That depends on your knowledge of svn - you might not have intended to do it but still done it.
Stefan
What? I never use --depth nor --set-depth. Is it still possible?
Yar
If you *really* never use --depth, then no. But just run 'svn st -v' or 'svn info' on the folder and check. It takes a second to check that, much less than arguing here over and over.
Stefan
Sorry Stefan, I never saw your comment until now (months later). .The reason that I didn't follow your advice was that I had resolved the problem and could NOT check with svn st -v. So my question was academic. Thanks for the help.
Yar
+1  A: 

Or maybe you have done svn switch or svn update -r X in that working copy folder. The output from svn:info could tell you that.

Thanks. svn info revealed that I was pointing to the right place in the repository, and svn update revealed that I was updating to the right rev.
Yar