More meaningful revision numbering

Feature
#1

I’m wondering: how much would it take to bake some information into revision numbers?

Currently revision numbers contain no information except the order in which revisions where created. What would it take to change the current revision numbering where current revision = previous revision +1 to a new system where current revision = date(YYYYMMDDHHMM) or something like that. To handle edge cases, you could even keep the sequential numbering and just append the date. But the benefit of scrapping the sequential numbering would be that ypu can easily delete och check revisions based on their date…

3 Likes
#2

It’s already there, no? When you run list you get version numbers and dates.

Adding interface for specifying revision to restore by date would likely easy to do – but would be of limited use: to know which date is available you would want to see list. And if you see list – it’s much easier to type the revision index than the date to restore.

#3

LOL, that’s exactly why I’d like the date to be baked into the revision-ID: you could work with dates directly instead of looking up the list. So:

No, that’s not what I want, it’s what I want to avoid.

Trying to explain it differently: it’s not just about targeting revisions, it’s also about being able to read what duplicacy tells you: when you work with duplicacy, you often see revision numbers (e.g. in logs) but they don’t tell you anything (except that some revisions are older than others). If those numbers looked more like dates, you would have a better idea which revision duplicacy is talking about.

1 Like