Thanks, I appreciate all the points everyone has made, and I realize
that NTP along with VMWare's tools package solved this problem long
ago. I just felt it was more of a matter of more points of failure
rather than a single point(ie keeping 3 production servers in sync vs
assuming all deployers are in sync). But I can completely agree with
the opinions expressed, and will gladly concede that it's a issue
easily kept in check on the developer side.
Have a great holiday.
- Mark
On Dec 23, 11:12 pm, "[EMAIL PROTECTED]" <[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
-~----------~----~----~----~------~----~------~--~---
