resource competition?

[stephen01]

I'm running several compiler build tests nightly starting at 10:00 pm using Windows Task Scheduler and have received the following message from Vault Pro:

"<exception>System.IO.IOException: The process cannot access the file 'C:\Test\Software\CPU\cpu_core.h' because it is being used by another process."

I've staggered the build tests with 1/2 hour between each of them but I know that some of them will surpass the half-hour time. Is there a way to allow each process to have its own copy of common resources or will I need to make sure each process runs to completion before launching a second or third process? I'm guessing that this is the source of the error message but maybe my intuition is wrong...

[Beth]

If what you are using for builds allows you to set the location to get the file to, then you can change the location of the get for projects that share resources. That would pull down two copies of the shared items then.

You could also create shares in Vault so that the common components are all placed within the projects that reference them. I'm assuming each project has its own place on disk, which would mean each share is in a separate place as well. When you check in a change to one part of the share, the change is copied to the other shares.

[stephen01]

Thanks for your help.

I read the information on shares and it seems; if I understand correctly, that I can have any number of share copies in different locations on the repository. That way I could launch N builds and direct the compiler instances to use common resources from N different locations - thus avoiding the blocked resource problem.

Is there any downside to creating shared folders with the same information in different locations for the users who will be modifying these common resources (over time)? Ultimately I was trying to use the multi-core on my test PC more efficiently, however I could just as easily run tests sequentially from a master batch file that would allow each process to terminate before launching the next one, hence avoiding the common resource problem altogether.

[Beth]

The aren't any real downsides to sharing that I can think of. You can try it, and if you don't like it, the shares are easy enough to get rid of.