We are currently in the planning stages for an application that is going to use a BA .NET rule service.
Our client demands that we use a versioned repository, and does not want to provide a CVS (only BVS, CVS or custom are available in BA .NET) server. Also, we will use a separate workspace authorization manager that will authenticate towards usernames/passwords on an authentication service that is not available/synced to an eventual CVS server.
So bottom line we are stuck with BVS for repository versioning system.
We will have a setup with a "production" RMA that will be deployed on a remote server.
For performance reasons, the BVS repository will most likely reside here aswell.
In our development environment we need to be able to work in parallell to the production changes, sometimes with conflicting changes. And we need to be able to cooperate, making changes available to other developers before they get released to the production repository.
Also, the same performance requirements apply here as for the RMA server; accessing a BVS file repository through a network share is slow.
The obvious solution would be to create a separate development repository and two way merge the two repositories before releases from the development team.
However, BVS/Blaze does not support merging.
One thought we had was to do checkout a workspace of the production repository using a system user, checking the workspace into the VCS the rest of the code uses (GIT) and mostly working offline in builder (works for new items and modifying checked out items).
This way developers can check in changes to the workspace with GIT, while still holding them back from the production repository until a release is imminent.
However, two people can't modify a BVS versioned file until a release is made.
Is there some experiences/best practice for dealing with this challenge?