Archive for the ‘svn’ Category

Project ADD

Wednesday, March 26th, 2008

Just had another “AWESOME” idea today that fits nicely with my desire to create something that can stay with an app as it grows. Once ked_core functionality is more or less finalized (sooner rather than later), I’m going to start hacking up a pecl extension that will mimic ked_core’s behavior perfectly, thus allowing the developer to simply comment out the require_once statement in index.php having installed the extension, maintaining the exact same behavior, but with less overhead, since the framework’s core will now be compiled.

As Crowley put it, that is overkill. I know. But I need to learn how to write PHP extensions :)

I realize that I’ve started more projects in the last month than I have in the last 2 years. I am going to prioritize things a little bit – I want to focus on ked_duffel (the SVN delivery system) to start out, then once that’s functional use it to update mihasya.com’s framework files, then tinker with the framework a little bit, using duffel to test it on mihasya.com.

Once I’m happy with its functionality, I’ll start compiling a pecl skeleton and trying to fill it out, making heavy use of my rollover minutes – to call Crowley with dumb C questions.

Of course, all of this is going to have to wait a little bit – I realized recently that nearly two weeks had passed without me having done any paid work. Someone has to pay for Crowley’s lapdances, so I am going to dedicate a bit more time to Yahoo! stuff in the coming couple of weeks.

So What Happened Last Night?

Monday, March 24th, 2008

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.

Dreamhost + SVN + WebSVN = WIN!!!

Sunday, March 23rd, 2008

I recently set up my public Subversion repository – I decided that setting up a sourceforge or google code account for my stuff would just be lame, given that I have my own website that I’ve recently started putting effort into making presentable. By default, however, svn displays a very basic browser that doesn’t really give any info and is just ugly:

crowley’s ugly svn

My 5 year old step-nephew (moptop from here on out) can do better than that. Here’s my how-to for setting up a baller ass looking Subversion tree like this one. Also, I just like ripping on Crowley.

Things we’ll be using:

  • Dreamhost panel’s svn manager
  • Subversion
  • WebSVN – a kick ass php web-based SVN browser
  • Enscript – a GNU app for highlighting source code.

We’ll start with the hardest, yet optional part:

Optional: Installing Enscript

If you want WebSVN to have broad highlighting support, follow this how-to to install it before we begin.

Setting up Subversion

  1. create a subdomain using this page. Mine is svn.mihasya.com.
  2. go to the dh svn manager and set up you repository. The two examples I’ll use are ked_core and mihasya.com. Make sure you make the repository a “public project”. Set up a username or however many you need. Your respositories can now be found at http://your.svn.subdomain.com/repository_name and locally at /home/username/svn/repository_name
  3. Do the usual commit/import routine so your repository isn’t empty.

Installing WebSVN

This part is easy. From your DH home folder run: (you should obviously replace the URL with teh latest WebSVN tarball and the svn.mihasya.com with the appropriate subdomain’s folder.

$ wget http://websvn.tigris.org/files/documents/1380/39378/websvn-2.0.tar.gz
$ tar -zxvf websvn-2.0.tar.gz
$ mv websvn-2.0/* svn.mihasya.com
$ rm -Rf websvn-2.0
WebSVN is ready to go. Going to your.svn.subdomain.com should now load WebSVN with no repositories.

Configuring WebSVN

Also easy. Now that your WebSVN files are in your subdomain’s folder (/home/mihasya/svn.mihasya.com for me) find the includes/distconfig.php and rename it to includes/config.php.

In that file, find the lines that look like this:

// $config->addRepository('NameToDisplay', 'URL to repository (e.g. file:///c:/svn/proj)');
Copy that, without the comments naturally, and change it to point to your repository. My example:
$config->addRepository('ked_core', 'file:///home/mihasya/svn/ked_core');
Save and refresh the WebSVN page – your repository should now appear. You could be done here, but if you’re not lazy, you could really be a rockstar. Like me.

Optional: Setting up Highlighting Using Enscript

By default, my understanding is that WebSVN only highlights PHP – probably just uses PHP’s highlight functions ;) Remember how we (might have) set up Enscript earlier? Well, now find this line:

// $config->setEnscriptPath('Path/to/enscript/command/');
Uncomment it and replace it with your path from step 1. Mine:
$config->setEnscriptPath('/home/mihasya/packages/bin');
Then find this and uncomment it:
// $config->useEnscript();
Enable Additional Extensions

If you’re like me and use Smarty with somethign like .tpl for files that are really mostly html, do this in the same section to tell Enscript what known filetype to associate that extension with:

$extEnscript['.tpl'] = 'html';

Optional (but awesome): Block Ugly UI Using Rewrite

There is still one problem to be solved. Going to http://svn.mihasya.com/ked_core still goes to the stupid old SVN interface (the one Crowley is using above). You can’t be doin that if you wanna be a rockstar. However, there is one thing it remember (which I initially didn’t): you use the exact same URL when running svn commands. Nothing a little RewriteCond magic can’t fix. Put something like this in the .htaccess file in your svn subdomain’s root folder (where we copied WebSVN earlier):

[ UPDATE: turns out you have to put the RewriteCond statement before every rule (if someone has a better way of doing this, holler); also added the [NC] flag to make the condition not case sensitive, just to be safe ]

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !^SVN [NC]
RewriteRule ^ked_core$ /listing.php?repname=ked_core [R,QSA]
RewriteCond %{HTTP_USER_AGENT} !^SVN [NC]
RewriteRule ^mihasya.com$ /listing.php?repname=mihasya.com [R,QSA]
That second line makes sure that the URL isn’t being called by a Subversion client. Browsers will be directed to the pretty new interface, while svn will operate as usual. Fucking WIN!

Conclusion

Now you can be cool like me and show off your code off your own domain with a sweet ass interface. Not like the chumps with that generic garbage… Explore includes/config.php some more if you want to tailor things more to your tastes.

WebSVN TreeWebSVN Single File