rdiff-backup-users
[Top][All Lists]
Advanced

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

Re: [rdiff-backup-users] More newby Qs: list of changed files, server-si


From: Bud P . Bruegger
Subject: Re: [rdiff-backup-users] More newby Qs: list of changed files, server-side diffs
Date: Fri, 22 Nov 2002 12:36:35 +0100

On Fri, 22 Nov 2002 00:24:51 -0800
Ben Escoto <address@hidden> wrote:

[...]

> Sorry, could you rephrase the last clause; I'm not sure I understand.

I looked through the code and it seemed that (for me personally) to understand
where to put hands, I had to invest more time than writing an external script.
That is not to say there is anything wrong with your code -- it seems written
very cleanly and eligantly.  

To give you details, I started with manage.py and couldn't figure out where
Manage.find_incrps_with_base was defined.  [Is it a left over of an earlier
version?].  Then I did a better job reading Main.py and moved on to
Restore.get_inclist.  I couldn't figure out what rp stands for: p is path?,
r=?.  I looked at rpath.py but didn't understand from the module description
what rpath actually was.  I should have gone on reading the code--but thought
it was much quicker to wip up some external script calling shell's find and
base on your excellent doc of the data format.  I'm lazy and wanted to stay
closer to known turf.  So, it seemed quicker to write an external tool..  

> But anyway, just to avoid duplication of effort, I just hacked
> together a --list-changed-since option which may do what you want.
> See the attached patches.

Seems I made you work very late!  Thanks a lot for the patches.  Will try them
out this afternoon (your morning) and give feedback.  

>   BB> BTW, I'm asking some of these questions since I may write a web
>   BB> frontend for easy restoring of files..
> 
> Someone expressed a desire to do this before (that is why I added
> --parsable-output) but I never heard from them.  Let me know if you
> need anything.

I noticed since first thing I did was look through the list archive to see
whether someone has already done it or is working on it..

I still need the final go-ahead from my customer to start, but we have already
decided to look into the possibility more closely.  I believe they have no
problem if the tool is released under an open source license.  

It would be great if someone was interested to discuss the design of the
frontend.  I need to do something minimal for starters and take the specific
needs of my customer in consideration--but maybe additional input could lead to
a much more general tool at the same effort.  

I actually already use a wiki to document my ideas.  I have to ask whether
security policy allows that I publish the URL to this mailing list.  

In any case, I'll write a separate message to the list with my initial ideas.  

>   BB> I have to check with my users, but if they want it, I may
>   BB> contribute
> 
> If you plan on doing anything substantial, let me know and I will try
> to move the CVS to Savannah to make things more convenient.  I've been
> meaning to do this but there is a bit of work to be done first.

Many thanks for the offer, but there is time to do that (see above).  One
option would be to interface with rdiff-backup's cli.  In this case I'd
probably not need any access to CVS...  But this is just my first idea and I'd
be more than happy if someone convinced me otherwise.  

>   BB> ok, so that is OS dependent but works if I read it in as python
>   BB> time on the same platform...
> 
> Would some other format be better?  I'm not sure anyone uses
> --parsable-output.  The plan was that the format could/would be
> altered as it became clearer exactly what data various frontends
> needed and how it was most convenient to relay this data.  The plan
> got put on hold a while because the 3rd party frontends didn't
> materialize, but we could resume where we left off.

Many thanks for offering all this support!  This is a real motivator to get the
project going! I believe that for my purposes, seconds since epoch are perfect.
Problems would only occurr if one intermixed OSs that have different epochs.
To be general, you could ad some string identifying the OS that produced the
time.  S.th. like U 1234 for a unix time or W 1234 for one based on windows
epoch.  But as I mentioned, I don't have a need for this.  I may have other
needs but don't know them yet ;-)







reply via email to

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