On 8/16/06, Charles Brian Q. [email protected] wrote:
Since capistrano’s deployment tasks really only automate the
performing of “checkout” from a repository (and usually through
subversion), it is really the developers job to “ignore” files that
shouldn’t be checked in. There are good reasons, I agree, to not
include developer tools like breakpointer and such.
I agree with keeping Cap simple in principal; my concern is to try to
having to hand-roll a less-than-perfect production scrubber, as well as
trying to keep up with new “fluff” in future Rails releases that I don’t
want to deliver with applications. There ought to be some reasonable
conventions for removing community-accepted fluff before a production
And, on the other hand, if you need to setup another developer, they
could always check out the production limited code-base and run “rails
.” on the current dir to get the latest dev tools like script/server
that have been removed anyways.
Not a bad thought, but it pushes the onus on the Rails end-user to know
which files shouldn’t go to production, rather than having a “safe by
default” scrubber already available. It also eliminates some of the
of Rails development if I’m always forced to prime a newly-checked-out
application before getting back to work. Still, it’s not bad.
In the case of schema.rb (highglighted by attacks), this file is
continue to get checked out or generated.
deploy to dev box task keeps files, but the deploy to production just
This is exactly in line with what I’m thinking. At a minimum, there
be a number of files you’d never want delivered to production, and a
reasonable set of defaults “after” tasks to prevent that from happening
without explicit permission. I’m not sure I’m the right person to say
files those are, however, nor to make appropriate changes to HOWTOs or