It isn't as straightforward as it sounds. A Linux virtual machine
behaves differently to a Linux host wrt time-keeping. Linux kernel has
a number of alternate algorithms that can be used to adjust times. The
default algorith, when used in a VM, will cause the clock to advance
60 seconds in about 48 real seconds, then be reset 12 seconds. In
other words "time goes backwards." The solution to this is to apply an
argument at boot time so that an alternate time adjustment algorithm
is used.
This has nothing to do with NTP.
On Dec 23, 2007, at 11:12 PM, [EMAIL PROTECTED] wrote:
>
> The release is based on a timestamp. That timestamp should refer to
> the time it was created or else it's misleading.
>
> Your solution is great and I would support it if we didn't already
> have an easy, free way to keep computer times in sync (to within
> fractions of a second!). Incorrect clocks will affect more than
> Capistrano and it's best to fix broken windows.
>
> People should ensure the clocks on their system are set correctly. We
> solved the problem of keeping computers in sync a long time ago with
> ntp. My Mac came with it installed and configured out of the box.
>
> - Mike
>
> On Dec 24, 3:32 am, Mark Percival <[EMAIL PROTECTED]> wrote:
>> I came across this issue a couple days ago and found it interesting.
>> Quick rundown - I develop on a Ubuntu VM inside of my windows laptop.
>> This allows me to develop on a machine configured identically to my
>> production Ubuntu server. The problem is that sometimes the time gets
>> out of sync when I suspend the machine. So in some cases my Ubuntu
>> machine can think it's 3 days ago, especially if I suspend over the
>> weekend.
>>
>> Of course as Capistrano currently uses the date on the local machine,
>> you can wind up with a release directory that's actually behind
>> another deployment from another developer.
>>
>> For example -
>> The current date is midnight 12/20/2007, and my laptop thinks it's
>> 12/15/2007
>> /u/apps/sampleapp/releases/20071215000000 is where mine deployed
>> /u/apps/sampleapp/releases/20071217000000 is where another developer
>> deployed 3 days ago
>>
>> The "current" directory gets symlinked to the "20071215" directory
>> with the up to date code, and if you run a migration it gets run on
>> the latest directory, which in this case is set to the "20071217"
>> directory. So now you have your mongrels running off the "20071215"
>> directory, and the database still lacking the most recent update.
>>
>> Now obviously one solution is for me to sync my clock. I recognize
>> that it's ridiculous to expect capistrano to make up for my poor
>> "time
>> management"
>>
>> But I think there's a more subtle problem here. If you're working in
>> group where multiple people can deploy, you could still run into this
>> issue. For example, it's not absurd to expect a one developers clock
>> to be off my 5 minutes, and I've been in a situation where one person
>> has deployed and minutes later I fixed an issue and redeployed.
>>
>> I think the best solution is to base all release directory timestamps
>> off of the server. That completely solves the issue and to be honest
>> it just make more sense to organize around one time standard, rather
>> than to expect everyone to be perfectly in sync.
>>
>> I propose the following modification -
>> _cset(:release_name)
>> { Time.parse(capture('date')).utc.strftime("%Y%m
>> %d%H%M%S") }
>>
>> This has solved the problem entirely for me, and now I can happily
>> update from a laptop that think it's Dec 15, 1986, as I often do
>> whilst traveling around in my DeLorean.
>>
>> Of course I'm not an expert on Capistrano, so I'd appreciate any
>> thoughts on why this would be a good or bad change.
>>
>> Thanks,
>> Mark Percival
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
