acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

You are suggesting Forward revisioning, which I again think is a good
choice. I was supporting reverse revisioning with the assumption that we
could do encrypted diffs and apply it to get the latest version.

On Mon, Jul 5, 2010 at 2:39 PM, krishnan parthasarathi <
krishnan.parthasarathi@xxxxxxxxx> wrote:

> After some deliberation on the design details we had come up so far, Aditya
> and
> me have thought of some modifications.
>
> When we use reverse diffs to maintain older revisions of a file, the client
> needs to upload the latest revision of the file along with latest reverse
> diff
> to the server, during updates. In a forward diff approach we would need to
> send
> only the latest diff. On the flipside when we setup the client for the
> first
> time on a machine, we need to download the first revision and all the
> diffs.
> This is not too bad since we need to do this only once for every new
> client. So
> our server app will store the first version of the file and all the diffs
> upto
> the latest revision.  To reduce the amount of download a new client
> initialisation requires, the server could compute the total download size
> (of
> first revision of file and all diffs) and on reaching a threshold value can
> ask
> client to send the 'current' version of the entire file in place of a
> diff.  By
> this approach, a new client only needs to download diffs upto the last
> 'fully'
> present revision to recreate the latest revision of the file.
>
This is exactly what Mercurial does as part of Snapshotting. The only
challenge for me is in trying to understand how Mercurial/SVN performs diff
- what does it perform the diff against? SVN seems to create a copy of the
repository-version for a file *only* when it is being edited. This allows it
to simply diff the file. However, I am not aware of when this is done - are
there some filesystem hooks that it leverages?

>
> The line preserving diffs between encrypted revisions on the server side is
> expensive on storage. Instead now the diffs will be between the unencrypted
> revisions of the file and taken at the client side. On update, client
> encrypts
> the diff and sends it to the server.
>
> In the event that a user loses his copy of the RSA key pair which he shares
> with the server for encrypting his master key file, he must be able to
> retrieve
> it from the server using his password. For this we must devise a challenge
> based authentication scheme like the one described in SpiderOak's articles.
>
>
> Cheers,
> Krishnan
>
> _______________________________________________
> Mailing list: https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> Post to     : acmeattic-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Karthik