Clients should be using ETags anyway...

That said, even if an SCM doesn't preserve timestamps, it should at least be
able to tell you when a particular file was last modified, and which files
have been modified since a particular revision. It'd still involve a touch,
but it'd be more accurate -- only changed files would appear as changed,
which is what you want.

On Thu, Jun 5, 2008 at 4:56 PM, Jamis Buck <[EMAIL PROTECTED]> wrote:

>
> I've not seen an SCM that preserves timestamps on checkout, but that
> might just mean I'm doing it wrong. In practice, though, we (at
> 37signals) are seeing files being stamped with the time of checkout, not
> with the time of last commit. This means that when checking out files on
> multiple servers, if one server takes a little longer to comply with the
> checkout request, the timestamps are off.
>
> Now, if this is me doing something stupid, please correct me. I
> certainly don't claim to be an expert in these matters. But the mass
> touch of asset files on deploy was how we worked around it. I certainly
> would be the last to complain if someone found a better way. That touch
> command drives me nuts.
>
> - Jamis
>
> John Trupiano wrote:
> > Actually, I'm still a little confused by this.  Doesn't your SCM
> > dictate the last accessed timestamp?  In other words, if your app is
> > checked out to several different app servers, shouldn't the timestamps
> > all come from the same authoritative source (the SCM)?
> >
> > Am I (a) misinterpreting which file attribute is used by rails to
> > create the querystring param, or (b) misunderstanding how the last
> > modified timestamp is determined when checking code out of a
> > repository?
> >
> > -John
> >
> > On Jun 5, 3:24 pm, John Trupiano <[EMAIL PROTECTED]> wrote:
> >> Makes sense-- thanks.
> >>
> >> -John
> >>
> >> On Jun 5, 3:22 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> >>
> >>> It is so that the timestamps are all the same, across all of your
> >>> servers. If the timestamps are even a second off (which can easily
> >>> happen when you are deploying to multiple servers), then the client
> will
> >>>  have to download the assets again every time their request hits a
> >>> different server, which totally defeats the purpose.
> >>> - Jamis
> >>> John Trupiano wrote:
> >>>> Hey Jamis,
> >>>> I can't understand why we need to touch all of the asset files after a
> >>>> re-deploy.  If I understand it correctly, rails uses the last modified
> >>>> date on an asset to append the querystring value.  As such, this last
> >>>> access date would change if a file was changed, but would otherwise
> >>>> remain the same.  What then is the need to go ahead and dirty all of
> >>>> the assets?
> >>>> It seems to me that we're unnecessarily asking clients to re-download
> >>>> all of our assets, even those that haven't changed.  Am I missing
> >>>> something here?
> >>>> Thanks.
> >>>> -John
> > >
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---

Reply via email to