Re: How to Keep Track of Changes to the System
On 2017-08-26 05:14, ray wrote:
> I would like to find a way to keep track of changes I make to my system. It
> seem that I may learn from others on how they keep track of changes they make
> to their systems.
>
> When I make changes, I don't remember where I made changes or why.
>
> It would be great to have a log of what changes I've made, where they were
> made, how they were made (direct edit, scripted, etc.), why I made them,
> references that I used to determine the change, and what was the outcome.
>
> Right now, I get lost in my documentation. I research solutions, make notes
> in Onenote on a Windows machine, record configurations files that I will
> test. But It is difficult to record results such as syslogs or console
> transactions. More challenging is that I have different notebook tabs for
> different objectives. So when I want to see what I changed, I have to go
> through many different objectives because I don't know what object I was
> shooting for when I made the change.
>
> I would really like to hear how others track their changes or suggestions how
> I may tack changes.
>
> I store all the changes on a different computer because I screw up the
> installation on my machine under test and rebuild the OS. The laptop I am
> building to run Xen is on its 28th build.
>
> I would appreciate any suggestions.
>
> Ray
>
Hi Ray,
I just returned from a short holiday, so I am a bit late to the party, but... if
you don't want to set up a full versioning system I might have something else
for you. About 10 years ago I had the same need as you. What I did was write a
perl-script that automatically makes a timestamped backup of each file you edit
to a directory you define yourself (in that directory the full path of the
original is preserved). You use it like visudo, you just call it like this:
vicf <name of file to edit>
All the rest happens automagically.
Of course this will only help for plain-text files and it doesn't provide for
the annotations you mentioned. But if you are interested I
can mail it to you.
Grx HdV
P.S. Here's the output of the help so you can decide if this is what you need:
vicf --help
Usage:
vicf [options] <argument>
List of options:
[-h|--help|-?] [--manual] [-V|--version] [-r|--root <directory>]
[-d|--datetime <format>] [-n|--sequencenr <format>]
[-a|--append_sequencenr] [-p|--permissions] [-o|--owner] [-g|--group]
[-t|--times] [-b|--backup] [-x|--x_editor]
Options:
--help
Print a brief help message.
--manual
Print the full manual.
--version
Print version and copyright information.
--root
The directory under which a dated copy of the original file should
be stored.
--datetime
A format string suitable for strftime(). Together with the local
time this parameter will used as input for strftime(). The result
will be appended to the name of the target file. See man 3 strftime
for more details.
--sequencenr
A format string suitable for sprintf(). This will be used to
generate a sequence number, which will be append to the filename if
the target file already exists.
--append_sequencenr
Append a sequence number to the filename, even if it does not exist.
Used to start sequences at 1 instead of 2.
--permissions
Preserve the access permissions of the original file.
--owner
Preserve the owner of the original file.
--group
Preserve the group of the original file.
--times
Preserve the access and modification times of the original file.
--backup
Instruct the editor to make a backup of the original file. This is a
convenience option that has nothing to do with the dated copy of the
original file.
--x_editor
Start the editor in graphical mode instead of console mode.
At the top of the code there is a section named 'User-definable
defaults' where defaults appropriate for the current environment can be
set. Doing so alleviates the need to specify options on every invocation
of the program.
Arguments:
This program accepts only one argument, which is the path to the file to
be edited.
Reply to: