duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] listing files in a backup session [SEC=UNCLASSIFIED


From: Aaron Whitehouse
Subject: Re: [Duplicity-talk] listing files in a backup session [SEC=UNCLASSIFIED]
Date: Wed, 26 Aug 2015 13:44:31 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

Hello Peter,

On 26/08/15 00:00, address@hidden wrote:
"you do not currently. feel free to offer a patch."

sure, what file contains the output and i'll look into learning a bit of
python ?
It isn't an area of the code that I'm familiar with, but on a quick look the output you have posted seems to be coming from duplicity/collections.py, perhaps from the BackupChain.__string__ method.

I'm happy to look, but it will take time to learn your code and learn
python too.

Take a look at the README-REPO file for some tips on getting set up with the code.

It may make sense as a first step to propose what you think the best solution is to listing the files in each collection-status collection here on the list (e.g. an enhanced collection-status output that displays the information that you need; a way of having collection-status output dates in a format that can be piped back to list-current-files; or extending list-current-files to additionally accept the output that is already displayed). Does anybody have a strong view on this? My gut feel is that the least invasive approach would be to extend the permitted input formats to list-current-files, as this would prevent any changes to the command line options or collection-status output (which other scripts may be relying on being in a particular format). The downside is that it means pulling out the further detail is still at least a two step process. Michael Terry, do you have any views on this? I know that deja-dup does some clever things with listing out previous versions of files for restore.

Once we've come to a landing on that, you could add an issue to the bug tracker suggesting that specific change and linking to the mailing list thread--then the idea will not get lost even if you do not have time to work on it. If/When you do have time to work on it, you can allocate the bug to yourself to make sure nobody else is working on it at the same time.

Uploading a branch and proposing that it be merged into the main codebase are two separate steps, so you could upload the branch and ask for comments if you would like more input.

Any new contributors to the project are valuable, so please ask if we can be of any help in getting you up and running.

Kind regards,

Aaron 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]