Merge docrails.

Signed-off-by: Pratik Naik <pratiknaik@gmail.com>

1 files changed, 25 insertions, 24 deletions

diff --git a/activerecord/lib/active_record/fixtures.rb b/activerecord/lib/active_record/fixtures.rb
index ac06cdbe43..c4cbe5d52f 100755
--- a/activerecord/lib/active_record/fixtures.rb
+++ b/activerecord/lib/active_record/fixtures.rb
@@ -33,8 +33,8 @@ end
 #
 # Unlike single-file fixtures, YAML fixtures are stored in a single file per model, which are placed in the directory appointed
 # by <tt>ActiveSupport::TestCase.fixture_path=(path)</tt> (this is automatically configured for Rails, so you can just
-# put your files in <your-rails-app>/test/fixtures/). The fixture file ends with the .yml file extension (Rails example:
-# "<your-rails-app>/test/fixtures/web_sites.yml"). The format of a YAML fixture file looks like this:
+# put your files in <tt><your-rails-app>/test/fixtures/</tt>). The fixture file ends with the <tt>.yml</tt> file extension (Rails example:
+# <tt><your-rails-app>/test/fixtures/web_sites.yml</tt>). The format of a YAML fixture file looks like this:
 #
 #   rubyonrails:
 #     id: 1
@@ -67,7 +67,8 @@ end
 # = CSV fixtures
 #
 # Fixtures can also be kept in the Comma Separated Value format. Akin to YAML fixtures, CSV fixtures are stored
-# in a single file, but instead end with the .csv file extension (Rails example: "<your-rails-app>/test/fixtures/web_sites.csv")
+# in a single file, but instead end with the <tt>.csv</tt> file extension
+# (Rails example: <tt><your-rails-app>/test/fixtures/web_sites.csv</tt>).
 #
 # The format of this type of fixture file is much more compact than the others, but also a little harder to read by us
 # humans.  The first line of the CSV file is a comma-separated list of field names.  The rest of the file is then comprised
@@ -93,11 +94,11 @@ end
 # This type of fixture was the original format for Active Record that has since been deprecated in favor of the YAML and CSV formats.
 # Fixtures for this format are created by placing text files in a sub-directory (with the name of the model) to the directory
 # appointed by <tt>ActiveSupport::TestCase.fixture_path=(path)</tt> (this is automatically configured for Rails, so you can just
-# put your files in <your-rails-app>/test/fixtures/<your-model-name>/ -- like <your-rails-app>/test/fixtures/web_sites/ for the WebSite
-# model).
+# put your files in <tt><your-rails-app>/test/fixtures/<your-model-name>/</tt> --
+# like <tt><your-rails-app>/test/fixtures/web_sites/</tt> for the WebSite model).
 #
 # Each text file placed in this directory represents a "record".  Usually these types of fixtures are named without
-# extensions, but if you are on a Windows machine, you might consider adding .txt as the extension.  Here's what the
+# extensions, but if you are on a Windows machine, you might consider adding <tt>.txt</tt> as the extension.  Here's what the
 # above example might look like:
 #
 #   web_sites/google
@@ -138,20 +139,20 @@ end
 #
 # In addition to being available in the database, the fixtures are also loaded into a hash stored in an instance variable
 # of the test case.  It is named after the symbol... so, in our example, there would be a hash available called
-# @web_sites.  This is where the "fixture name" comes into play.
+# <tt>@web_sites</tt>.  This is where the "fixture name" comes into play.
 #
-# On top of that, each record is automatically "found" (using Model.find(id)) and placed in the instance variable of its name.
-# So for the YAML fixtures, we'd get @rubyonrails and @google, which could be interrogated using regular Active Record semantics:
+# On top of that, each record is automatically "found" (using <tt>Model.find(id)</tt>) and placed in the instance variable of its name.
+# So for the YAML fixtures, we'd get <tt>@rubyonrails</tt> and <tt>@google</tt>, which could be interrogated using regular Active Record semantics:
 #
 #   # test if the object created from the fixture data has the same attributes as the data itself
 #   def test_find
 #     assert_equal @web_sites["rubyonrails"]["name"], @rubyonrails.name
 #   end
 #
