[ On Wednesday, August 9, 2000 at 09:32:14 (-0700), Glew, Andy wrote: ]
> Subject: RE: CVS'ing home directory files; CVS in place
>
> No. I mean "modify the production system in place, and then have
> those changes automatically checked into the repository".
Like I said, that's backwards. It's also not really safe. Changes
should be made, tested, and only then put into production.
Mind you when I do things like this on less important (not quite
production) systems I sometimes follow an "edit, install, test, edit,
install, test" loop until things are working fine and then I do the
commit of only the most recent working revision. I'd never tell anyone
else to do this though! ;-)
> What you describe is single level undo.
Strictly speaking, yes it was, but as as the manual section I quoted
said, it's easy to get infinite undo by using the numbered backup
option. However if you are using a versioning system together with this
trick then you only really need a single-level undo because all the
other levels are stored in your versioning system.
> Maybe I should have said "backwards propagation of changes".
> "Back annotated". Whatever.
Still sounds backwards to me! ;-)
> I want to be directly editting the "production" copy on my test
> machine, with all site specific strings, etc., expanded, and
> then check that back into the repository, with site specific
> strings unexpanded, etc., etc.
Well other than the fact that you've got a very difficult problem on
your hadn undoing string expansions, compilation, whatever, that's still
not really the accepted practice in proper configuration management, be
it of software, or systems config files, or whatever.
> If you will, I want a tool that automatically creates that
> Makefile.
I think you may be way too far off in the direction of incremental
development systems. CVS, and indeed 'make' and all of the other tools
you might use in a related environment, are almost entirely
diametrically opposed in philosophy to most incremental development
techniques that I'm aware of.
> Running the makefile is easy.
>
> Maintaining the Makefile is not so easy - don't tell me you've
> never encoutered a broken Makefile? - because it adds an extra
> level of indirection.
It's that extra level of indirection that makes the "running" step
easy. Without it you have to repeat all the steps it does every time.
Which would you rather do? Learn to go forward with the extra but
necessary step, or accept the error prone way of going backwards?
I.e. if you think you're going to have to do something, particularly
something semi-complex in that it has more than one step, more than once
or mayby twice then it might just be worth the effort of instead
developing a tiny program to do it for you and then you only have to
maintain that more general tool.
> Let's think about "builds" that don't expand site-specific strings
> - they just do things like change the names of files. That's a
> one-to-one mapping that doesn't lose any information in going from
> the repository to the production system.
As soon as you ignore those kinds of "build" steps they soon become far
more common than the corner cases you might have wanted them to be.
Even the BSD "install" program itself is a perfect example of a tool
that combines a multi-step process into a single, easily repeatable,
step.
> In such a system, editing a live file on the production system
> (which has its own issues for big multisystems, but is probably
> a reasonable thing for me to do, when "production" means a
> single user LINUX laptop), and you know exactly where to send the
> changes to in the repository.
You have to get out of that mold -- it's not good CM, and it's not
scalable; at least not using tools like CVS.
Just as you should never try to patch a binary and then try to fix the
code to match after you've got it working, so should you not try to
patch config files in place and then expect you can remember to get them
back into the repository.
The only way you're going to get anywhere near what you're thinking of
is to build the repository right into the filesystem. This has been
done, and those who've used it seem to think it works pretty good. Have
a read for yourself in this example of a publication describing the
concept and the results:
Practical Reusable Unix Software
edited by Balachander Krishnamurthy
pub. by Wiley (1995)
ISBN 0-471-05807-6
> Build processes are the best we have, but are unsatisfactory in general
> because they don't do backwards propagation, because directly editting
> the build results is occasionally necessary and can lead to inconsistencies.
The problem with build processes not doing "backwards propogation" is
the backwards mindset of those who want them to do it that way! ;-)
If you learn to always only modify the source and never the product
you'll be a long ways ahead in the battle to good configuration
management.
> Many famous bugs can be traced to use of non-reversible build processes,
> including, perhaps, Intel's FDIV bug.
Very few build processes are ever reversible in that sense. What you
want are repeatable build processes! Reversible build processes are
usually more a matter of reverse engineering (also discussed in the
above mentioned book).
IMPORTANT NOTE: You can have your cake and eat it too, in this
situation, and so long as you are not looking for a grand scheme of
scalable centralisation. Just use RCS (or SCCS) directly on the "live"
system files. If you use the "vc" mode in Emacs (or a wrapper around
your favourite editor that does as much), you'll never have to remember
to check things in because you will/can be forced to do so every time.
Obviously this doesn't solve everything (eg. renaming files, creating
links, changing permissions, etc.) unless you religiously use tools to
do these tasks too (eg. *BSD's mtree). I.e. CVS is not the right tool
for this job! :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
