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?
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.
> 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?
> 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?
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 <jtrupi...@gmail.com> wrote:
> On Jun 5, 3:22 pm, Jamis Buck <ja...@37signals.com> 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?
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.
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 <jtrupi...@gmail.com> wrote: >> Makes sense-- thanks.
>> -John
>> On Jun 5, 3:22 pm, Jamis Buck <ja...@37signals.com> 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
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 <ja...@37signals.com> 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 <jtrupi...@gmail.com> wrote: > >> Makes sense-- thanks.
> >> -John
> >> On Jun 5, 3:22 pm, Jamis Buck <ja...@37signals.com> 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
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" <d...@3mix.com> wrote:
> 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 <ja...@37signals.com> 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 <jtrupi...@gmail.com> wrote:
> > >> Makes sense-- thanks.
> > >> -John
> > >> On Jun 5, 3:22 pm, Jamis Buck <ja...@37signals.com> 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
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 <jtrupi...@gmail.com> 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" <d...@3mix.com> 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 <ja...@37signals.com> 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 <jtrupi...@gmail.com> wrote:
> > > >> Makes sense-- thanks.
> > > >> -John
> > > >> On Jun 5, 3:22 pm, Jamis Buck <ja...@37signals.com> 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
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.
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 <jtrupi...@gmail.com> 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" <d...@3mix.com> 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 <ja...@37signals.com> 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 <jtrupi...@gmail.com> wrote: >>>>>> Makes sense-- thanks. >>>>>> -John >>>>>> On Jun 5, 3:22 pm, Jamis Buck <ja...@37signals.com> 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
> 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 <jtrupi...@gmail.com> 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" <d...@3mix.com> 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 <ja...@37signals.com> 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 <jtrupi...@gmail.com> wrote:
> >>>>>> Makes sense-- thanks.
> >>>>>> -John
> >>>>>> On Jun 5, 3:22 pm, Jamis Buck <ja...@37signals.com> 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
