1.Content and File Mangement(wikis)
The main discussion document management and version control to cvs, svn and git-based, wikis File management model to complement
2. version control issues to be addressed:
- Access control
- concurrent access
- update conflict
- error handling
- remote editing
- versioning
- recovery of old version
- time-dependent publication
3. Revision control systems
software for management and monitoring document and software revision. Primarily concerned with recovery of former revisions, storing, versioning and locking of project files or directories.
Repair revision management system is responsible for managing documents and software. The main focus on the recovery of historical versions, save, version control, and control access to project files and documents. There are CVS, SVN, Git version
4. Categories of Revision Control Systems
- Local Version Control
- Centralized Version Control Systems
- Decentralized Version Control Systems
First of all in terms of the structure, local version control by definition is the local version database, Centralized version control systems is to have a central version database server provides centralized version control, participants can only export version; decentralized version control systems is decentralized version control, version exchange offer.
5. CVS(concurrent versions system)
- is the center of the structure CVS version control, centralized version control.
- component:
- repository (warehouse):
- central storage for all raw files which are under RC
(First central repository to manage all raw files)
- each raw file is converted to a history file(*,v) that contains recovery information and the concurrent revision
(All raw files to be converted into a version of history, carrying the historical recovery information and the current version)
- Provides a "CVSROOT" directory containing additional meta-information
(Provided CVSROOT contains meta-information)
- Sandbox (sandbox):
- a working directory containing specific checked-out revisions
(A working directory that contains a special version detection)
- a sandbox is created by the "cvs checkout" command, thereby specific revisions of raw files are created with the help of the history files
(Working directory is a command by the checkout, and therefore the detection of specific file is created in the history file)
- every directory in a CVS-Sandbox has a "CVS" directory, which contains management files providing e.g. information about current revision number or checked-out time
(Each folder in your working directory has an cvs folder that contains the file management provides the current revision, the detection time)
- selected mechanism
- versioning (version number assigned when there is change, there is a historical document may facilitate the detection of various versions of the client, in and out)
- Allocation of revision numbers for every modification of a source file which is registered in the repository by the "cvs commit" command
- due to the history information containing in history files all revisions are available and accessible, thereby clients can load various revisions from the repository(via "cvs checkout" or "cvs export" methods - same effect like checkout but no mangament files are created)
- merging (conflict requires manual processing occurs)
- is a mechanism for joining two different revisions of the same file(if the same line are edited a conflict occurs that has to be solved by the developers manually)
- The "cvs update" proofs whether new revisions exist in the repository and, if this is the case, tries to merge these different revisions.
- tagging
- provides a possiblity for creating a kind of symbolic linkage of various files and their revisions
- it is necessary to create a tag(e.g. release_1_0) on a particular revision of a file
- it is possible to checkout concrete tagged revisions annotated（注解）by these meaningful tags
- each tag is unique within a history file
- locking
- cvs provides a way to set an explicit commit lock on a revision and while the commit lock is active other users are not able to commit a revision of the particular file
- branching
- cvs tag -b branch1
- cvs update -j （merge branch and master）
- central shortcomings:
- not support directory versioning,
- commit is not atomic: is run for every file separately and when there is conflict regarding one file, other files are commited beside the file contianing the conflict, so inconsistent repository state
- No self-defined properties(metadata information)
- management of tags and branches is difficult and resource intensive
- no efficient storing of binary files
5. SVN subversion system
to solve shortcomings of cvs
- tags and branches
- realised by copying the revisions to an extra folder
- the "svn copy" method does not copy the files physically to a folder- reference to the original data is created
- files and dictories can be copied
- if a copy is modified, only the differences are stored.
6. Git
- decentralized version control system
- optimized for nonlinear development and branching
- Typical variants of version control systems realise versions by tracking changes to an original version of each file
- create with every commit a new snapshot of the versioned files: and use SHA! hash of concatenated hashes of versioned files are used as identifiers
- link to previous file, if files are not changed, a link to previous file is stored
- Branching
- a branch in git is a reference to a snapshot
- every branch has a name. The main branch is named "master". One brach is always the active one = marked by the head reference
-git branch bugfix
- git checkout bugfix(bugfix is activated)
- git commit (commit changes to active branch)
-merging
- merging is done into the active branch:
- git checkout master
- git commit
- git merge bugfix (merge bugfix into active branch)
- remote branches
contains remote canonical project repository
- git clone [email protected]/repo.git
local repository, two branching
- origin/master and the master branch are pointing to the origin's master branch
- git fetch
changes done by others in the remote repository can be transferred to the local repository via the Git command "fetch"
- distributed workflows
- git enables distributed software development workflows with several hierarchical levels
7. Content
- content basically consists out of three components:
- structure information
- defines the composition, sequence and encapsulation of raw data
- data raw
- composed according to the structure
- layout information
- formal specification for presentation on a potential output medium
- content lifecycle - cms functionalities
- creation(authoring, authentication, check-in/check-out, WYSIWYG, Multi-user ability)
- Organissation(user management, workflow/quality protection, page integrity/link management, log functionality)
- publishing(presentation, personalisartion, multi-channel-output, portal function)
- archiving(retrieval, backup/rollback,version management)
- content phase: deals with collection, creation and editing or the content
- organisation phase: deal with quality check and clearing of the content for publication
- publication phase: deals with publication of the content in intra- or internet
- archiving phase: after removing the content from the network, content can be stored in the content repository for documentation purpose or future usage
-example for a widespread CMS: TYPO3
- for configuration of TYPO3 TypoScript is used
- TypoScript is a declarative language
- conversion of typoscript into html by php logic
- area of application:
- designing+integration of templates(front-end = publish web site)
-pure ts-template
- html-template +TS
- configuration of the back-end(administration + content mangement area)
- user/user group properties(User TSConfig)
- page properties(page TSConfig)
- separation of structure, layout and raw data
- PAGE object builds a framework for embedding further content
- content object array is created and put to position 20 of the page
- COA is wrapped into HTML table row elements
- Abbreviatory syntax for assigning values to positions
- After creating an image object a file is associated with it
8. Wikis
- software systems that allow users to easily generated, interconnect, edit pages and that can be used to create collaborative web site
- support basic features of CMS
- separation of structure, layout and raw data
- integrated editing functionality
- version management, history mechanism, retrieval of former versions
- provide often special wiki syntax for formatting purposes and link creation
- can be used as a means for group communication
- various wiki engines available
- semantic wikis
- enable encoding of semantic data within regular wiki pages
- provide possiblities to annotate pages with meaningful relations to other pages and with attributes
- data can be used for semantic search (inline querying tools are available)
- provide RDF export functionality
"subject"+"predicate"+"object"