Looking into Subversion specifically, it definitely behaves as you described Jamis. An interesting idea would be to write a post-commit hook that added a last-edited timestamp as a property on the file. This would allow us to avoid this.
That said, that solution targets a specific SCM, and for it to work with Capistrano, you'd need this subversion post-commit script. What's terribly annoying about this is that Subversion does in fact record the last modified timestamp. Running svn info on a file will give this information back to you. I think it's ridiculous that export and checkout don't allow the option to preserve this timestamp. -John On Jun 6, 6:00 pm, "David Masover" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
