Samselvaprabu
Samselvaprabu

Reputation: 18147

checkin or not checkin which will be preferred in clearcase UCM?

In our build system ,once build is over ,assemblies also will be check-in . But When we were moving to UCM , architects divided in this opininon. Few people supported check-in the compiled assemblies and msi and few were opposing it.

when we were check-in ,we simply do symlinks and it gave us great advantage. Moreover when check-in was done ,it will be removing entries from bin and release folder instead of copy. It helped us lot. Every day people were able to work with latest assemblies check-in by nightly build. Now they are not able to do that. They want me to copy the Nightly build dll to some common place.

On other hands due to every day check-in our repository grows humungous.

I don't know what was the best option.

Can you share your thoughts about which method is better? Is it better to check-in assemblies in UCM/Clearcase or not?

Upvotes: 1

Views: 126

Answers (2)

VonC
VonC

Reputation: 1324577

Another reason against checkin assemblies in ClearCase is the lack of clean-up feature possible: you cannot easily rmver some versions you might not need without potentially compromising the Vob repo.

This is especially true in UCM where metadata and hyperlinks are added to versions, making the removal of one quite dangerous for the integrity of other objects (like an UCM baseline) depending on it.

For the other, more general, reasons for not versioning binaries, see "Is it good practice to store framework runtimes under source control?" and hsalimi's answer.

Upvotes: 1

TonySalimi
TonySalimi

Reputation: 8427

AS a practice, all build outputs should not be kept under source control. But, you have to keep them on a common place until they expire. The philosophy behind this practice is:

  1. The repository size gets larger as you add binaries to it.
  2. The old versions of an assembly produced in a nightly build (belongs to 2 years ago) are useless. On the other hand, the old version of source codes and its history are useful all the time.
  3. In addition to the build results, software products are usually dependent to third party components. These third party components are usually evolved and their newer versions are usually released. Keeping build results in the source control, you have to keep the right version of third party components somewhere else.

Upvotes: 2

Related Questions