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
-~----------~----~----~----~------~----~------~--~---
