Repeatable read: the transaction may not be serializable with respect to other transactions
This is related to the concept of Isolation Levels. See https://en.wikipedia.org/wiki/Isolation_(database_systems) for details.
Isolation levels are defined by the presence (or absence) of one or more of the following phenomena:

Dirty Reads

This means the ability to see uncommitted data: a change made by another transaction, but not committed yet. That is seldom seen in real life - very few database systems allow that. It is risky because it may return inconsistent data. For example a bank transfer: the origin account has been debited, but the destination account has not yet been credited. If your application reads the accounts in between the two updates, it looks like the money has disappeared!

Non-repeatable Reads

This is what the sentence you quote is talking about. It means that you can see changes that have been committed by other transactions. It implies that, should you repeat the same query in a transaction, you may get different results, because someone may have changed the data since you read it previously. It is a problem for any application that involves checking a stock before confirming an order: the application finds that there are 5 gizmos in stock, then places an order for 4 of them - but in the meantime someone else has ordered them.
This phenomenon can be prevented by placing read locks on everything you read in a transaction. That prevents anyone else from updating the data while you are reading it. It is a bit like if you looked at a pair of shoes in a shop window, and that simple fact makes the shoes unsalable to anyone else.

Phantom Reads

Assume you do place read locks on everything you read. That would still not guarantee that you get the same answer when you repeat a read: everything you read first is safe: nobody can update or delete any of it. However simple read locks do not prevent anyone from inserting a new row. This can lead to inconsistencies in reporting. Say you print out a sales report with the detailed sales. Then you want to print the total and you do that by doing another query to compute the total. That total may not match the details: that is because while you were reading the individual lines, someone has inserted a new sale and committed it.
Preventing phantoms is much harder: placing read locks on the rows read in order to prevent updates is not possible: there is nothing to lock since the new rows do not exist yet. Typical techniques are to place locks on the entire table - which is really bad for concurrency and effectively single-threads inserts. Better techniques involve placing locks on index nodes, since an index node represents a range or rows, effectively preventing any insert in a range of rows read by some application.
Those three phenomenons are used to describe the isolation levels:
Read uncommitted is the lowest isolation level: essentially no consistency at all (dirty reads are allowed).
Read committed prevents dirty reads only. Reads are not repeatable: repeating the same read can have different results
Repeatable reads prevents non-repeatable reads, but does not prevent phantom reads. A read will return the same rows as the previous execution - but it may return more rows: those rows did not exist yet on the first read.
Serializable prevents phantom reads. It is the highest level of consistency. It guarantees that all reads done in a transactions always deliver the exact same result. It is called serializable because the effect of the execution of a series of concurrent transactions is identical to a serial execution of those transactions in one specific order.