howto use subversion to maintain a directory tree "in place"
------------------------------------------------------------

* problem:
    I have a directory tree that I want to maintain with subversion
    but I don't want to do blow it away, just to check it out again.

    This is the normal method to creat a repo and import an existing
    directory tree into it:

    # assuming I am root for this example wanting to use subversion
    # to maintain backed up versions of /xxx (an existed tree of stuff)
    svn create /root/svn-repo
    svn import /xxx file:///root/svn-repo/xxx -m'imported *ALL* of xxx'
    # don't delete it until you are sure you snagged everthing
    mv /xxx /xxx2
    svn checkout file:///root/svn-repo/xxx /xxx
    # make sure /xxx is fine and delete the backup
    rm -rf /xxx2

* solution:
    You can perform at least some[1] actions on the repository directly.

    # assuming I am root for this example wanting to use subversion
    # to maintain backed up versions of /xxx (an existed tree of stuff)
    svn mkdir file://root/svn-repo/xxx -m"direct creation of xxx in repo"
    svn checkout file:///root/svn-repo/xxx /xxx
    # magic! /xxx is now under svn control. Now, just add whatever you want
    # if you want to add everything in /xxx:
    cd /xxx
    svn add * # this example doesn't catch .files
    svn ci -m'adding all files (*) under /xxx to the repo'

    This example is great for such things as version controlling /etc or
    even a large tree of stuff in your home-directory where you only
    want select things and don't want to delete a tree and replace it
    with the checked out version. For example, if instead of /xxx I am
    managing /etc, I only control stuff I have alternatively configured.
    For example, my apache, nfs exports, and lots under sysconfig, etc:

    svn add httpd syslog.conf sysconfig exports
    svn ci -m'adding first set of custom configured /etc files'
        
* DANGER DANGER DANGER:
    Subversion *is* better than CVS, but, it still does *not* preserve full
    file permissions correctly :(. This really REALLY irks me. So... though it
    handles symlinks and executables correctly, it does not handle files with
    permissions that deviate far from 644 and directories that deviate far
    from 755 upon checkout. If you are managing such files, I *highly*
    recommend keeping a "svnfix.sh" script at the top level that knows about
    certain files and manually fixes their permissions. This is horrible, I
    know, but, until things change, that's what you have to do.

    I got the idea for that fix script from:
    http://svn.kitenet.net/trunk/bin/svnfix?rev=11777&view=auto
    ...and his O'Reilly article...
    http://www.onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.html


[1] as far as I know, only "some" actions can be directly applied to a svn
    repository. I don't claim to be an expert. :)