Requirements Gateway Relative Paths

[Hooovahh]

So I've been using Requirements Gateway for a little while now and I may be one of several developers using it, or one of several people maintaining documents within it.  We keep the Requirements Gateway project in source code control with the documents and code of the project it relates to. 

One problem we ran into was that requirements gateway is setup as an absolute path if the path is not below the requirements gateway project path.

Lets say I have a directory structure like this.

Q:\Project\Project [x]\Requirements Gateway\

Q:\Project\Project [x]\Project [x] Documentation\

Q:\Project\Project [x]\Project [x] Code\

When you add documents to the requirements gateway project it will add them with an abosolute path.  So if another developer gets the source code control on drive V:\ then it will not find the documents or code.  We found that you can manually edit the path of the documents to have a relative path by editing the .rqtf file manually in a text editor.

Finally to the problem.  This solution doesn't work for TestStand code, or LabVIEW code paths...why?  If I replace "Q:\Project\Project [x]\Project [x] Code\" with "..\Project[x] Code\" within the .rqtf project file, and then open the project it will say file not found.  The file might have been moved or deleted.  But all the documents that are setup to have relative paths work fine.

Can someone tell me how to get relative paths to work for LabVIEW and TestStand code in Requirements Gateway?  Thanks.

[Spectre_Dave]

I have around 50 Requirements Gateway Projects in VSS (I know it is obsolete but that is all I have - blame IT) but I do not see this problem.

What I did originally is to map VSS to be exactly the same as my C drive including all directory structures.  That way the VSS path is exactly the same as the path for all users.

It is a little cumbersome to setup initially but now no one has to think.

[Hooovahh]

---

@SPECTRE Dave wrote:

What I did originally is to map VSS to be exactly the same as my C drive including all directory structures.  That way the VSS path is exactly the same as the path for all users.

It is a little cumbersome to setup initially but now no one has to think.

---

Yeah I know that would make the most sence, and it is an option I guess.  But what makes this a little more difficult is that some engineers have a restricted TrueCrypt container for customers who have tighter restrictions on how their files need to be secured.  This means some engineers will have the project files in their C:\Projects\, some will have it in their TrueCrypt drive which can be any drive letter.  Some use Q:\, some use V:\ some use the next available letter. 

It is an option for this project to standardize on using a specific letter drive, but is this really that hard of a feature to implament?  I'm kind of surprised it's just not there by default since LabVIEW handles absolute and relative paths for all primatives that I can think of (and I assumed Requirements Gateway was written in LabVIEW but I might be wrong)

[Spectre_Dave]

I also have a shared drive where I mirror VSS. G:\Folder\Source  where source is mapped to the VSS project as C: with the identical stucture as C:\..  I have also brought the same stucture down to my truecrypt drive and brought it into windows xp virtual machine on my Mac - running parallels.  The trick is the stucture - I know the pain in setting up this stucture but the payoff is worth it. 

Each user would set the working folder to their HD or removable media. I have to occasionally rebuild my mirror site (network issues). I have to set my working folder to G:\Folder\Source >> get latest then reset my working folder to C:\

Good Luck

[Manooch_H · Accepted solution]

Hooovahh -

This is currently a lack of functionality for our TestStand and LabVIEW types in NI Requirements Gateway 1.1. This is something that we will likely fix in the next version of NI Requirements Gateway.

Thank you for bringing this to our attention.

[ncolson]

This is being fixed in RG 2014 (currently beta).  For 2012, the workaround is to use the "$ProjDir" macro to specify that the path should start from the project directory.  For example, to find a sequence file one level above the project, you would use:

$ProjDir\..\teststand.seq