On May 11, 2009, at 8:27 PM, silky wrote:
The local version needs access to the last committed file (to compare
the changes) and the server version only keeps the 'base' file and the
'changes' subsets.
a)  What's a "committed" file.
b) As in my response to Victor's message, note that you can't keep a base plus changes forever - eventually you need to resend the base. And you'd like to do that efficiently.

So yes, it does increase the amount of space required locally (not a
lot though, unless you are changing often and not committing),
Some files change often. There are files that go back and forth between two states. (Consider a directory file that contains a lock file for a program that runs frequently.) The deltas may be huge, but they all collapse!

will also increase the amount of space required on the server by 50%,
but you need pay the cost somewhere, and I think disk space is surely
the cheapest cost to pay.
A large percentage increase - and why 50%? - scales up with the amount of storage. There are, and will for quite some time continue to be, applications that are limited by the amount of disk one can afford to throw at them. Such an approach drops the maximum size of file the application can deal with by 50%.

I'm not sure what cost you think needs to be paid here. Ignoring encryption, an rsync-style algorithm uses little local memory (I think the standard program uses more than it has to because it always works on whole files; it could subdivide them) and transfers close to the minimum you could possibly transfer.

If you want the delta computation to be done locally, you need two local copies of the file - doubling your disk requirements. In principle, you could do this only at file close time, so that you'd only need such a copy for files that are currently being written or backed up. What happens if the system crashes after it's updated but before you can back it up? Do you
need full data logging?

I think this is resolved by saving only the last committed.
If a file isn't committed when closed, then you're talking about any commonly-used system.
                                                        -- Jerry

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to