hoodwink.d enhanced


Deploying Rails #

by why in inspect

If you’re keeping your Rails application in a source code repository, Tobias Luetke has a script for retrieving the code, running its tests in a deployment directory and copying it to the target directory. All guided by a simple YAML configuration file at ~/.deployrc.

To keep Hieraki fresh:

   server: linux
   get: svn export svn://myserver/hieraki/trunk
   directory: /var/www/applications/hieraki
   test: RAILS_ENV=production rake

     - chmod 777 log/
     - chmod 666 log/*

     - sudo /etc/init.d/apache reload   

You can likewise checkout from RubyForge CVS with a hack like:

 get: cvs -d:pserver:anonymous@rubyforge.org:/var/cvs/bugtrack 
      export -D now bugtrack; mv bugtrack

I wonder: can RubyGems be easily scripted to pull from CVS or Subversion? Better, I wonder if ViewCVS could be easily hacked to generate snapshot gems? Easily?

said on 23 Apr 2005 at 20:52

Rails has a nifty script and rake task to generate snapshot gems from Subversion and push them to a gem server.

said on 24 Apr 2005 at 03:50

Actually, the freebsd ports and packages system is all cvs based, and the preferred tool for working with it is ruby based.

I dunno about the ‘easily’ part though, because the ports system seems to be a fairly massive make hack.

But it does have the kind of behavior you’re talking about. FreeBSD ports pull source directly from a list of master sites that the port author puts in the makefile, which is quite verstile. If you’ve authored a port, you just use a command line utility that bundles up all the required skeleton info and sends it off to the master ports repository for approval.

But really the ultimate hack would be what you’re talking about. A central gem tracker that can pull any tagged version from the authors source repository, or even the ‘head’ or ‘current’ as a gem. It sounds like rails folks have already implimented the first bit using a push model.

Actually, for a while now I’ve thought that there’d be a lot of merit to a ruby specific revision control system. Being syntax and semanticly aware could enable a lot of snazzy things. But that’s a much bigger and unlikely idea ;)

said on 24 Apr 2005 at 04:13

Zed A. Shaw’s FastCST? :)

said on 24 Apr 2005 at 10:29

How about implementing a feature similar to seaside halos but tying it to a cvs or svn backend, so that your rails application has it’s own builtin source code repository, that can be edited through the web?

said on 25 Apr 2005 at 01:08

gab: FastCST looks interesting, but no, that’s not the sort of thing I’m imagining. FastCST just happens to be implimented in ruby, otherwise, it’s a fairly standard distributed approach: changesets have a UUID , you can assign an arbitrary site specific revision number to some sequence of applied changesets. Changesets get arranged in a dependancy tree of UUID ’s.

Right now it doesn’t allow conflicting applies at all… but when it does, it’ll be strictly manual mergeing. This is because, like almost all diff mergeing tools, it’s not aware of the syntax and semantics of the language.

Darcs gets a bit this by exploiting some algebraic properties. Which is also unforetunate because it creates a lot of overhead as well.

But instead, if you were aware of the syntax and semantics of the language you were working with, it would make automatic merges consideribly better. There’s also oppertunities to do things like reformat someone elses patch into your preferred coding standards, etc.

said on 26 Apr 2005 at 11:35

well, I was thinking of how FastCST should allow you to use plugins. This way you could add a merging tool tuned for the choosen language, and still rely on the rest. But maybe I just need to sleep :)

Comments are closed for this entry.