Just a simple deployment question… would it be a better idea to
include the plugins I install in my project’s SVN repository? Or should
I ditch them and re-install them in my production environment?
Personally I thought it might be a better idea to include them in my
project SVN so that way I’m sure that the same version of the plugin
will be used once I deploy my app in production environment… Any
reasons why I shouldn’t do it?
Also, besides the database config file and temp directories (tmp, cache,
logs etc)… anything else I should EXCLUDE from my projet’s svn repo?
On Oct 24, 2007, at 11:46 AM, Jean-nicolas Jolivet wrote:
Also, besides the database config file and temp directories (tmp,
cache,
logs etc)… anything else I should EXCLUDE from my projet’s svn repo?
In my opinion, yes. Lock everything to versions that you’ve tested with.
This is where Piston comes into play. We import plugins into our svn
via piston so that we aren’t relying on svn external repositories to
stay up/active… or heaven forbid they make changes and it breaks
our application on our next deployment.
We mirror the plugins we use with svk into the svn repo and then use
svn externals into the same repo. This setup has been working without
problems for us.
You can lock to specific plugin revisions with the usual -r option in
the external
On Oct 24, 8:46 pm, Jean-nicolas Jolivet <ruby-forum-incom…@andreas-
Personally I thought it might be a better idea to include them in my
This is where Piston comes into play. We import plugins into our svn
via piston so that we aren’t relying on svn external repositories to
stay up/active… or heaven forbid they make changes and it breaks
our application on our next deployment.
Same goes for rubygems, (frozen with my gems plugin, http://svn.techno-weenie.net/projects/plugins/gems/), or even edge
rails. I have a rake task that exports specific edge rails revisions
and creates symlinks for all deployments. Mike C. had an excellent
blog post taking you from using svn:externals for rails (icky) to
using the ‘cadillac style’ of freezing rails (adapted from some of my
rake tasks).
One nice thing is you can easily roll back if things break, rather
than jump into your server(s) and rollback gems manually.