Fail, that’s what happened. A big fat sack of fail.
So as I was working on mihasya.com, I was simultaneously tinkering with ked_core – a natural thing to happen, since mihasya.com is a test for how ked_core actually does when used in practice (it kicks ass, fyi). I got the idea to permit actionless views (more on how, once again, I did that better than you later), so I got all excited and immediately hacked up the code. So now I had this code that was directly applicable to mihasya.com (a lot of the inner pages don’t do much, so don’t need a controller function defined) in the ked_core svn, but not on the site.
The problem is: now that ked just ships as a big hunk of folders with the internal files and the site’s own files mixed in, the separation gets tricky. Also, my blog/ folder (the WordPress install) had to go under mihasya.ked/www/blog, as that was what my mihasya.com folder was symlinked to… Long story short, I straight up deleted mihasya.ked. That was fine, I thought, because I still had all that code in svn…. OOOOPS. Thank goodness for database storage.
Where This Leaves an Ambitious Mother F@#$%#
Well, this is a problem I gots ta solve. It’s plagued me for years, as applications come shipped in huge tarballs that just extract like they’re kings of the world. If you want to selectively update something, you have to cp files one at a time. Fuck that.
How do I elegantly, and from within the framework, permit the developer to upgrade ked files, but not affect his own? This could be solved easily by some sort of package manager like apt or rpm, but we don’t have that luxury. Or rather, I won’t give myself that luxury. This will be solved with bash, php, and svn in the spirit of minimalistic requirements. After all, it has to work on Dreamhost 
What I Intend To Do
This is how it’s goin down, homegirls: I am going to write a shell script which will fetch a special file from a predetermined svn location (the repository doesn’t have to be static, as I’m sure ked will have thousands of mirrors as it sweeps the market 
) The file will contain a listing of files which are internal to ked. It will probably just look something like this:
... inc/controllers/internal inc/core inc/tpl/layouts/internal ...The script will check the internal files on the repository for updates (including a self-update), download them to a separate copy (to avoid messing up your own .svn folders, if any are present) and copy them into your own dev tree.
One problem I’m already seeing before I even start hacking this up is that www/index.php contains configuration information that I refuse to move into a conf file (extra file read) that might get overwritten in this way, but I can probably figure out a way to handle that without quite developing a full blown package manager variable manipulation deal. Or maybe I’ll just do that. Cuz I can, son!
Stay tuned for more on this and other ked shenanigans.