Description: spelling fixes
Origin: vendor
Bug: https://rt.cpan.org/Ticket/Display.html?id=84307
Forwarded: https://rt.cpan.org/Ticket/Display.html?id=84307
Author: gregor herrmann <gregoa@debian.org>
Last-Update: 2013-03-30

--- a/lib/Tangram.pod
+++ b/lib/Tangram.pod
@@ -46,7 +46,7 @@
 structure, it describes a I<data access pattern>.
 
 If you are not picky about which accessor module to use, preferring to
-specify the schema once only, then you can use the seperately
+specify the schema once only, then you can use the separately
 distributed L<Class::Tangram::Generator> to make a set of classes from
 a Tangram schema structure.
 
--- a/lib/Tangram/Schema.pod
+++ b/lib/Tangram/Schema.pod
@@ -32,7 +32,7 @@
 
 B<note>: No corresponding Perl classes are generated from calling
 C<Tangram::Schema-E<gt>new>.  If you want that, and like the behaviour
-of the seperately distributed C<Class::Tangram> module, then you
+of the separately distributed C<Class::Tangram> module, then you
 should pass the C<$hashref> in the above example to the
 C<Class::Tangram::Generator-E<gt>new()> constructor.  See
 L<Class::Tangram::Generator> for more information.
--- a/lib/Tangram/Storage.pod
+++ b/lib/Tangram/Storage.pod
@@ -613,7 +613,7 @@
 In (1), f() commits the changes to $homer directly to the database.
 
 In (2), f() transparently reuses the transaction opened by g().
-Changes to both $homer and $marge are commited to the database when
+Changes to both $homer and $marge are committed to the database when
 g() calls tx_commit().
 
 By default with ACID compliant database back-ends (such as Pg,
@@ -633,8 +633,8 @@
    $storage->tx_commit();
 
 Commits the current Tangram transaction for this storage.  If the
-transaction being commited is the outermost transaction for this
-storage, the DBI transaction is also commited.
+transaction being committed is the outermost transaction for this
+storage, the DBI transaction is also committed.
 
 When using the L<SQLite> back-end, when the DBI transaction is
 committed, the connection is also marked read-only (ie, AutoCommit is
--- a/lib/Tangram/Type.pod
+++ b/lib/Tangram/Type.pod
@@ -76,7 +76,7 @@
 The addition to Sets, you can have `Arrays' of objects, represented by
 a standard Perl array in memory.  Arrays may contain I<undef> values
 (in the middle of the list), and the C<array> type may contain
-duplicates (ie, the same element present in seperate places in the
+duplicates (ie, the same element present in separate places in the
 list).
 
 C<array> : see L<Tangram::Type::Array::FromMany> (implementing an I<ordered> B<N to N>
--- a/t/README.pod
+++ b/t/README.pod
@@ -41,7 +41,7 @@
 More complex conversions and optimisations of inefficient application
 schema, such as combining several L<Tangram::Scalar> C<string> fields
 that do not need to be searched into a single L<Tangram::IDBIF> field,
-should be performed as a seperate project.
+should be performed as a separate project.
 
 As such, some principles will apply to building the test suites that
 use these schemas:
--- a/lib/Tangram/Type/Extending.pod
+++ b/lib/Tangram/Type/Extending.pod
@@ -56,7 +56,7 @@
 A Type must implement the methods described below. Keep the following
 facts in mind while reading further:
 
-1. A Type is responsible for transfering all the *direct* fields for a
+1. A Type is responsible for transferring all the *direct* fields for a
 given *class*. This excludes inherited fields. OTOH, the same Type can
 be called more than once for the same object, because the same Type
 may be used in several classes that appear in a particular object's