| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
Return to WebRCS page
web revision control system -- product specs revision 0.2 - 9.3.98 1. Server Interface a. Installation i. Java 1.1 application ii. should have both text-only and AWT interfaces iii. uninstallation as well? (possible future) b. Web Server Integration i. CGI (Java Servlets) - Java 1.1 API only (no use of 1.0 techniques) - possibly look at support for Java 1.2 API ii. standard HTML's - upload/download from client - information presentation - server-side configuration iii. standard graphics (jpeg/gif, possibly png) iv. which server? - I personally will be developing under Apache and doing some testing with MS Personal Web Server (similar to IIS) - should be as server-independent as possible 2. Client Interface a. Web Interface i. standard HTML's - upload/download to server - information presentation - client-side preferences ii. standard graphics (jpeg/gif, possibly png) iii. perform standard rcs functions - access (view) a resource, area, project - upload a resource - download a resource - create a resource, area, project - relocate a resource, area - rename a resource, area, project - build a resource, area project 3. Resource Database a. Security Checks i. server-implemented - useful for settings rcs-wide protection (i.e. first line of defense if the rcs database is stored on a publicly-accessible website) - shouldn't use server passwords within the rcs database structure (may interfere with normal rcs security operation) ii. rcs-implemented - can lock individual resources, areas, projects - can set members for individual resources, areas, projects b. Resource check-in i. be sure to check member's upload permissions for resource ii. use HTTP upload c. Resource check-out i. be sure to check member's download permissions for resource ii. use HTTP download d. upload/download locations (see server and client interfaces) e. Types of Resources i. files - source code - graphics - HTML - plain text - user-defined ii. notes - memos - bug tracking - user-defined f. Organization of Resources i. projects - top-most level is populated by projects - has a director who is "super-user" for the entire project - one "super-user" for the entire system (i.e. all projects) - stored in individual directories on web server - should be able to define "make" rules for a project, with the ability to include areas in the build - can set list of members or groups who can initiate a project- level "make" or "build" ii. areas - stored in individual directories under projects - should be able to rename areas with ease - should be able to define "make" rules for an area, with the ability to include resources in the build - can set list of members or groups who can initiate an area-level "make" or "build" - "upload/download all" (i.e. all resources contained in the area) feature needed iii. resources - stored in individual files under areas - represent the working pieces to each project - should be able to rename or relocate resources with ease - can set individual permissions for each resource by way of a list of members or groups with the following permissions: + view + upload + download + create + relocate + rename + build - should be able to define "make" rules for a resource iv. members - one or more members for each resource, area, or project - should be able to group members into one or more groups v. builds - separated storage for finished products - can set list of members or groups who can access individual builds vi. storage - projects, areas, and resources are represented by directories and files within the web server document root - all information should be maintained in a database, most likely a SQL database that will be accessed using JDBC f. logging i. should keep careful track of all actions performed - access (view) a resource, area, project - upload a resource - download a resource - create a resource, area, project - relocate a resource, area - rename a resource, area, project - build a resource, area project ii. should be able to control which of the above events are logged and how much detail is provided (logging/debug level) iii. the logs themselves should be treated as a resource so as to allow access control by different members
Return to WebRCS page
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|