Workspace File Contents

[JVL]

Are there any documents describing the contents of a workspace (.cws) file. I am using CVS source code control and want to keep a copy of the .cws file in the archives but don't necessarily want to check it in unless the changes are pertinent, i.e. folders in workspace view changed, etc. Changes to open windows, etc. aren't so important and wouldn't prompt me to save them. I want to be able to diff two versions and understand the differences that I am seeing and make a judgement call as to whether I should check it in or not. Information on the project file would also be good but it doesn't seem quite so volatile.

Thanks,
John

[MJF]

I haven't seen any documentation for the file but it is a text file that is pretty self explanatory. It shouldn't be too hard to figure out the relevant items in it.

[cdk52]

Hello John.

The structures of both the Workspace and Project files are suitable for examination by the inifile.fp instrument. You could write a small utility which would compare relevant* sections of two workspace files and highlight the differences for you, providing some degree of automation.

Regards,
Colin.

* Selected using Ini_SetSectionFilter()?

[LuisG]

John,

The workspace file was introduced in CVI 6.0 precisely as a result of adding source code control integration to CVI. Previously there were only project files, and everything was saved in them. The reason for the split was to remove those things which tend to be strictly user preferences (window positions, breakpoints, debug vs. release, etc.) and that typically do not need to be shared. Those were moved to the workspace file, and the idea is that workspace files would therefore not need to be archived in a source code repository. Project files, on the other hand, contain information that is necessary in order to be able to build the project, so those would need to be shared by multiple users.
As a result of this, CVI does not assume that project files are writable (i.e. "checked out") but it does expect that workspace files are writable, and it will complain mildly when they're not.

Of course, this is just a loose guideline. There's no technical reason why workspace files can't also be shared, if need be. But I just wanted to let you know that the main rationale for having workspace files was that this was data that did not need to be shared.

Luis

[JVL]

Luis,
Thanks for your reply. Your explanation of workspace is consistent with other IDE's that I have used. I tend to work on single developer projects or at most, 2 or 3 developers. Workspace structure is the most important thing for me, i.e. what projects are included and any folders that have been created to contain certains types of files and their contents, i.e. source files. include files, etc. I only want to keep these structural changes and not information like how many open windows there are, etc. I usually do a compare to see what changes have been made and as mentioned before in this thread, most things are pretty obvious. I usually make a judgement call as to whether anything was significant enough to check in. I was just curious if anything described some of the fields like "Source Window State" with all those comma separated values. Call it an engineer's curiosity!
John

[rbaker68]

We seem to have a problem with version controlling this cws file. Turns out it shares information needed to build a distribution. We previosly thought the .cds file was a self contained package of distribution settings/defintions and that only the .cds file needed to be controlled. Not so says my config management guy, who has found web posts that the .cws file has some other neccessary information. So we need to control the CWS file too. Unfortunately we can't find a way to disable the save/discard prompt should we move or resize the IDE window. This thrashing is kind of a bummer. If anyone's got an "easy" fix that would be great. Otherwise we'll just keep grumbling about this and live with it. I think this is the cds related data that's important:

[Distributions]
Active Index = 1
AbsCDSPath 0001 Line0001 = "/c/zigs-sw-active/trunk/SP002"
AbsCDSPath 0001 Line0002 = "UI.cds"
RelCDSPath 0001 = "GUI.cds"

[Mert_A.]

In the past (pre-8.0), all the distribution information was contained in the .prj file, but in order to better support more flexible distributions that could include output from multiple projects, distributions are now workspace-associated (in .cds files).

The .cds file does contain all the settings needed to build a distribution.  The .cws just contains a list of references to the .cds files that are included in the workspace, very similar to the way it contains a list of projects that are in the workspace.  So, assuming you sync down only a project file, source files, and .cds file(s) from your repository, when you first open the project a default .cws workspace file will be generated for you. This workspace will not automatically include any distribution information; you will have to manually add any .cds files (via the Add button on the Manage Distributions dialog), but once the distributions have been added, you should have no problem building them.  So assuming you are willing to manually add all the source-controlled .cds files to the workspace the first time you run your project, I would not worry about source controlling the .cws.

Let me know if you have questions.

Mert A.
National Instruments