Thanks.
Since I would like to store my workspace file in source control, the name of the workspace will always be the same, and I may have multiple copies of it for different branches of the source code. I wonder if I will have collisions in the .vtg file name?
Now what happens if I check out 2 different branches of my source code, and the .vpw files inside the different "copies" of the source is the same?
I would be switching between different .vpw workspace files to work on different branches.
For example, I would have 2 .vpw in these directories:
/view/view1/source_code/workspace.vpw
/view/view2/source_code/workspace.vpw
Both workspace.vpw have it stored to save the tag files in $HOME/tagfiles/v19.
Each time I open the workspace, will it try to create "$HOME/tagfiles/v19/workspace.vtg"
So if I open view1's .vpw, then open view2's .vpw, will the workspace.vtg that was created for view1 get overwritten by the workspace.vtg that was created for view2?
Is there a way I could tell SE to apply the directory structure under the tagfiles directory.
For example, I would like the tag files to be stored as:
$HOME/tagfiles/v19/view/view1/source_code/workspace.vpw
$HOME/tagfiles/v19/view/view2/source_code/workspace.vpw
Then there will be no collision.
So maybe we SE could accept another entity like an environment variable, such as saying:
<Workspace ... TagFileDir="%(HOME)/tagfiles/v19/$(full_path_of_workspace)">
In Windows, $(full_path_of_workspace) would expand c:/dir1/dir2 to /c/dir1/dir2
How to solve the problem of having workspace stored in version control and multiple branches of version control have same workspace name?