10.05.2015 Views

Graduating from microsoft visual sourcesafe to ... - PVCS - Synergex

Graduating from microsoft visual sourcesafe to ... - PVCS - Synergex

Graduating from microsoft visual sourcesafe to ... - PVCS - Synergex

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

G R A D U ATING FROM MICROSOFT ® VISUAL SOURCESAFE TO MERANT ® S C M<br />

Promotion Models<br />

<strong>PVCS</strong> Version Manager solves the promotion model dilemma of SourceSafe. You can<br />

set up miles<strong>to</strong>nes <strong>to</strong> reflect the various lifecycles your software may pass through. For<br />

example, after the first baseline is created you may want <strong>to</strong> lock the associated code and<br />

start testing it.<br />

You would “promote” the baselined code (all revisions) <strong>to</strong> a miles<strong>to</strong>ne level entitled<br />

“QA_Test1.”<br />

You can restrict a user’s actions at specific points in the promotion model. For example,<br />

you may restrict a user’s actions such that they are not allowed <strong>to</strong> add labels, promote a<br />

file or delete files <strong>from</strong> “QA_Test1.” Visual SourceSafe does not offer the option <strong>to</strong> set<br />

this type of protection or restriction <strong>to</strong> user actions, based on the promotion level — t h e<br />

miles<strong>to</strong>ne — the code has attained.<br />

The Version Manager promotion system is based on a logical association between a revision<br />

of a file and a stage in the development cycle. These stages represent processes<br />

that normally occur in the development of a software application, such as development,<br />

testing, and production. There is no need <strong>to</strong> keep separate copies of files in different<br />

locations. Visual SourceSafe does not offer this type of functionality.<br />

Branching and Merging<br />

Being able <strong>to</strong> create separate threads of development — a c c u r a t e l y, au<strong>to</strong>matically<br />

and without file corruption — is key <strong>to</strong> enabling parallel development. Parallel development,<br />

in turn, is manda<strong>to</strong>ry for managing large development projects with any hope<br />

of achieving a competitive time <strong>to</strong> market.<br />

The limited capability of Visual SourceSafe in these areas can lead <strong>to</strong> lengthy development<br />

schedules, which in turn can cause dissatisfied cus<strong>to</strong>mers, features falling<br />

behind those of competi<strong>to</strong>rs, loss of revenue, escalating project costs, project backlog<br />

and developer frustration.<br />

Archive File<br />

Trunk<br />

1.4<br />

1.3<br />

1.2<br />

Merge<br />

1.1.1.1<br />

1.1.1.0<br />

Branch<br />

1.1<br />

1.0<br />

Revision<br />

<strong>PVCS</strong> Version Manager supports branching and merging of files <strong>to</strong> enable parallel development. There is no need<br />

<strong>to</strong> create separate project folders when branching files.<br />

But with <strong>PVCS</strong> Version Manager, users can branch their development so they can create<br />

a special release if they need <strong>to</strong>, and can later merge these changes with the original<br />

development path <strong>to</strong> create the next main release. Teams can make multiple enhancements<br />

in parallel without corrupting files or creating new, separate project databases.<br />

M E R A N T<br />

9

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!