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.