I'm not sure whether even *CVS* allows you to do a 'checkout' which
overwrites an unversioned tree.  The idea makes my skin crawl. 
Assigning to post-1.0, enhancement.  Let the debate over this happen
later.

Copy of text sent to the mailing list:

"Just a $0.02 on this subject - my ideal 'import' would actually just be a svn add which did not 
require a root wc. it would schedule the whole imported tree for addition, and perhaps would scan 
for things such as mime-type and line endings and set those properties. However, it wouldn't 
affect the repository until I did a commit. This would allow me to have much stronger control over 
my imports, and also would leave me after import with a valid working copy."

Original comment by akuma

Fix summary.

Someone got carried away with platform and OS again.  This applies to All.

Is there any likelihood this will ever make it into subversion?

I've lately had to explain to a number of people new to subversion that after
they have checked in they need to immediately checkout - it always results in a
look of surprise and confusion.

I usually work in eclipse (using the subclipse plugin).  Importing a project
with subclipse does result in the copy i'm importing becoming the working copy,
which begs the question: how does subclipse handle this?  Does it automagically
delete the old copy and checkout a new copy?

Original comment by steveliles

Useful link from the FAQ, in case someone arrives at this bug, as I did, from a
google search.

http://subversion.tigris.org/faq.html#in-place-import

Original comment by steveliles

In Subversion 1.5, 'svn remove' has grown a --keep-local argument.  Adding
something like that to 'checkout' might work here.

I thought this was exactly what Subversion 1.5's 'svn checkout --force' was for?

Yup, I think you're right -- that's a sufficient work-around for this issue.