Version control
SiteBuilder allows several users to work on the same site and at the
same documents at the same time. This could easily cause problems,
when someone edits a document only to find out that in the meantime,
someone else has also made changes to the same documents, maybe even
in the same places. SiteBuilder avoids this by employing a version
control system.
To start off with, SiteBuilder has a central repository where the
live documents, the documents that will actually be sent when someone
looks at the site, are stored. Together with these files are stored a
history of each document - What changes has been made to it, by which
user, and when. This enables the system administrator to change a page
back to an earlier version of itself by simply undoing the changes
made since then, which means that a mistake by a page editor is never
likely to be fatal - it is always possible to revert to an earlier,
working version. Furthermore, this way SiteBuilder keeps track of who
has written each part of a document, and can automatically annotate
each document with its authors or log its change history.
Edit area
It is not possible, or desirable, to let anyone edit the live
documents directly. Instead, as soon as you want to edit a document, a
copy is made to your personal edit area, where you can edit the
document, view it as it would look like on the site, try out different
templates, illustrations or
whatever. When you are satisfied with the result, you commit your
changes to the central repository and the live document changes to
reflect your edits.
Conflicts
Now, if somebody else is also editing the same document, it might
happen that the document in the central repository has already
changed. In this case, SiteBuilder will inform you that the document
has changed and that you need to update your edit area to reflect the
new changes. When updating, SiteBuilder will attempt to merge the
changed document with your edits. Sometimes this will be simple, such
as when the edits are in different parts of a long document. However,
sometimes there will be a collision, when both you and the other user
have been editing the same paragraph. In such a case, both your and the
other user's version will be shown, and you'll have to decide which
one to keep. Remember, it is always possible to revert to an earlier
version. Finally, when you have successfully eliminated all conflicts
between the document in the repository and your edits, you may commit
your new document to the repository.
Schematic example
Version
control
A short example to show how this works:
- A document is in the central repository, that contains some text.
Editor1 and Editor2 starts to edit it and the document is copied to
each user's edit area.
- Editor1 adds some text to the document while Editor2 inserts a
picture. Both users work in their own edit area and are therefore not
affected by each others changes.
- Editor2 commits his change, thereby updating the document in
the repository. Since no one has changed the document in the
repository since Editor2 started editing he has no problems
committing.
- Editor1 tries to commit his change, but this fails since
Editor2 has updated the document in the repository.
- Editor1 uses the Update wizard, which updates his
document with the changes made since he started editing.
- Editor1 can now successfully commit his changes to the
repository.
Note that the document can be reverted at a later date. Thus the
version of the documnet that existed in step three or step one can be
recovered.
|