Are you referring to VMware? Got a URL for the fix?
My understanding is that Xen virtual hosts use the clock from the Dom0
which is running ntp.
I stopped using Parallels a while ago so can't comment (I like it but
VMware Fusion won me over).
- Mike
On Dec 26, 3:38 pm, Peter Booth <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
