Recommendation for creating a repo of "docroot"

I asked this on #svn so sorry if you already saw this. This is kind
of a general "what would you do?" question.

I'd like to move a client's website to subversion. They have all been
using FTP to update the site, and for a number of obvious reasons I
think they would be better off keeping working copies on their own
machines/accounts than updating the docroot directly as they are now.

My concern is that the content is now about 5GB and about 6000 files
and a mix of mostly binary and some text content, and I'm sure most of
them don't want to check all that out onto their laptops.

So, I'm looking for suggestions how to create the repository. Should
the repository contain everything, or just the text files that they
will be mostly interested in updating?

If just a sub-set of files, then how best to create that repo?
Manually copy the 1700 or so text files to a new directory tree, then
import that tree? Then cp the old docroot on top of the new tree and
go crazy with svn ignore? That could be a bit of work just keeping
the svn ignore properties updated.

What would you do in this situation?

Thanks,

-- 
Bill Moseley
moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org