Wishlist/TO DO

  • Add a command to the pyqt GUI to delete the entirety of a “.archive” subfolder, with a text prompt to confirm (immutable files in this folder require a sudo/su to do that…)

  • Add a dialog to the pyqt GUI to allow deleting multiply selected files in a “.archive” subfolder, or files before a particular cutoff date (immutable files in this folder require a sudo/su to do that…)

  • Add Bitbucket repository support.

  • Add a logrotate file, to insure the service log does not get too large.

  • Make it compliant for Ubuntu Linux too (it presently has only been tested with Debian Bookworm…)

  • Add a “git” tab to the “Show Versions…” dialog that will render versions that are available for retrieval from a configured repository. [Presently you need to visit a browser’s git dashboard to inspect and retrieve files from a repo; versions in a hidden “.archive” subfolder can be retrieved directly and efficiently.]

  • Add a facility to such a “git” tab to delete multiple versions in a repository, with a text prompt to confirm doing so -possibly using a cutoff date.

  • Add man pages for the few shell commands there are (since repliversion was designed to be used in a desktop GUI like KDE, and there is a good online doc, this was not deemed a priority…)

  • Have a watch folder pick up new prune/skip/repo directives when a version.xml is directly edited (presently it requires a restart of the repliversion service, unless you are using the Dolphin file manager context menu choices for editing directives…)

  • Presently versions to be uploaded to a git repo are queued using folders of symbolic links. If “prune” directives are aggressive and there is latency interacting with the repo, it is possible for versions to get removed before they are posted to the repository. We need to add a file attribute (using “setfattr”…) to archive files to indicate to the pruning process whether a file still needs to be posted to a repo, so it does not delete it. Until then: don’t use “prune” directives that are much too aggressive; allow some time for the repository to be contacted.

  • Support for other Linux graphical desktops besides KDE (gnome? xfce?…)

  • Support for BSD: this can be challenging because BSD does NOT have an inotify API, though it has an analogous facility -so it’s possible.

  • Support for using EXT4 journaling info to insure any file being copied for backup will be completed before the source file is further modified. Presently the Linux “inotify” API is relied on, and for large files it is possible that a file copy will not be completed before the source file is modified once again. The author benchmarked “FUSE” (File System in USEr space), but found its performance and stability leaving something to be desired. Note that versioning large files can introduce the problem of faster consumption of disk free space! Keep in mind that with the way repliversion retains file versions, one can choose the versions they no longer need and thus automatically free up and efficiently conserve disk space.