You can collaborate on ReqView projects managed in SVN as described in Subversion section. To enable this type of collaboration, install SVN on your computer, set up an SVN repository and import your projects into SVN.
You can download SVN command line tools for your platform from Apache Subversion page. It is also bundled with many popular SVN GUI clients, such as Tortoise SVN for Windows after enabling command line client tools install option.
You can verify if the installation was successful by the following command:
$ svn --version
svn command is not found, make sure that Subversion executable binary is present in the system or the user environment variable
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 Subversion 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 — a basic layout for simple products with few projects and an advanced layout for complex products with many projects.
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.
The main advantage of this repository layout is that you can check out all ReqView projects from a repository into a 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.
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:
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 checkoutcommands for selected projects.
svn:externalproperties 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
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 repository
svndumpfilter include— filter an SVN dump file to contain only the selected project(s)
svnrdump load— load a filtered dump file into the new repository
Example: 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>