Hi Cynthia,
I've got a deploy script you might be interested, it currently resides in
the 2.6.0 branch of Capistrano on github, it is the revisioned, and
roll-back-able deploy (transactional) without the rails assumptions (I
considered removing the Rails-isms in 2.6.0, but that conversation is
ongo
Hello Lee,
I think that in general good documentation will help a lot of people.
With Capistrano, there is a somewhat steeper mental barrier than
Rails. The situation is compounded due to the fact that you don't
"write" Capistrano scripts everyday since once written, they just tend
to work. Whil
On Thu, May 21, 2009 at 2:32 AM, Lee Hambley wrote:
> I agree however I'm relatively inexperienced with RDoc, and hear chat about
> how it's the conceptual stuff about cap that people struggle with; what runs
> locally, what do we mean by remote, deploy targets, roles etc..
>
What runs where and
Robert,
I agree however I'm relatively inexperienced with RDoc, and hear chat about
how it's the conceptual stuff about cap that people struggle with; what runs
locally, what do we mean by remote, deploy targets, roles etc..
I've even heard scary comments like "I'm thinking of switching from Rails
Robert,
I agree however I'm relatively inexperienced with RDoc, and hear chat about
how it's the conceptual stuff about cap that people struggle with; what runs
locally, what do we mean by remote, deploy targets, roles etc..
I've even heard scary comments like "I'm thinking of switching from Rails
Documentation? The documentation I use for Capistrano is the source.
Even then, I need to use a lot of grep, since it's hard to know which
file really defines the underlying method.
Capistrano is great, but, the documentation really suffers. If you
just want to use the standard recipes, it's eas
On Feb 19, 2007, at 12:08 PM, Jamis Buck wrote:
> perhaps Google has the pages cached in the meantime?
They do -- that's how I found stuff about 3 hours ago.
-faisal
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more
On Feb 18, 2007, at 8:39 PM, Keith Pitty wrote:
Hi,
Having just joined the group, I have a couple of questions regarding
documentation for Capistrano.
1. I see there have been some posts this year about improving the
documentation for Capistrano. What's the latest with these efforts?
Is the
I'd be willing to give that a try, though a mephisto account per
author feels a bit top-heavy for the "community-driven" documentation
effort I had in mind. Maybe that's what we try first, though. What
would it take to set that up?
A domain name pointed to the same IP that weblog.rubyonrails.o
On Jan 14, 2007, at 1:03 PM, Rob Sanheim wrote:
On 1/12/07, Jamis Buck <[EMAIL PROTECTED]> wrote:
Alright, apologies to Julie for hijacking her thread. That was not my
intention. I'm rectifying the situation by giving the documentation
topic it's own thread.
So, here's the status of Capist
On 1/12/07, Jamis Buck <[EMAIL PROTECTED]> wrote:
Alright, apologies to Julie for hijacking her thread. That was not my
intention. I'm rectifying the situation by giving the documentation
topic it's own thread.
So, here's the status of Capistrano documentation:
1. The existing manual (http://
On Jan 12, 2007, at 2:24 PM, Rick Olson wrote:
> On 1/12/07, Faisal N Jawdat <[EMAIL PROTECTED]> wrote:
>>
>> On Jan 12, 2007, at 12:28 PM, philippe lachaise wrote:
>>> +1. Most RDoc-generated sites are good at convincing visitors that
>>> their efforts at understanding are doomed to failure.
>>
On 1/12/07, Faisal N Jawdat <[EMAIL PROTECTED]> wrote:
>
> On Jan 12, 2007, at 12:28 PM, philippe lachaise wrote:
> > +1. Most RDoc-generated sites are good at convincing visitors that
> > their efforts at understanding are doomed to failure.
>
> +1. my initial experiences with rails were pretty
On Jan 12, 2007, at 12:28 PM, philippe lachaise wrote:
> +1. Most RDoc-generated sites are good at convincing visitors that
> their efforts at understanding are doomed to failure.
+1. my initial experiences with rails were pretty painful, as i got
a giant list of the api and no small nugget
On Jan 12, 2007, at 11:11 AM, NeilW wrote:
> It might be worth banging this around here for a week or two and
> see if we can come up with something that is better than a wiki.
one alternative might be to set up a documentation repository and
handle changes via the standard "submit patch -> we
Well, look at this :
http://deplate.sourceforge.net/index.php
An it's Ruby-based by the way !
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--
>> I've not seen an rdoc-generated site that succeeded from that
perspective.
+1. Most RDoc-generated sites are good at convincing visitors that their
efforts at understanding are doomed to failure.
>> Ultimately, I'd like to be able to provide a printable version of the
docs, as well as a versio
On 12 Jan 2007, at 16:11, NeilW wrote:
>
> It might be worth banging this around here for a week or two and
> see if we can come up with something that is better than a wiki.
>
> Is there any particular reason why it can't be done in 'rdoc' in the
> code
> base. At least then we can submit patche
The problem with rdoc is it is API-oriented. I'm wanting something
that someone new to capistrano could pick up and learn how to use
capistrano with. I've not seen an rdoc-generated site that succeeded
from that perspective.
- Jamis
On Jan 12, 2007, at 9:11 AM, NeilW wrote:
>
> It might b
It might be worth banging this around here for a week or two and
see if we can come up with something that is better than a wiki.
Is there any particular reason why it can't be done in 'rdoc' in the
code
base. At least then we can submit patches to it (assuming there is
somewhere capistrano patch
20 matches
Mail list logo