-# As seen above, the data hash created from the YAML fixtures would have @web_sites["rubyonrails"]["url"] return
-# "http://www.rubyonrails.org" and @web_sites["google"]["name"] would return "Google". The same fixtures, but loaded
-# from a CSV fixture file, would be accessible via @web_sites["web_site_1"]["name"] == "Ruby on Rails" and have the individual
-# fixtures available as instance variables @web_site_1 and @web_site_2.
+# As seen above, the data hash created from the YAML fixtures would have <tt>@web_sites["rubyonrails"]["url"]</tt> return
+# "http://www.rubyonrails.org" and <tt>@web_sites["google"]["name"]</tt> would return "Google". The same fixtures, but loaded
+# from a CSV fixture file, would be accessible via <tt>@web_sites["web_site_1"]["name"] == "Ruby on Rails"</tt> and have the individual
+# fixtures available as instance variables <tt>@web_site_1</tt> and <tt>@web_site_2</tt>.
 #
 # If you do not wish to use instantiated fixtures (usually for performance reasons) there are two options.
 #
@@ -184,7 +185,7 @@ end
 #
 # This will create 1000 very simple YAML fixtures.
 #
-# Using ERb, you can also inject dynamic values into your fixtures with inserts like <%= Date.today.strftime("%Y-%m-%d") %>.
+# Using ERb, you can also inject dynamic values into your fixtures with inserts like <tt><%= Date.today.strftime("%Y-%m-%d") %></tt>.
 # This is however a feature to be used with some caution. The point of fixtures are that they're stable units of predictable
 # sample data. If you feel that you need to inject dynamic values, then perhaps you should reexamine whether your application
 # is properly testable. Hence, dynamic values in fixtures are to be considered a code smell.
@@ -257,7 +258,7 @@ end
 #   reginald: # generated id: 324201669
 #     name: Reginald the Pirate
 #
-# ActiveRecord looks at the fixture's model class, discovers the correct
+# Active Record looks at the fixture's model class, discovers the correct
 # primary key, and generates it right before inserting the fixture
 # into the database.
 #
@@ -267,7 +268,7 @@ end
 # == Label references for associations (belongs_to, has_one, has_many)
 #
 # Specifying foreign keys in fixtures can be very fragile, not to
-# mention difficult to read. Since ActiveRecord can figure out the ID of
+# mention difficult to read. Since Active Record can figure out the ID of
 # any fixture from its label, you can specify FK's by label instead of ID.
 #
 # === belongs_to
@@ -304,15 +305,15 @@ end
 #     name: George the Monkey
 #     pirate: reginald
 #
-# Pow! All is made clear. ActiveRecord reflects on the fixture's model class,
+# Pow! All is made clear. Active Record reflects on the fixture's model class,
 # finds all the +belongs_to+ associations, and allows you to specify
 # a target *label* for the *association* (monkey: george) rather than
-# a target *id* for the *FK* (monkey_id: 1).
+# a target *id* for the *FK* (<tt>monkey_id: 1</tt>).
 #
 # ==== Polymorphic belongs_to
 #
 # Supporting polymorphic relationships is a little bit more complicated, since
-# ActiveRecord needs to know what type your association is pointing at. Something
+# Active Record needs to know what type your association is pointing at. Something
 # like this should look familiar:
 #
 #   ### in fruit.rb
@@ -332,7 +333,7 @@ end
 #   apple:
 #     eater: george (Monkey)
 #
-# Just provide the polymorphic target type and ActiveRecord will take care of the rest.
+# Just provide the polymorphic target type and Active Record will take care of the rest.
 #
 # === has_and_belongs_to_many
 #
@@ -395,15 +396,15 @@ end
 #
 # Zap! No more fruits_monkeys.yml file. We've specified the list of fruits
 # on George's fixture, but we could've just as easily specified a list
-# of monkeys on each fruit. As with +belongs_to+, ActiveRecord reflects on
+# of monkeys on each fruit. As with +belongs_to+, Active Record reflects on
 # the fixture's model class and discovers the +has_and_belongs_to_many+
 # associations.
 #
 # == Autofilled timestamp columns
 #
-# If your table/model specifies any of ActiveRecord's
-# standard timestamp columns (created_at, created_on, updated_at, updated_on),
-# they will automatically be set to Time.now.
+# If your table/model specifies any of Active Record's
+# standard timestamp columns (+created_at+, +created_on+, +updated_at+, +updated_on+),
+# they will automatically be set to <tt>Time.now</tt>.
 #
 # If you've set specific values, they'll be left alone.
 #