Vault 3.5 - Working folders

BigBrett · Post by **BigBrett** » Tue Jul 25, 2006 2:48 am

In Vault 3.1 we had a number of projects which had the same working folder. The main project supplied the source code and other projects provided dsw files for building various program versions.

Now, in 3.5, if we try to set the working folder for such a project we get an error message that the working folder has already been assigned to a number of repositories and we are unable to complete.

Any chance of going back to the original way of working, or is there a work-around so I can get the working folders set as I want them to be and not as Vault 3.5 thinks they should be ?

lbauer · Post by **lbauer** » Tue Jul 25, 2006 7:24 am

Using the same working folder for multiple repository folders caused a lot of problems with cache files being out of sync, files being overwritten, and other unexpected behavior for most users.

Vault 3.5 was changed so that you can have only one working folder per Vault project/folder.

You might be able to create a shared folder in Vault for those elements used by multiple projects. Perhaps if you can describe your setup in more detail we can suggest a workable solution.

BigBrett · Post by **BigBrett** » Tue Jul 25, 2006 7:56 am

We have a main application, let's call it A, consisting of an exe and a number of DLLs that has its dsw file, multiple dsp files and source files in one main Vault folder (obviously with sub-folders for each DLL).

Now we also have subsidiary applications, B, C, D and E which have their own dsw files that use a combination of the various dsp's from application A.

When adding the subsidiary applications to source control each dsw went into a different Vault project (when using 3.1). Each project had the same working folder and contains a single file (the relevant dsw). That was the way Vault set it up and that is the way we continued working with it.

One of the developers recent changed his working folder before getting a version of a subsidiary project and then found he could not set the working folder back to what he had before due to the error mentioned.

While I accept that 3.5 has changed the way this works for a good reason, and that I could probably move all the dsw files into one project folder and tweak SCC settings to make it work again, could we at least have an option to go back to the 3.1 way of working if required ?

lbauer · Post by **lbauer** » Tue Jul 25, 2006 3:49 pm

It's not likely that we'll change this. You were able to create a reasonable workaround for potential pitfall. But sharing a working directory can be a hazard for most users, and our goal is to make Vault as safe as possible for your source code.

BigBrett · Post by **BigBrett** » Wed Jul 26, 2006 1:33 am

Thanks for the advice. We've implemented the work-around and will change our work procedure to match.

jsynoski · Post by **jsynoski** » Wed Jul 26, 2006 8:34 am

lbauer wrote: Vault 3.5 was changed so that you can have only one working folder per Vault project/folder.

Linda,

Does this mean that if you have a Vault structure of
$
Manual 1
Manual 2

that the working directory of Manual 1 and Manual 2 cannot both be "My Documents"?

kasti · Post by **kasti** » Wed Jul 26, 2006 12:27 pm

Slightly offtopic but a suggestion: I get the feeling (also with past releases) that your release notes are not complete. Would be nice to have a complete list so your users are better prepared.

Thanks,
Kasti.

lbauer · Post by **lbauer** » Fri Jul 28, 2006 1:51 pm

Linda,

Does this mean that if you have a Vault structure of
$
Manual 1
Manual 2

that the working directory of Manual 1 and Manual 2 cannot both be "My Documents"?
_________________
Jim Synoski

That's correct. Vault's client side cache and baseline folders are designed with the assumption that there is one working folder per repository folder. If two repository folders have the same working folder (or if two users are using the same working folder), everything gets out of sync and bad things happen.

Slightly offtopic but a suggestion: I get the feeling (also with past releases) that your release notes are not complete. Would be nice to have a complete list so your users are better prepared.

Thanks,
Kasti.

We don't list every single bug that has been fixed, but we probably should be more diligent about listing those that will cause a change for users.