steam0r
commented
1 month ago we are currently reworking backups, exacatly for this reason. thanks for your input!
Open TobyKLight opened 1 month ago
steam0r
commented
1 month ago we are currently reworking backups, exacatly for this reason. thanks for your input!
60-hz
commented
2 weeks ago I agree and continue to use the old subpatch op since they were very handy, even with their few bugs / limitations
Problem
Subpatches are useful both as modular repeatable units AND as unique sub organisation of your main patch. The latter is how the old subpatches used to work and I used them extensively for this.
The new subpatches they aren't included in backups, they are their own independent patch that is excluded from the backup history of the containing patch. This makes sense with subpatches intended to be reusable modules that are e.g distributed with teams.
For patches that are simply organisational parts of your larger subpatch this makes cables.gl backup and clone functionality a lot less useful. You have to be very careful if you make changes in such subpatches as they will change in older versions of your patch as well. And you can't rely if you restore a backup that you really get the old functionality back.
Feature request
Three versions of this feature request, from most to least complex.
Request A
Best solution that really makes backups work properly in all scenarios: Provide a separate and automatic backup history for all subpatches.
Then all subpatches will be restored to the specific version they were at when you a restore a backup.
When you restore a backup there is a tickbox to load latest live version of subpatches or load the backed up stale versions.
This automatic backup of subpatches should be triggered on every backup On clone it should be a tickbox, as you may be cloning to intentionally create a snapshot patch but also you may want to keep both original and clone using latest version of ops.
There are data management challenges here, for shared ops I guess the backed up ops should actually switch to versions saved in the patch namespace and not in their shared namespace.
e.g.
One problem is what about subpatches that contain subpatches... can also be backed up I guess but how to avoid recursive hell?
Request B
Provide the functionality above as an option only for subpatches that are in the namespace of a parent patch. Hence avoids the complexity of backing up subpatches shared between patches because these subpatches cannot be shared between patches.
Have a tickbox option for these subpatches 'include in backup history' that will automatically backup and restore these as above.
Request C
Bring back the old subpatches as orgapatches or something? Use those if you want unique organisational subpatches that are effectively just content of your main patch hidden in a folder.