On 20 Apr 2006, at 18:53, Alder G. wrote:
The Rails wiki has several detailed treatments of SVN Rails
development and deployment. Many other texts exist, some going into
quite a bit of detail, like for example [1].
That’s a nice article, and could be translated to darcs, which I’d do
if I had more time.
Yeah, knowing all the gotchas in advance would be nice. Maybe I’ll
find the time to write it after I experience all of them myself 
I didn’t have any problems other than the ones mentioned, and those
articles were what got me to try darcs so I avoided them :).
The main issue i’ve found using darcs is how to handle the case where
others would use svn:externals. I shy away from them anyway, and for
vendor/rails use tasks similar to this one on railsweenie [1], which
I’ve blogged about here [2]. I don’t actually like the way my task
works at the moment but it should give you the idea.
What I’ve started doing with other plugins (which use svn in general
with a few .zips) is checking them out to ~/dev/rails_plugins/
<plugin_name> and then using svn export ~/dev/rails_plugins/
<plugin_name> ~/dev/my_app/vendor/<plugin_name>. I then record this
in darcs with something like darcs record -alm "[PLUGIN_NAME] - r123
- added". I do this manually at the moment but it’s crying out to be
raked up. I’ve got every plugin I think I’ll need locally, which
means I can create new or test apps without needing to be connected
to the net. Another rake task crying out to be written is one that
svn up’s all those dirs to keep me up to date.
It would be great if you found the time to do the writeup, more
people should behold the power of the darcside on their source </
vader_misquote>
Not sure either I understand Rails on principle (MVC, basic
concepts and MO), but actually developing a complex Rails application
is still a mystery for me. I figured if everyone is flocking to SVN
(when we all know how much simpler and subtly powerful Darcs is 
there must be a good reason…
I think simply because svn has a lower barrier to entry and wider
usage, and it’s how you get the rails source. I much prefer how darcs
works, especially given that one of my tasks pretty soon will be to
help merge a branch and trunk in an svn repo that diverged over 1000
revisions ago 
I’m still finding my feet with darcs somewhat, and trying to figure
out the best way of going about recording patches. At the moment I’m
going for the record as often as possible approach, as well as this I
should probably be putting useful tags in my commit messages to
making pulling and pushing specific bits of functionality easier.
On my “I want a pony” list is a rails app that you could tell about
your darcs repos that would query them and allow you to drag and drop
patches between one and the other. I haven’t really needed anything
like that yet but it’d just be cool
If you’re deploying to unix I’d really really recommend checking
out Capistrano, I can’t imagine using anything else now!
Sounds like I really need to check it out (deploying to a Debian
Stable server).
I deploy to debian stable on my VPS using runit rather than spinner /
spawner / reaper [3] and have used Capistrano with both darcs and
svn. For darcs, I push to a dir readable by my www user (which I
should put in a before_deploy task thinking about it), have
set :repository, ‘/path/to/readable/dir’ in config/deploy.rb and
Capistrano gets it from there when it’s doing it’s stuff on the
remote machine. Capistrano shells out to darcs get so you can put any
darcs valid repo in there.
Cheers,
Chris
[1] http://rails.techno-weenie.net/tip/2006/2/7/
deploy_your_apps_on_edge_rails
[2] http://outside-thoughts.octopod.info/articles/2006/03/14/keeping-
your-apps-on-the-edge-without-using-svn-externals
[3] http://outside-thoughts.octopod.info/articles/2006/03/18/
switching-to-runit-from-spinner-spawner-reaper