file
keep.py is a command and function that "keeps" a specified file by making a time stamped copy. it supports being configured in ~/.config/keep/config where i have mine configured to keep the copies it makes in a subdirectory named "keep". it used the date of the file itself for the time stamp. when keeping the same file again, it detects that the copy is already existing and does a compare and indicates the result in the one line message. when it makes this copy it says where it copied to or where it already exists and if it is equal or not.
i use this in my edit command script to keep the file i am editing each time i edit it, as well as keep the editor backup. so i will have older versions all the time (space is cheap). keep handles emacs backups (original name + '~') by using the original name. that way i have a 2nd chance to keep files. i also have it do that both before and after i edit the file. but keep is only keeping one file per edit change.
my keep subdirectory is just a little over 700 megabytes in size. not all of that is edited; somtime i just so a keep on files i want to keep a copy of.
(Nov-28-2017, 06:13 AM)Skaperen Wrote: [ -> ]i use this in my edit command script to keep the file i am editing each time i edit it, as well as keep the editor backup. so i will have older versions all the time (space is cheap). keep handles emacs backups (original name + '~') by using the original name. that way i have a 2nd chance to keep files. i also have it do that both before and after i edit the file. but keep is only keeping one file per edit change. my keep subdirectory is just a little over 700 megabytes in size. not all of that is edited; somtime i just so a keep on files i want to keep a copy of.
Never heard of
version control systes, like
Git? It's well worth the learning efforts..
(Nov-28-2017, 07:07 AM)buran Wrote: [ -> ] (Nov-28-2017, 06:13 AM)Skaperen Wrote: [ -> ]i use this in my edit command script to keep the file i am editing each time i edit it, as well as keep the editor backup. so i will have older versions all the time (space is cheap). keep handles emacs backups (original name + '~') by using the original name. that way i have a 2nd chance to keep files. i also have it do that both before and after i edit the file. but keep is only keeping one file per edit change. my keep subdirectory is just a little over 700 megabytes in size. not all of that is edited; somtime i just so a keep on files i want to keep a copy of.
Never heard of version control systes, like Git? It's well worth the learning efforts..
i have heard of then used SVN and HG (it's written in Python). but it don't like the process.
The problem is everyone knows a VCS like git or hg. So if you want someone to add better code to your programs, no one knows your keep file, but does know git or hg. Or even if you wanted to make a project with others, you wouldnt be ablet o use your keep, but git or hg.
Also if your computer crashes, or is burnt in a fire, your keep appear to keep it locally, where VCS does not.
There is a lot more that you can do in with VCS than your keep as well.
my keep method does not impose any new steps on what i do. i am looking into the idea of a automatic "archiver" that can check in for me with no action on my part, and produce patch sequences that so many people love.
FYI, the web site i am building for my company is being developed in SVN.
everything is incrementally backed up to AWS EFS storage.
Im just saying your reinventing the wheel. And usually that is not good, unless you plan on beating the competition. But if you just doing it because you didnt know about VCS, then it is there, someone has already built it, and everyone already uses it
in a technical sense, it could be said it didn't know about such tools. that's because i have been doing it this way since before those tools even existed. i didn't call it "keep" back then. it went through a number of names. i think the first one was called "TRACKER" and it was written in the EXEC2 language on VM/CMS circa 1978. it had a feature to export updates to the OS/VS2 batch system (and stored in a big PDS until they woul go to tape). i did that because i could write to tape more easily that way. i rewrote it into REXX in 1980 or so. i was thinking of writing a version in assembler soon after that but it never happened. i started writing one in PCL in 1984, got it to the point of working, but never really finished the error handling. that one made use of tools i had created to transmit files with ASCII to EBCDIC conversion from TOPS-20 to OS/MVS and VM/CMS. one of those tools was actually written in COBOL because i just want to prove to someone that i could make even COBOL do system stuff. today, i would use Python everywhere it was available, even for system stuff. i crossed paths with a few revision control programs when i got going on Unix an Linux (NeXT, Sun, Vax and more) and hated them all until Subversion which i actually found to be usable. a friend hooked me up with Mercurial which soon got me exposed to Python.
my experiences, of course, influence my preferences. but this is definitely not from lack of experience. and "keep" is just a component of newer ideas. in the beginning, source was IBM 360/370 assembler in fixed format 80 byte card image files. today, well... keep even support Perl.
It almost seems as though you don't like anything unless you wrote it.
in some ways it does come out like that. i usually run into most common problems and for many i find a workaround or develop a solution. when i do develop a solution, my personal approach to things has a substantial influence on how i make it work. then i have no need to be looking around for a solution ... at least for that problem. not everything goes this way, but many things do.
Are they really problems, or just conceived problems.
Sometimes, the solution can become the problem.
That is not to say you shouldn't plant the trees, so long as
it's not in my back yard, at least not until that tree becomes
useful to me.