A definition is made up of classes and fields, and attached to a record so we know what values and validations the record needs.
When we change a definition, or one of its classes or fields, we effectively change the specification of the record. We don't want to do that with half-finished changes, so we use a make-changes-then-commit stategy, where the changes aren't visible yet until we commit the definition. We are using so-called working copies.
When we want to create a new definition based on an existing one, we use the same method; but instead of committing the working copy, we save it under a new name.
A working copy is automatically created when we make the first change to a definition - from then on we're updating this working copy until we're happy with the results.
There are three possible actions on a working copy:
In all three cases, after the action we no longer have a working copy. Working copies are temporary constructs, and cannot be assigned to records.
A commit action always impacts every record that uses the committed definition, class, or field.
The process is the same as for definitions, we use working copies and commit/save/revert. When we commit a class or field, we implicitly update (and commit) the definitions that use them (yes, also if we commit a field that is part of a class that is used by a definition).