Will this be horribly inefficient right now?

I do development work on several different computers. I use my version
control system as a sort of distributed filesystem where I have to
explicitly update the server's copy of all of my files.

Since I use it this way, I often have many, small checkins. A given
change is almost always made up of several checkins. The log entries
for these checkins are often somewhat inane as there really isn't
anything to report until the change is completed.

In CVS, I experimented with branching my own branch for every change I
made, and putting the important log entries in the log for the merge
when I was finally finished. Of course, since branching and merging are
such a pain under CVS, I quickly abandon this strategy.

I'm wonder though, if such a strategy would be reasonably efficient
under subversion. Here's my idea:

svnroot/trunk/project
svnroot/releases/project-version
svnroot/branches/project-branchname
svnroot/workarea/developer/project

svn cp trunk/project workarea/developer/project
Record the revision as rb
Make a bunch of tiny, incremental changes in workarea/developer/project.
svn merge svn://host/svnroot/workarea/developer/project_at_rb svn://host/svnroot/workarea/developer/project /checked/out/project
svn rm svn://host/svnroot/workarea/developer/project
cd /checked/out/project
svn commit (and give the real log message here.)

If this is done repeatedly, will there be a lot of problems? Will it
take up excessive amounts of storage space? Does it fit with
subversion's design? Are there slight changes I could make that would
make it work better?

Thanks,

-- 
Eric Hopper hopper@omnifarious.org
Omnifarious Software