Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!sdsu!lll-winken!xanth!mcnc!thorin!unc!cheung
From: cheung@unc.cs.unc.edu (Clement Cheung)
Newsgroups: comp.software-eng
Subject: Re: Source Code Control
Message-ID: <8713@thorin.cs.unc.edu>
Date: 3 Jul 89 21:39:19 GMT
References: <133@tirnan.UUCP> <39400035@m.cs.uiuc.edu>
Sender: news@thorin.cs.unc.edu
Reply-To: cheung@unc.cs.unc.edu (Clement Cheung)
Organization: University Of North Carolina, Chapel Hill
Lines: 68

In article <39400035@m.cs.uiuc.edu> render@m.cs.uiuc.edu writes:
>
>
>Written  6:35 pm  Jun 27, 1989 by cheung@unc.cs.unc.edu:
>>By the way, I have been reading over 20 technical papers on SCM systems
>>in the past few weeks but I didn't find any which deal with management
>>of object codes. Also lacking is the relationship between SCM and quality
>>assurance. Almost all systems assume that object codes can be derived
>>when necessary. But let suppose. 
>> [Problem statement of controlling 2 sets of source and binary for 4 
>>  different platforms.] 
>
>I'm not sure what the problem is that you are trying to state.  If the 
>problem is "we don't have enough disk to keep all this stuff around at 
>the same time," then you're hosed unless you can schedule work so that you
>don't need everything around at once and can reproduce stuff on demand.  
>You can ensure this by recording the manufacture steps used to create 
>the executables and making sure that all the inputs to the manufacture
>steps are either on disk or are reproducible.  
>
>If the problem is "we have to keep clear which object code corresponds to
>which source and make sure that this is kept straight," then take a 
>look at the DSEE description of the derived object pools.  Everything
>that is made as the result of some DSEE manufacture step is placed in
>the DOP and uniquely identified.  There is no way for Joe Johnson to
>accidentally overwrite Bill Benson's object file, and each person's
>objects are distinguishable from the other's. 
>
>I dunno, I may be missing your point, in which case I welcome enlightenment.
>
>render@cs.uiuc.edu

It sounds attractive to keep all parameters of the software build steps
so that hopefully you can reproduce an exact copy of the executables at
a later time. However what is not said is that you must put your compilers,
linker, loader under version control as well. Moreover, if we are talking
about manufacturing large scale software then you are not going to 
regenerate your executables when needed. You simply won't have time to
do that. Suppose you are asked to produce a fix for this large scale
software version 3.5 within 24 hours, you might just be spending all those
time rebuilding the executables. That leaves you no time to test your
fix. On the other hand, if the executables is available, the fix can be
applied by patching that executables. So this is one reason why software
house tends to keep their executables around. I don't think I explained
this clearly the first time.

Realistically, can it be guaranteed that the regenerated executables
is 100% identical to the one you built the first time everytime ?

[Archiving happens when you are in leisure; regeneration happens when 
you are time crunched.]

Bearing the aforesaid in mind, suppose your software runs on different
Unix platforms. Since they are not binary compatible, you want to keep a
copy of each of the versions for each of the platform. This is a lot of
copies of the executables for the same large scale software. There
simply is a need to device some scheme to manage the executables.

The assumption that all SCM system made concerning regenerating executables
when needed breaks down in this scenario (IMHO). The production aspect
of configuration management (or is there a better term) is simply
neglected. I guess this is closer to what you called release engineering.

If there is a byte oriented delta technique, could that be used to find
the deltas of object codes ?

Clement Cheung
cheung@unc.cs.edu