4.1.1 - Several Vault folders to the same physical one?

[montek]

We upgraded from 3.5 to 4.1.1 this weekend and this morning, my DBA was upset because of what appears to be a new restriction in v4.1.1. Apparently you can no longer have several Vault folders point to the same physical path and get the following error instead:

The following repository path is already assigned to this working folder: $/database/db1

Is there any workaround or way to change this behavior? While I understand why technically you way not wish it to work this way, she's been using this feature in Vault for years to consolidate work into one physical folder.

[Beth]

This feature change is listed in the Vault 3.5.0 release notes. It's the very last item on that page. I'm not sure how you hadn't ran into that before.

Either way, I do have a way around this depending on the lay out. What some users do is create a new folder that is the folder that will have the projects beneath it and hold the working folder path. Then they share the items they want into it.

If you are using IDE integration, then with the Enhanced Client, you may be able to get around that. I know of a few that are running this way too.

Are you using IDE integration? Where were the working folders set at? What does your tree look like?

[montek]

For this particular situation, we're just using the Vault Client itself, not IDE integration. And your proposed solution would require sharing within the Vault structure which is not desired in order to help one person's workflow.

It wasn't clear WHY this feature was changed, but I guess we're stuck with it.

[jeremy_sg]

I can speak to the question of why. Vault keeps track of which files it manages in the working folder in the "state folder" where it maps repository information to local files. When there are two mappings, the state folder always gets overwritten by the last folder that updated. This means that there were lots of cases of files mysteriously going unknown, and a high probability of losing data in the working folder. It was decided that the most prudent course of action would be to disallow this workflow that could be dangerous.

[montek]

Thanks, Jeremy.

[jeremy_sg]

No problem, Monte.

[mcutter]

I find this restriction to be annoying and would like to propose that it is trivial to use namespaces for the state folder to avoid conflicts. One should be able to set working folders without having to nest folders. Please reconsider fixing this feature!

[Beth]

mcutter: I have a feature request open on that. I have added your name as a "vote" for it.

[SlyW]

We are considering Vault as a VSS replacement but have found this to currently be a deal breaker. Any chance that another vote be counted toward replacing this feature? It certainly would help convince us to switch (for now we have to stick with VSS).

Thanks!

[lbauer]

Yes, we'll add your vote, though we don't know when -- or if -- this might be implemented.

[jksteere]

I also vote to change it back. I just started this job after coming from another one that used VSS. I was working on procedures for our new project when I came across this problem. When you can't overlap working folders, it seriously limits or complicates the branching process. (Not sure which until I come up with a process workaround)

[Beth]

I've added your vote as well. Thanks.

F: 10904