Maybe I'll get discussions and git opened up. For now, it's just a place to put it.
This is an update of the code/idea that ezrsync was based on.
It has had many changes in logic since it was forked and some bug fixes, but so has ezrsync.
Known (95% certainty) differences (mostly mentioned in previous discussion):
-ezrsync now has explicit support for multiple config files. That's great.
-ezrsync mostly has cleaner code formatting and probably structure (the word "mostly" is subjective ;) )
-ezrsync is a little more polished in things like warning the user about unrecognized config options.
-ezrsync has other changes that I have not fully explored yet.
-ezrsnapshots has an updated logic to determine which levels to sync into and which backups to delete. There are pros and cons to both but I preferred the coding simplicity and primarily fundamental safety of the new logic, which is why I changed it.
-As part of this logic ezrsnapshots will never reduce the number of backups presently stored even if the configuration retain value is reduced. This prevents accidental configuration typo disasters and guards against programming bugs. You can delete extra backups by hand. A feature should be added to request cleaning. An optional, pragmatically more complex implementation of the old sync logic that still meets this criteria was planned and started but never finished for lack of interest on my part.
-ezrsnapshots has a probably overly complex process control mainly as the result of my obsessive compulsion to get ALL program output sent to the screen and to the logfile, and as a result of my (here probably unnecessary) habit of trapping and controlling errors. To the user this probably doesn't mean much at all and to a programmer it borders on silly anyway.
There have been other bug fixes since the fork, some of those (at least 1 or 2 I think) were inherited by ezrsync and not fixed, some look probably fixed in ezrsync, and some were probably never even relevant to ezrsync with its restructured code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
By multiple requests (well 2 including pepa65) I've made a page with my latest update of ezrsnapshots.
https://sourceforge.net/p/ezrsnapshots/
Maybe I'll get discussions and git opened up. For now, it's just a place to put it.
This is an update of the code/idea that ezrsync was based on.
It has had many changes in logic since it was forked and some bug fixes, but so has ezrsync.
Known (95% certainty) differences (mostly mentioned in previous discussion):
-ezrsync now has explicit support for multiple config files. That's great.
-ezrsync mostly has cleaner code formatting and probably structure (the word "mostly" is subjective ;) )
-ezrsync is a little more polished in things like warning the user about unrecognized config options.
-ezrsync has other changes that I have not fully explored yet.
-ezrsnapshots has an updated logic to determine which levels to sync into and which backups to delete. There are pros and cons to both but I preferred the coding simplicity and primarily fundamental safety of the new logic, which is why I changed it.
-As part of this logic ezrsnapshots will never reduce the number of backups presently stored even if the configuration retain value is reduced. This prevents accidental configuration typo disasters and guards against programming bugs. You can delete extra backups by hand. A feature should be added to request cleaning. An optional, pragmatically more complex implementation of the old sync logic that still meets this criteria was planned and started but never finished for lack of interest on my part.
-ezrsnapshots has a probably overly complex process control mainly as the result of my obsessive compulsion to get ALL program output sent to the screen and to the logfile, and as a result of my (here probably unnecessary) habit of trapping and controlling errors. To the user this probably doesn't mean much at all and to a programmer it borders on silly anyway.
There have been other bug fixes since the fork, some of those (at least 1 or 2 I think) were inherited by ezrsync and not fixed, some look probably fixed in ezrsync, and some were probably never even relevant to ezrsync with its restructured code.