Re: CM tools vs versions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 18 Sep 2012 21:54:48 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>>> What you described is just *impossible* in the system I am
>>>> talking about. It just does not allow two versions of the same project
>>>> being both visible. No way. No problem. He would have exactly same path for
>>>> whichever version he selected.
>>> 
>>> What CM system is that? I've never heard of such a thing.
>>
>> It is a custom system on top of Perforce. But IBM's ClearCase does exactly
>> this.
> 
> Nonsense. I used ClearCase briefly a while ago, and I had no problem
> maintaining two workspaces with different versions.

So what is nonsense? You cannot have two versions of the same component in
the same baseline. (I hope I used the ClearCase UCM terminology correctly
here)

>> We split projects into smaller manageable (and testable) projects
>> instead. When the project is mapped it is fully usable, e.g. includes
>> all sources, binaries of this build. That is necessary for us because
>> we have many installations and when a customer reports we have to be
>> able to reconstruct his installation without rebuilding.
> 
> Which means you need different versions for different customers; exactly
> what I am saying.

So?
 
> Hmm, you are going to say "no, not versions, just configurations of many
> small projects". I still don't believe it. If one customer is using a
> configuration that was frozen 5 years ago, clearly that will involve
> different _versions_ than a customer just starting today.

I don't understand what you are trying to say here.

I will try again. When a project A needs a component represented by a
project B (e.g. a library), I tell the system that the scheduled *new*
version x of A will depend on some *released* version y of B. The system
will map everything needed for using that version into any view of A x.

Later I could schedule yet another release x+n of A dependent on B y+1
(when the latter is released). In fact our system has a "project update"
feature to pull all dependencies of a project to the latest versions while
checking consistency of those automatically rebuilding the new release.
This  saves a huge amount of work (and bugs).

Any actions on the project A do not influence its released versions and
under no circumstances any view of any version of A could see more than one
version of B or any other project.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de