I sent you a pull request on github for this-- I'm still getting my feet wet with git, so let me know if I did something wrong.
-John On Jun 7, 2:08 pm, Jamis Buck <[EMAIL PROTECTED]> wrote: > Good find. I'm not opposed to another variable; there's already one for > determining whether or not to make the checkout group-writable. I'd > rather see the variable phrased as a positive, than a negative, > something like "normalize_asset_timestamps" and have it default to true, > much in the same way that "group_writable" is used. > > - Jamis > > John Trupiano wrote: > > Ah ha! Found it in Subversion. There is a global configuration > > option use-commit-times that by default is turned off. This is a per- > > host setting (and can be overridden by local user preferences) so this > > means that it would part of your initial server setup. In other > > words, after installing Subversion, you would set this global config > > parameter. > > > ========================= > > From the SVN manual: > > ========================= > > use-commit-times > > > Normally your working copy files have timestamps that reflect the > > last time they were touched by any process, whether that be your own > > editor or by some svn subcommand. This is generally convenient for > > people developing software, because build systems often look at > > timestamps as a way of deciding which files need to be recompiled. > > > In other situations, however, it's sometimes nice for the working > > copy files to have timestamps that reflect the last time they were > > changed in the repository. The svn export command always places these > > “last-commit timestamps” on trees that it produces. By setting this > > config variable to yes, the svn checkout, svn update, svn switch, and > > svn revert commands will also set last-commit timestamps on files that > > they touch. > > > ========================= > > > Capistrano could now expose another property to set...something like > > 'dont_touch_assets' (probably a better name). The onus would be on > > the app writer to know that he has set up his server's subversion > > configuration to do just this. Then, in finalize_update, this > > property could be queried, and the touch process could be conditional. > > > Any interest in a patch? Also, any suggestions on a good name for the > > property? > > > -John > > > On Jun 7, 12:14 pm, John Trupiano <[EMAIL PROTECTED]> wrote: > >> 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 -~----------~----~----~----~------~----~------~--~---
