The
system provides operations that identify the conflicts and allow users to choose how
to resolve them.
In our case study, we have not modeled any particular revision control system;
instead, we have abstracted features that are common to typical revision control
systems. If you want to compare the model with an implementation, you might want
to look at the Subversion revision control system that is available as open source.
10.4.1 Vocabulary of actions
We viewa revision control system as amodel program with the following vocabulary
of user actions:
??? Synchronize updates a given client??™s local copy to include the latest revisions in
the global repository. However, changed files will not be overwritten; instead,
they will be marked as conflicts to be resolved before committing.
??? Edit represents a file change in the client??™s local view of the repository.
??? Revert undoes a previous edit, restoring a file??™s state to the version of the last
Synchronize operation.
??? Commit propagates local file changes to the global repository.
??? Resolve reconciles conflicts between a local version of a file and changes to the
global repository made in parallel by another user. All files with conflicts must
be resolved before a set of changes may be propagated to the global repository.
The server has two actions that represent the server??™s possible repsonses to a
client??™s request to commit changes:
??? MustResolve occurs after a Commit action for a client with unresolved file con-
flicts.
Pages:
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240