Hmm. Maybe try this:
_cset(:real_revision) { source.query_revision(revision) { |cmd|
capture(cmd) } }
(That's totally off the top of my head, and hasn't been tested at all.)
- Jamis
On May 13, 2008, at 8:07 AM, David Smalley wrote:
>
> On May 13, 2:50 pm, "Mislav Marohnić" <[EMAIL PROTECTED]>
> wrote:
>> On Tue, May 13, 2008 at 3:44 PM, Jamis Buck <[EMAIL PROTECTED]>
>> wrote:
>>
>>> It's because an entire deploy actually consists of several non-
>>> atomic
>>> operations, and if you just use HEAD there exists a race condition
>>> such that one operation could be against one revision and the next
>>> operation against some newly pushed revision.
>>
>> Yes, of course, this may be the most important reason of them all.
>> Deployment usually last a while---it doesn't happen in a second---
>> and often
>> there is a lot of development (pushing) happening at the time of
>> web app
>> deployments. Probability for a race condition would be high.
>
> Yes - an excellent point and probably one that means we don't want to
> push this as a default into our Capistrano configurations.
>
> I have tried with varying degrees of success to move the git ls-remote
> over to the remove side of the deployment. Anyone got any pointers on
> how I could do this easily? I was secretly hoping that I'd just
> change...
>
> _cset(:real_revision) { source.local.query_revision(revision) { |
> cmd| with_env("LC_ALL", "C") { `#{cmd}` } } }
>
> to
>
> _cset(:real_revision) { source.remote.query_revision(revision) { |
> cmd| with_env("LC_ALL", "C") { `#{cmd}` } } }
>
> But obviously that's just wishful thinking :)
>
> Capistrano is so magic that if anyone has already sussed out this
> magic and can save me an rdebug session I'd greatly appreciate it.
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
