Re: [Duplicity-talk] Usability annoyance

[Ken Bass]

On 12/31/2011 8:10 AM, address@hidden wrote:
> On 30.12.2011 02:26, Ken Bass wrote:
> > Maybe I am doing something incorrect, but when listing collections (such as 
> > collection-status), duplicity prints out something like:
> >
> >     Chain start time: Thu Dec 29 19:08:30 2011
> >     Chain end time: Thu Dec 29 19:08:30 2011
> >     Number of contained backup sets: 1
> >     Total number of contained volumes: 1
> >     Type of backup set:                            Time:           Num volumes:
> >                     Full         Thu Dec 29 19:08:30 2011                       
> >     1
> this is because this output is optimized for user readability
Certainly that output is more readable and describes when the backup 
occurred in the local time zone, but it doesn't
relate back to the dataset created.

> > Or perhaps added to existing output such as
> >
> >     Chain start time: Thu Dec 29 19:08:30 2011
> >     Chain end time: Thu Dec 29 19:08:30 2011
> >     Number of contained backup sets: 1
> >     Total number of contained volumes: 1
> >      Type of backup set:                                                Time:   
> >                      Num volumes:
> >                     Full          Thu Dec 29 19:08:30 2011 (20111230T000830Z)   
> >                     1
> do you do more than one backup per day?  because if not you might easily use 
> 2011-12-30 as time value. check
> http://duplicity.nongnu.org/duplicity.1.html#sect8

I have heard of some people perform hourly backups. For me personally, 
this came up during testing while developing a new backend.
Some of my backups were mere seconds apart and I made those 
modifications to speed testing of various operations.
> i don't really oppose to your patch but i am not sure it is desperately needed.
It just seemed like a way to allow a user to pinpoint exactly which 
dataset they want to restore to. Sometimes people only care about
the date or 1D ago, etc. But sometimes it is useful to want to revert to 
a very specific dataset. Those who backup multiple times per day might 
appreciate it.
Specifiying '--log-fd 2' doesn't seem very friendly.