org.opensolaris.opengrok.history
Class RazorRepository

java.lang.Object
  extended by org.opensolaris.opengrok.history.RepositoryInfo
      extended by org.opensolaris.opengrok.history.Repository
          extended by org.opensolaris.opengrok.history.RazorRepository
All Implemented Interfaces:
java.io.Serializable

public class RazorRepository
extends Repository

Adds access to to a Razor Repository http://www.visible.com/Products/Razor/index.htm A brief and simplistic overview of Razor Razor uses the term 'Group' for what might traditionally be called a repository, that is a collection of files and folders. A collection of Groups is called a 'Universe' in Razor. Razor supports multiple Universes, and these are the units which can be independently started and stopped. A universe usually consists of on issue tracking data set called "Issues", this is managed from a user perspective by a GUI called 'issues' or a web interface called 'issue weaver'. Each group has a file repository, managed by a GUI called 'versions', and an associated GUI called 'threads' is used to collect together related versions of files into a "Thread", which can be thought of as a like a tag against the repository, but is managed outside of the file repository itself. From the point of view of the user, they raise an issue to document a unit of work, make changes to a collection of files against that issue, and then combine one or more issues into a thread to represent a releasable product. Of course, there is more to the product then this brief outline can do justice to but these general concepts should assist in understanding the concepts presented in the OpenGrok Razor Repository interface. At an implementation level, a Universe consists of it Issues database, and one or more Groups each consisting of file repository and thread repository. Each of these repositories is implemented with a series of directories (Archive, History, Info, Scripts and Tables). When file revision control is needed on a file (both committed files and some internal implementation files), Razor supports the use of either SCCS or RCS for non-binary files and numbered compressed instances of binary files. Each file is given a unique (per universe) numerical identifier in the file .../razor_db//RAZOR_UNIVERSE/Mapping, this is used by Razor to track files over time, as they renamed or deleted. Unfortunately, the Razor command line interface does not support features that other SCMS support like 'log' and 'annotate'. Also, Razor check-outs leave no indication that the files are from a centralised repository, so it will not be possible to implement this module from a copy or check-out of the repository, we will have to access (in a read-only manner) the actual repository itself, extracting the information directly or via SCCS/RCS interfaces. IMPLEMENTATION NOTES: The Razor implementation used for development and testing of this code has the following properties which may affect the success of others trying to use this implementation: - Multiple Universes - Each Universe had Issues databases - Each Universe has multiple Groups, with Threads but no Projects - The file repository format chosen was the non-default implementation, that is, RCS rather than the default SCCS implementation - Binary files are compressed with the standard UNIX 'compress' tool - Not all Groups would be suitable for OpenGrok analysis - Use of Razor command line interface was deemed impractical - The use of the Mapping file and the tracking of renamed and deleted files was deemed too complex for the first implementation attempt - The Razor implementation was on a single Sun Solaris SPARC Server - The code development/testing used NetBeans-6.1 and Sun JDK 6 Update 6 The initial implementation was to create symbolic links in the SRC_ROOT directory to the Razor Group directories you wished OpenGrok to process. The Razor implementation of HistoryParser and DirectoryHistoryParser were functional, but the file analysis infrastructure could not support the virtual filesystem that I was creating in my implementation of the DirectoryHistoryParser for Razor. Essentially I was trying to make a virtual file system, and remap all file names as required, but the file analysis code assumed it could just read actual directories and process their contents. I would have had to implement a VirtualFile and possibly VirtualFilesystem classes, recode the file analysis framework and develop Standard and Razor implementations. THIS APPROACH HAS BEEN ABORTED!!! The implementation now requires that you checkout a read-only copy of the directories you wish OpenGrok to process, and place in the top-level directory of each, a symlink called ".razor" to the Razor Group directory for that folder. Example: if you have a universe called MyUniverse, containing a group called MyGroup with top-level folders called Documentation and Implementation. Then in SRC_ROOT (or a sub-directory of it), check-out read-only say the Implementation into $SRC_ROOT, and create a symlink called $SRC_ROOT/Implementation/.razor which points to a directory of the form /razor_db//RAZOR_UNIVERSE/DOMAIN_01/, so that might be /repository/razor/razor_db/MyUniverse/RAZOR_UNIVERSE/DOMAIN_01/MyGroup Because of the distributed nature of information storage in Razor (by this I mean, that each file in the repository is represented by files of the same name (and path) under multiple directories (Archive, History & Info)), I'm continuously mapping SRC_ROOT based names into the appropriate subdirectory of the actual repository. The current implementation assumes the use of a UNIX platform, but I will try not to hard-code too much in relation to these assumptions. Also I have not worked Java for almost 8 years now, so please forgive any oversights in this regard.

See Also:
Serialized Form

Field Summary
 
Fields inherited from class org.opensolaris.opengrok.history.RepositoryInfo
datePattern, directoryName, remote, type, working
 
Constructor Summary
RazorRepository()
           
 
Method Summary
 java.lang.String getOpengrokSourceRootDirectoryPath()
           
 java.lang.String getRazorGroupBaseDirectoryPath()
           
 void setDirectoryName(java.lang.String directoryName)
          Specify the name of the root directory for this repository.
 void setOpengrokSourceRootDirectoryPath(java.lang.String opengrokSourceRootDirectoryPath)
           
 void setRazorGroupBaseDirectoryPath(java.lang.String razorGroupBaseDirectoryPath)
           
 
Methods inherited from class org.opensolaris.opengrok.history.Repository
getDateFormat
 
Methods inherited from class org.opensolaris.opengrok.history.RepositoryInfo
getDatePattern, getDirectoryName, getType, isRemote, isWorking, setDatePattern, setRemote, setType, setWorking
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Constructor Detail

RazorRepository

public RazorRepository()
Method Detail

setDirectoryName

public void setDirectoryName(java.lang.String directoryName)
Description copied from class: RepositoryInfo
Specify the name of the root directory for this repository.

Overrides:
setDirectoryName in class RepositoryInfo
Parameters:
directoryName - the new name of the root directory

getOpengrokSourceRootDirectoryPath

public java.lang.String getOpengrokSourceRootDirectoryPath()

setOpengrokSourceRootDirectoryPath

public void setOpengrokSourceRootDirectoryPath(java.lang.String opengrokSourceRootDirectoryPath)

getRazorGroupBaseDirectoryPath

public java.lang.String getRazorGroupBaseDirectoryPath()

setRazorGroupBaseDirectoryPath

public void setRazorGroupBaseDirectoryPath(java.lang.String razorGroupBaseDirectoryPath)