Asset timestamps are appended, not prepended. Closes #10276 [mnaberez]

git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@8220 5ecf4fe2-1ee6-0310-87b1-e25e094e27de

actionpack/CHANGELOG

 *SVN*
 
+* Asset timestamps are appended, not prepended. Closes #10276 [mnaberez]
+
 * Minor inconsistency in description of render example. Closes #10029 [ScottSchram]
 
 * Add #prepend_view_path and #append_view_path instance methods on ActionController::Base for consistency with the class methods.  [rick]

actionpack/lib/action_view/helpers/asset_tag_helper.rb

@@ -41,7 +41,7 @@ module Helpers #:nodoc:
     #
     # === Using asset timestamps
     #
-    # By default, Rails will prepend all asset paths with that asset's timestamp. This allows you to set a cache-expiration date for the
+    # By default, Rails will append all asset paths with that asset's timestamp. This allows you to set a cache-expiration date for the
     # asset far into the future, but still be able to instantly invalidate it by simply updating the file (and hence updating the timestamp,
     # which then updates the URL as the timestamp is part of that, which in turn busts the cache).
     #
@@ -55,7 +55,7 @@ module Helpers #:nodoc:
     # </FilesMatch>
     #
     # Also note that in order for this to work, all your application servers must return the same timestamps. This means that they must 
-    # have their clocks synchronized. If one of them drift out of synch, you'll see different timestamps at random and the cache won't
+    # have their clocks synchronized. If one of them drift out of sync, you'll see different timestamps at random and the cache won't
     # work. Which means that the browser will request the same assets over and over again even thought they didn't change. You can use
     # something like Live HTTP Headers for Firefox to verify that the cache is indeed working (and that the assets are not being 
     # requested over and over).