> > Subject: RE: CVS'ing home directory files; CVS in place
> >
> > Actually, I will happily use a build procedure,
> > if it is reversible.
>
> Hmmm.... reversible...
>
> Do you mean like combining these options to the "install" program with
> something in your build system that'll rename the (most recent) backup
> copies to their original names and thus effectively undo the
> most recent build?
No. I mean "modify the production system in place, and then have
those changes automatically checked into the repository".
What you describe is single level undo.
Maybe I should have said "backwards propagation of changes".
"Back annotated". Whatever.
> > E.g. once I have checked out the file called
> > dir/foo in the repository
> > and had it renamed via the build procedure to dir/bar,
> > then, if I edit dir/bar,
> > I want to have a command that will take the changes
> > I make to dir/bar and apply them the file named dir/foo
> > in the repository.
>
> I think that's "backwards", if I might say so....
I thought that you might.
> You want to be changing the checked out copy and then
> installing it into the "production" location, perhaps
> after first testing it, and of course performing any
> necessary transformations (such as compiling, or
> replacing place-holder-tags with site-specific strings, etc.)
> on the way through....
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.
> > Basically, I am often too lazy,
> > and find the process too error-prone
> > of editting dir/bar in my workview,
> > tracking down that it maps to dir/foo in the repository,
> > and then arranging to check it in there.
>
> Ah, but that's where a makefile or some other build and/or install
> script makes thing so easy! It "remembers" everything for
> you *and* it
> takes care of all the messy details and boring redundant steps. You
> just have to invoke it when you're ready and then sit back and relax
> while all the magic happens....
If you will, I want a tool that automatically creates that
Makefile.
Actually, not so much: 90% of the time, the Makefile
is overkill.
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.
> > Similarly wrt symlinks, etc. --- any build process
> > that is one to one, and even many that just extract info
> > from a multiversion form.
>
> ?
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.
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.
Similarly, if your repository contains a Makefile, and the Makefile
creates a lot of symlinks one by one:
make_symlinks:
...
ln -s foo/bar baz
...
If you edit the link baz to change to fu/bar, again, in this situation
it is straightforward to propagate this change back to the repository.
Now, there are two ways you can react to the statement "it is
straightforward to
propagate this change". Either you can say "it's easy to do by hand", or,
you can
be like me, and say "how do I automate it"? I.e. how do I create a generic
tool
that does such backward propagation?
It's a bit more challenging if you expand variables
FOO=local_foo
make_symlinks:
...
ln -s $(FOO)/bar baz
ln -s $(FOO)/bar1 baz1
...
but, again, there is hope for automatability.
If we changed the symlink local_foo/bar1 to point to local_foo/BART1
rather than baz1, it can be backwards propagated straightforwardly.
If we changed the local_foo part to local_fu, automation can detect,
flag that a site specific variable was expanded, warn if not all instances
of the site specific variable were expanded, etc, etc.
Similarly for the general process of expanding variables.
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.
Many famous bugs can be traced to use of non-reversible build processes,
including, perhaps, Intel's FDIV bug.
