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