You can collaborate on ReqView projects managed in Subversion (SVN) as described in Collaborate via SVN. To enable this type of collaboration, install SVN on your computer, set up an SVN repository and import your projects into SVN.
First, install SVN command line tools for your platform as described in Install SVN Client.
For testing purposes, you can simply install an SVN repository on your PC in a few steps:
Create a parent directory C:\SVN where you will place your SVN repositories (Windows example):
$ mkdir C:\SVN
Create a new repository ReqView under C:\SVN:
$ svnadmin create C:\SVN\ReqView
More information is described in Apache Subversion: Quick Start > Setting up a local repository.
For production use, your network administrator can set up a server to host an SVN repository storing your ReqView projects on our premises. For more information see SVN Book > Choosing a Server Configuration.
Or, you can host your SVN server in AWS cloud, Azure cloud, or choose a reliable SVN SaaS provider, such as Assembla.
SVN is very flexible and supports many ways how to organize repositories to fit different use cases, see Strategies for Repository Deployment. Let’s explain two typical repository layouts:
This section describes how you can lay out your repository if you have a simple product structure with a few linked projects and need to work with all of them easily. See the next section Advanced Layout if you have multiple products, subsystems, reusable components and need more control.
Create the following top-level directories in your repository: trunk storing the main line of requirements development, and tags storing requirements baselines. For each ReqView project, create a subdirectory of /trunk and /tags.
Example: Store the Example System Project in a repository with the following hierarchy of directories.
/ trunk/ STAKEHOLDERS/ SYSTEM/ SW1/ SW2/ ... tags/ STAKEHOLDERS/ SYSTEM/ SW1/ SW2/ ...
The main advantage of this repository layout is that you can check out all ReqView projects from a repository into a local working copy by running just a single svn checkout
command:
$ mkdir <working_copy>$ svn checkout <svn_repository>/trunk <working_copy>
This section describes how you can lay out your repository if you have many linked projects describing multiple products, subsystems, reusable components, etc.
The main advantage compared to the layout described in the previous section Basic Layout is that projects are better separated, and it is easier to work with selected projects only.
Group your projects into top-level directories in your repository. For each project directory, create two subdirectories: trunk storing the main line of requirements development and tags storing requirements baselines.
Example: Store the Example System Project in a repository with the following hierarchy.
/ STAKEHOLDERS/ CUSTOMER1/ trunk/ tags/ ... SYSTEMS/ SYSTEM1/ trunk/ tags/ ... SOFTWARE/ SW-1/ trunk/ tags/ SW-2/ trunk/ tags/ ...
Example: Import ReqView project CUSTOMER1 into a repository.
Create a new local project folder CUSTOMER1 to store the working copy of your project.
Create empty sub-directories trunk and tags in this folder.
In ReqView, open your project CUSTOMER1 and save it to the trunk. The working copy of your ReqView project should have the following structure:
CUSTOMER1 ├───tags └───trunk ├───attachments ├───documents └───project.json
Open command line from the working copy CUSTOMER1, and then import the project to SVN repository by svn import
command:
$ svn import <svn_repository>/STAKEHOLDERS/CUSTOMER1 -m "Initial import of ReqView project"
Most users are only interested in a small subset of all projects. For instance, they update stakeholder requirements for a specific customer. Or they develop a specific SW component.
There are two common ways to set up a working copy for a group of users with the same intent automatically:
svn checkout
commands for selected projects.svn:external
properties to check out selected projects.Note: Working copies containing a different set of linked projects should have the same fixed structure of directories to load the projects in ReqView correctly.
Example: Assume the repository storing the Example System Project shown in the previous example. Create a script to set up the working copy for developing module SW2, which needs to edit the latest version of SW2 requirements and see version v1.0 of SYSTEM1 and CUSTOMER1 requirements. Check out all projects as siblings of the working copy directory.
mkdir SW2-WScd SW2-WSsvn checkout <svn_repository>/SOFTWARE/SW2/trunk SW2svn checkout <svn_repository>/SYSTEMS/SYSTEM1/tags/v1.0 SYSTEM1svn checkout <svn_repository>/STAKEHOLDERS/CUSTOMER1/tags/v1.0 CUSTOMER1
Example: Assume the same repository and a group of users developing module SW2. Create a workspace directory and set its svn:external
properties to check out the specific versions of all needed linked projects.
Create folder WORKSPACES in the SVN repository and check it out to a working copy.
$ svn mkdir <svn_repository>/WORKSPACES$ svn checkout <svn_repository>/WORKSPACES <ws_working_copy>
Create a new directory SW2 for the workspace and add it to the local working copy.
$ cd <ws_working_copy>$ mkdir SW2$ svn add SW2
Open an editor (e.g., notepad) to set the svn:externals
properties for the working copy.
$ svn propedit svn:externals . --editor-cmd=notepad
Set the svn:external
properties in the editor.
^/SOFTWARE/SW2/trunk SW2^/SYSTEMS/SYSTEM1/tags/v1.0 SYSTEM^/STAKEHOLDERS/CUSTOMER1/tags/v1.0 STAKEHOLDERS
Commit the workspace to the repository to share it with other users.
$ svn commit -m "Set up SW2 workspace"
When another user checks out the workspace, his working copy is set up automatically.
$ svn checkout <svn_repository>/WORKSPACES/SW2 <sw2_working_copy>
You can start with managing versions of all ReqView projects in a single SVN repository and restructure the repository easily as needed. A little downside is that SVN uses the same revision numbers per repository. On the other hand, SVN revision numbers have no special meaning.
After some time, you may need to split your repository. For instance, when the repository contains too many projects or you need to restrict user access on the repository level.
To extract selected project(s) into another repository, run the following commands:
svnrdump dump
— create a dump file from an existing repositorysvndumpfilter include
— filter an SVN dump file to contain only the selected project(s)svnrdump load
— load a filtered dump file into the new repositoryExample: Extract ReqView project(s) storing stakeholder requirements from the repository structured as explained in the previous section.
$ svmrdump dump <svn_repository_orig> | svndumpfilter include "STAKEHOLDERS" | svmrdump load <svn_repository_new>
As an administrator, you can release project or document locks when the editor cannot release the lock from ReqView application, for instance if his computer is broken or if he leaves the company with a document locked for editing.
ReqView implements exclusive edit access using the svn lock
command. To break a project or document lock created by other users, run:
$ svn unlock --force <reqview_file>
Note: Breaking a ReqView file lock manually can lead to merging conflicts, which will be difficult to resolve manually. Try to avoid it whenever possible.