What is the best practise to organize different applications under VOBs

Question

This is a follow up question to this answer: https://stackoverflow.com/a/9579131/1204799

"It is best to create root-based components"

If I have several standalone applications (which means their development and deployment are independent), shouldn't I create different VOB to accommodate them? What I'm doing now is that, I have one single PVob, which contains a few UCM projects, each UCM project has its own Vob and baseline component(a component without Vob). Am I doing it the wrong way?

Updated at Mar-7 16:29

After taking your advice, this is what I am trying to do now:

1. I created a single PVOB to accomodate all the VOBs
2. I created one VOB for each business team, which, in my company, only three teams
3. I created one UCM project for each application. Each business team will host several applications, each application is rather independent, but every application may have more than one branch for parallel development, so there can be a lot of projects

Here comes my question: Now several applications are sharing the same VOB, how can I better manage the baselines so that they are organized by applications? i.e. to prevent accidentally choosing baselines of another project

Answer 1

It is best to use multiple components within a (generically) named Vob.

Making a component per Vob is not "wrong" per say, but you need to know that, once a component has been assigned a root directory (like a Vob), you can no longer change that root, or make any refactoring.

By "refactoring", I allude to the classic case where I create a component "MyProject" (with its Vob '\MyProject'... before realizing, for example, a few months later that 'MyProject' has actually a server and a client modules which could benefit from a separate history: I should have defined two components and not one.

With the "one vob per component" model, I have no other choice that to create another Vob: I cannot refactor, ie I cannot make a subdirectory within my existing component, and define a second component there.

With the "multiple components per Vob", I can:

• rename my first component as "MyProject_Server", with its root directory '\MyVob\myproject' (which remains unchanged: you cannot change the root directory of a component once created),
• make another component within the same Vob: "MyProject_Client", with a root directory '\MyVob\myproject_client'.

The main advantage is about scale: you can define many (hundreds) components within a Vob.
But you shouldn't define hundreds Vobs, because of the sheer number of processes (vobrpc_server and vob_server) required to manage the access to said Vobs.

---

If you create several components per Vob, that won't have any influence on the baseline choice for each project UCM.
Ie you would have as much risk of choosing the baseline of the wrong component, whether those components are a full Vob or are part of a Vob.

You would simply separate those components in different UCM projects, and manage each component baselines in those UCM projects.