Document Revisions
From Projectivity Documentation
Overview
Projectivity is a centralized system for sharing information. At its core is a workspace, which owns a dedicated repository. This repository stores information in the form of a filesystem tree, a typical hierarchy of files and directories. Any number of clients connect to the repository, and then read or write to these files. By writing data, a client makes the information available to others; by reading data, the client receives information from others. The figure below illustrates this process.
So why is this interesting? So far, this sounds like the definition of a typical file server. Indeed, the repository is a kind of file server, but it is not your usual breed. What makes the Projectivity repository special is that it remembers every change ever written to its files.
When a client reads data from the repository, it normally sees only the latest version of the filesystem tree. But the client also has the ability to view previous states of each document. The following image shows the window that lists the document revisions (giving the chance of downloading each one of them) that is displayed when the user clicks on the History button in the Toolbar.
The Problem of File-Sharing (from subversion documentation)
All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.
Consider the scenario shown in Figure “The problem to avoid”. Suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file.While Harry's version of the file won't be lost forever (because the system remembers every change),any changes Harry made won't be presenting Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost—or at least missing from the latest version of the file—and probably by accident. This is definitely a situation we want to avoid!
The Lock-Modify-Unlock Solution
Projectivity uses the so called lock-modify-unlock model to address the problem of many authors clobbering each other's work. In this model, the repository allows only one person to change a file at a time. This exclusivity policy is managed using locks. Harry must “ lock ”a file before he can begin making changes to it. If Harry has locked a file, then Sally cannot also lock it, and therefore cannot make any changes to that file. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, Sally can take her turn by locking and editing the file. The figure below illustrates this simple solution.
