[Capistrano] Re: Time Sync and the local machine

[Jamis Buck]

Mark,






- Jamis

On Dec 23, 2007, at 9:32 AM, Mark Percival wrote:

This sounds like a "this might possibly bite someone someday" issue. Have you actually been bitten by this, where a deployment goes bad because of an incorrect timestamp? The sad fact is, the only authoritative way to build the timestamp would be to query a time server on each deploy. Even production servers can get out of sync--ours have, on occasion. If the current implementation concerns you, then you're more than welcome to use the solution you suggested--plopping that right into your deploy.rb should work just fine.

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 -

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

_cset(:release_name) { Time.parse(capture('date')).utc.strftime("%Y %m

smime.p7s
Description: S/MIME cryptographic signature