Problem with folder sharing

[talamar]

I have the following folder structure on C:

Code: Select all

work
  |-- public
  |     |-- library1
  |     |-- library2
  |
  |-- solution1
  |     |-- project
  |
  |-- solution2
  |     |-- project
  ...

where "library..." folders contain sets of commonly used files (generally, headers). All solutions use files from one or more libraries from "public" (via #include directive).
Along with that, this folder structure representation in repository is the following:

Code: Select all

  $
  |-- public
  |     |-- library1
  |     |-- library2
  |
  |-- solution1
  |     |-- library1 (shared)
  |     |-- project
  |
  |-- solution2
  |     |-- library1 (shared)
  |     |-- library2 (shared)
  |     |-- project

where "library..." folders from "public" are shared to "solution..." folders.

The problem is: while getting latest version (for instance) of a solution, the library folders are restored to the folders within solutions ("c:/work/solution.../library..."). It produces unnecessary copies of libraries, while I need them to be automatically restored to their original location "c:/work/public", not to "c:/work/solution.../library..." folder, as it happens now.
Under VSS it makes no problem to set working folder for both references to "library 1" (within "solution1" and "solution2") to "c:/work/public/library1" and get the desired result. Under Vault it's prohibited.
Anyway. is it possible to get what I need, under current Vault version?
Thanks.
P.S.
I'm running Vault 3.5.2.5087.

P.P.S.
In general, Vault inability to support duplicate working folder paths means that the user may be unable to restore (get, check out, etc.) the files from repository exactly to the place, where they were checked in from. That's the problem.

[lbauer]

There's a way to do this -- I'll need to consult with our IDE specialist for details, and will post back.

[MKent]

I am curious if a solution was found to this issue. I have a similar situation that would probably be solved by the solution to this problem.

[lbauer]

You should be able to accomplish this without sharing. Instead, bind the class library to each project separately. That way you will have only one directory for the class library on disk (and in source control, for that matter.)

Here's how to set this up:

Assuming a directory structure like this:

work
|-- public
| |-- library1
| |-- library2
|
|-- solution1
| |-- project
|
|-- solution2
| |-- project
...


Note: these steps assumed the libraries are solutions or projects of their own.

Open solution 1. Right-click on the solution level, and choose source control ->Add Project from Source Control. Browse to the location of the class library. And click on the appropriate folder in the repository. You may need to check out the parent solution first, or it may be automatically checked out when you add the project. The solution file must be checked out because it is modified with information about the new project which has been added.

You also may get a prompt that there are already files in the working folder that correspond to the project in source control. You can click overwrite, or leave, either should work. Check in any items that have been checked out as a result of this operation.

Now the class library is part of solution 1.

Follow the same steps for solution 2.

The results should be that the class library is part of both solutions, but not physically shared.

[talamar]

Note: these steps assumed the libraries are solutions or projects of their own

The steps you listed appear to be working.
But you did not answer on my initial question.
I considered the case when "libraries" are sets (maybe large sets) of header (.h, .hpp) and/or source (.c, .cpp) files, not represented by separate solutions/projects?

[lbauer]

No, you can't with just files -- you're back to the sharing situation you described earlier.

If your files are not in a solution, you can create a class library project and keep all your files there.

[talamar]

If I create a class library project (within its own, separate solution), as you recommend, and then add this project (it has already been added to repository, and its working copy exists on disk) to another solution by IDE command "Add->Existing Project" (the project being added), following this way I get a problem with labels.
When I apply a label to repository folder to which this solution is bound, this label is not propagated to the project added and if I later decide to restore the revision of this solution by label, in this case the source code of that, "external" project, won't be automatically restored.
Is project sharing the only way out, which is currently available?

Will it be available in Vault 4.0, for instance, to label the solution, to which projects from other solutions were added, from within IDE and in the way that this label is also applied to all added projects, so that it would be possible to restore all these sources by label automatically?

[lbauer]

No, this won't be different in Vault 4.0. A workaround might be to apply the label at the common parent of all items. Then you can still get the inherited label with the Show Label command.