Re: Is CM important? (CM as file motel)

Re: Is CM important? (CM as file motel)

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!z]

> jls@netcom.COM (Jim Showalter)
>> jcallen@Encore.COM (Jerry Callen)
>> Real programmers make mistakes: [....] I like to check in after every
>> edit, so all those errors are visible.  Or would you rather see an
>> afternoon of work go down the tubes because of a power flicker?
> This makes no sense to me. If I have saved a file to disk, it is saved
> whether it is checked in or not. I don't check in stuff I'm not yet happy
> with--why would I want to store line differentials on a piece of crud?

In terms of "saving the afternoon's work", I agree with Jim.  But most
(Unix) file systems don't save things explicitly deleted, either at the
text-in-a-file level, nor at the file-in-the-filesystem level.  Thus, it
can be very difficult to back out a disastrous change, or even more
common, *part* of a disastrous change, retaining some of it.

Now, some people think the function of maintaining a very small grain
history is the job of the filesystem.  Others think it is the job of the
editor.  Still others (as we see above) think it is part of configuration
management.  I have sympathy for all of these viewpoints, but IMO, whichever
conceptual bucket such history-keeping is placed in, it should not be
necessary to explicitly ask (via check in) to have each element of this
history created.

For example, if your editor is doing this for you, it should have an
option to keep "undo" information across edit sessions as a globally
settable configuration option.  If the filesystem is doing it, it should
keep a version of each file whenever the file is closed after writing. 

The less frequent road taken, having the CM system keep
small-granularity history, is however also done occasionally.  In this
case, I think the "natural" way of doing it in a Unix-like environment
is to have automated construction a-la make save any "new" version of a
file it encounters.

Now, as Jim points out, keeping history at this level of granularity
also captures many versions that ultimately turn out to really be
worthless.  Thus, if it's being done via a CM/automated-construction
system, such a system really ought to have the ability to purge old
versions of files/sources not part of "released" (or otherwise blessed)
versions of configurations.  To reduce irrelevant detail presented to a
user browsing the history, even if storage space is not a consideration. 

But the question still remains: why would one *want* to keep history
at such a fine level of granularity in the first place:

> The only reason I can see for checking something in is to have a record
> of milestone to which I would WANT to return should I decide I want to
> revert later on. I hardly think I'm going to want to revert to something
> shot full of syntax errors, letter transpositions, and logic errors.

Ah, but you may well have put those errors in on top of some good (but
incomplete) work.  Thus, the ability to back up to versions with quite
fine granularity can be crucial, and has saved my bacon no small number
of times.  

Not that I couldn't have gotten along without this CM feature, either
with the editor, or with versioning filesystems, or by saving copies to
the side "by hand", or whatever.  But it seems to me that this sort of
clerical convenience is very close to the core of what CM is all about. 
After all, one *could* keep track of configurations by file versions, or
by archival backups, or whatever. 

And of vital importance in this, it seems to me, is that one shouldn't
have to explicitly ask for it to be done, via "check-in".

--
(Note the followup setting)
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw