duplicity-team team mailing list archive

[Michael Terry <mike@xxxxxxxxxxx>]

2009/8/5 Kenneth Loafman <kenneth@xxxxxxxxxxx>:
> So far, so good on the feedback.  Don't be afraid to complain if I'm
> doing something wrong.  I guarantee it won't be the first time.

Since you asked for complaints...  :)  I wanted to share my experience
with the new date format that went out a while ago.  I don't know how
much of the pain that caused on my end was visible at the time.

Since duplicity automatically defaulted to the new format, but didn't
try to interpret the old format, deja-dup (naively) would just run
duplicity, and it would start a full new-format backup, thinking there
were no files yet.

This was a problem, since now FAT32 users had two backup chains, one
with the old format, one with the new.

To workaround this, I quickly made a workaround release.  The fix was
to have deja-dup do a collection-status first (which it now has to do
for other reasons too, but these were earlier, more care-free days
;)).  If no files were found, it did a collection-status with the
--short-names option.  If files were found, it used that option for
the backup.

But there was still a window of opportunity for someone to 'lose' (via
the UI since old deja-dup wouldn't notice them) their old backups, if
they updated duplicity but not deja-dup.

Eventually I wrote the patch for duplicity that made it be able to add
new-format dates to an old-format chain, to really deprecate the
--short-names option.  But I still support that old duplicity version,
so I keep the logic.  Since I hope(!) to never bump the required
duplicity version, each workaround I have to add creates a maintenance
problem for me.  One day I probably will bump, and cleanup the code,
but for now, that's my policy.

So long story short, please consider how any change affects users that
don't have direct access to the duplicity command line.  I assume you
originally imagined users just changing their cron jobs for the next
full backup, so you didn't worry about it.

This has gotten better!  I again cite the happy willingness to have
duplicity sync caches without user intervention.  But for a while, it
was touch and go, with users having to delete their cache directories
if there were any sync mismatches.

Thanks,
-mt