chore: fix typos, acronym and styles

Author: ccoVeille

CONTRIBUTING.md

@@ -1,17 +1,17 @@
 # Development, Testing and Contributing
 
   1. Make sure you have a running Docker daemon
-     (Install for [MacOS](https://docs.docker.com/docker-for-mac/))
+     (Install for [macOS](https://docs.docker.com/docker-for-mac/))
   1. Use a version of Go that supports [modules](https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more) (e.g. Go 1.11+)
   1. Fork this repo and `git clone` somewhere to `$GOPATH/src/github.com/golang-migrate/migrate`
-      * Ensure that [Go modules are enabled](https://golang.org/cmd/go/#hdr-Preliminary_module_support) (e.g. your repo path or the `GO111MODULE` environment variable are set correctly)
+      * Ensure that [Go modules are enabled](https://golang.org/cmd/go/#hdr-Preliminary_module_support) (e.g. your repository path or the `GO111MODULE` environment variable are set correctly)
   1. Install [golangci-lint](https://github.com/golangci/golangci-lint#install)
   1. Run the linter: `golangci-lint run`
   1. Confirm tests are working: `make test-short`
-  1. Write awesome code ...
+  1. Write awesome code …
   1. `make test` to run all tests against all database versions
   1. Push code and open Pull Request
- 
+
 Some more helpful commands:
 
   * You can specify which database/ source tests to run:

FAQ.md

@@ -50,7 +50,7 @@
   and whenever we want, not just once at the beginning of all tests.
 
 #### Can I maintain my driver in my own repository?
-  Yes, technically thats possible. We want to encourage you to contribute your driver to this repository though.
+  Yes, technically that's possible. We want to encourage you to contribute your driver to this repository though.
   The driver's functionality is dictated by migrate's interfaces. That means there should really
   just be one driver for a database/ source. We want to prevent a future where several drivers doing the exact same thing,
   just implemented a bit differently, co-exist somewhere on GitHub. If users have to do research first to find the

GETTING_STARTED.md

@@ -14,7 +14,7 @@ Once you create your files, you should fill them.
 Developers and Teams should keep an eye on such cases (especially during code review).
 [Here](https://github.com/golang-migrate/migrate/issues/179#issuecomment-475821264) is the issue summary if you would like to read more.
 
-Consider making your migrations idempotent - we can run the same sql code twice in a row with the same result. This makes our migrations more robust. On the other hand, it causes slightly less control over database schema - e.g. let's say you forgot to drop the table in down migration. You run down migration - the table is still there. When you run up migration again - `CREATE TABLE` would return an error, helping you find an issue in down migration, while `CREATE TABLE IF NOT EXISTS` would not. Use those conditions wisely.
+Consider making your migrations idempotent - we can run the same SQL code twice in a row with the same result. This makes our migrations more robust. On the other hand, it causes slightly less control over database schema - e.g. let's say you forgot to drop the table in down migration. You run down migration - the table is still there. When you run up migration again - `CREATE TABLE` would return an error, helping you find an issue in down migration, while `CREATE TABLE IF NOT EXISTS` would not. Use those conditions wisely.
 
 In case you would like to run several commands/queries in one migration, you should wrap them in a transaction (if your database supports it).
 This way if one of commands fails, our database will remain unchanged.
@@ -36,7 +36,7 @@ It's also worth checking your migrations in a separate, containerized environmen
 
 ## Forcing your database version
 In case you run a migration that contained an error, migrate will not let you run other migrations on the same database. You will see an error like `Dirty database version 1. Fix and force version`, even when you fix the erred migration. This means your database was marked as 'dirty'.
-You need to investigate the migration error - was your migration applied partially, or was it not applied at all? Once you know, you should force your database to a version reflecting it's real state. You can do so with `force` command:
+You need to investigate the migration error - was your migration applied partially, or was it not applied at all? Once you know, you should force your database to a version reflecting its real state. You can do so with `force` command:
 ```
 migrate -path PATH_TO_YOUR_MIGRATIONS -database YOUR_DATABASE_URL force VERSION
 ```

MIGRATIONS.md

@@ -18,7 +18,7 @@ the `extension` of the migration files is not checked by the library, and should
 be an appropriate format for the database in use (`.sql` for SQL variants, for
 instance).
 
-Versions of migrations may be represented as any 64 bit unsigned integer.
+Versions of migrations may be represented as any 64-bit unsigned integer.
 All migrations are applied upward in order of increasing version number, and
 downward by decreasing version number.
 

README.md

@@ -77,7 +77,7 @@ Source drivers read migrations from local or remote sources. [Add a new source?]
 * [GitHub](source/github) - read from remote GitHub repositories
 * [GitHub Enterprise](source/github_ee) - read from remote GitHub Enterprise repositories
 * [Bitbucket](source/bitbucket) - read from remote Bitbucket repositories
-* [Gitlab](source/gitlab) - read from remote Gitlab repositories
+* [Gitlab](source/gitlab) - read from remote GitLab repositories
 * [AWS S3](source/aws_s3) - read from Amazon Web Services S3
 * [Google Cloud Storage](source/google_cloud_storage) - read from Google Cloud Platform Storage
 

database/mongodb/mongodb.go

@@ -30,15 +30,15 @@ var DefaultMigrationsCollection = "schema_migrations"
 const DefaultLockingCollection = "migrate_advisory_lock" // the collection to use for advisory locking by default.
 const lockKeyUniqueValue = 0                             // the unique value to lock on. If multiple clients try to insert the same key, it will fail (locked).
 const DefaultLockTimeout = 15                            // the default maximum time to wait for a lock to be released.
-const DefaultLockTimeoutInterval = 10                    // the default maximum intervals time for the locking timout.
+const DefaultLockTimeoutInterval = 10                    // the default maximum intervals time for the locking timeout.
 const DefaultAdvisoryLockingFlag = true                  // the default value for the advisory locking feature flag. Default is true.
 const LockIndexName = "lock_unique_key"                  // the name of the index which adds unique constraint to the locking_key field.
 const contextWaitTimeout = 5 * time.Second               // how long to wait for the request to mongo to block/wait for.
 
 var (
 	ErrNoDatabaseName            = fmt.Errorf("no database name")
 	ErrNilConfig                 = fmt.Errorf("no config")
-	ErrLockTimeoutConfigConflict = fmt.Errorf("both x-advisory-lock-timeout-interval and x-advisory-lock-timout-interval were specified")
+	ErrLockTimeoutConfigConflict = fmt.Errorf("both x-advisory-lock-timeout-interval and x-advisory-lock-timeout-interval were specified")
 )
 
 type Mongo struct {
@@ -134,15 +134,15 @@ func (m *Mongo) Open(dsn string) (database.Driver, error) {
 	if err != nil {
 		return nil, err
 	}
-	lockingTimout, err := parseInt(unknown.Get("x-advisory-lock-timeout"), DefaultLockTimeout)
+	lockingTimeout, err := parseInt(unknown.Get("x-advisory-lock-timeout"), DefaultLockTimeout)
 	if err != nil {
 		return nil, err
 	}
 
 	lockTimeoutIntervalValue := unknown.Get("x-advisory-lock-timeout-interval")
 	// The initial release had a typo for this argument but for backwards compatibility sake, we will keep supporting it
 	// and we will error out if both values are set.
-	lockTimeoutIntervalValueFromTypo := unknown.Get("x-advisory-lock-timout-interval")
+	lockTimeoutIntervalValueFromTypo := unknown.Get("x-advisory-lock-timeout-interval")
 
 	lockTimeout := lockTimeoutIntervalValue
 
@@ -171,7 +171,7 @@ func (m *Mongo) Open(dsn string) (database.Driver, error) {
 		TransactionMode:      transactionMode,
 		Locking: Locking{
 			CollectionName: lockCollection,
-			Timeout:        lockingTimout,
+			Timeout:        lockingTimeout,
 			Enabled:        advisoryLockingFlag,
 			Interval:       maxLockCheckInterval,
 		},

database/sqlserver/sqlserver.go

@@ -190,7 +190,7 @@ func (ss *SQLServer) Close() error {
 	return nil
 }
 
-// Lock creates an advisory local on the database to prevent multiple migrations from running at the same time.
+// Lock creates an advisory lock on the database to prevent multiple migrations from running at the same time.
 func (ss *SQLServer) Lock() error {
 	return database.CasRestoreOnErr(&ss.isLocked, false, true, database.ErrLocked, func() error {
 		aid, err := database.GenerateAdvisoryLockId(ss.config.DatabaseName, ss.config.SchemaName)
@@ -214,7 +214,7 @@ func (ss *SQLServer) Lock() error {
 	})
 }
 
-// Unlock froms the migration lock from the database
+// Unlock the migration lock from the database
 func (ss *SQLServer) Unlock() error {
 	return database.CasRestoreOnErr(&ss.isLocked, true, false, database.ErrNotLocked, func() error {
 		aid, err := database.GenerateAdvisoryLockId(ss.config.DatabaseName, ss.config.SchemaName)

migrate.go

@@ -526,7 +526,7 @@ func (m *Migrate) read(from int, to int, ret chan<- interface{}) {
 	}
 }
 
-// readUp reads up migrations from `from` limitted by `limit`.
+// readUp reads up migrations from `from` limited by `limit`.
 // limit can be -1, implying no limit and reading until there are no more migrations.
 // Each migration is then written to the ret channel.
 // If an error occurs during reading, that error is written to the ret channel, too.
@@ -626,7 +626,7 @@ func (m *Migrate) readUp(from int, limit int, ret chan<- interface{}) {
 	}
 }
 
-// readDown reads down migrations from `from` limitted by `limit`.
+// readDown reads down migrations from `from` limited by `limit`.
 // limit can be -1, implying no limit and reading until there are no more migrations.
 // Each migration is then written to the ret channel.
 // If an error occurs during reading, that error is written to the ret channel, too.