Prev | Current Page 461 | Next

Brad Ediger

"Advanced Rails"

When a
folder is designated as an external, it is paired with a remote repository. When
updating the working copy, code will be pulled from that repository in addition to
the main project repository.
In Rails, there are two reasons you would want to do this. The first is to lock Rails to a
certain version (or to track edge Rails). The second is for plugins: you may want to
follow updates to a plugin??™s Subversion repository, so you can lock vendor/plugins/
plugin_name to the plugin??™s development repository. The script/plugin command
even provides a flag that adds the plugin as an external rather than downloading it:
$ script/plugin install -x some_plugin
This works for small-scale applications, but the dependencies can quickly become
a mess. Most of the time, you will not want to follow the bleeding edge of Rails or
a plugin, but instead lock to a known-stable version. Although svn:externals has a
feature to do that, it can get messy. The biggest problem is that any local changes
you make to the external code are not versioned. In addition, updates are slow as
they must query each external server.
The best solution at this point is Fran?§ois Beausoleil??™s Piston (http://piston.rubyforge.
org/). Rather than pulling a copy of the code from the remote Subversion server, Piston
stores a copy locally, in your project??™s own Subversion repository. It uses properties
on the folder to track the current version at the remote repo.


Pages:
449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473