acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

On Tue, Jul 6, 2010 at 11:00 PM, Aditya Manthramurthy
<aditya.mmy@xxxxxxxxx>wrote:

>  On Tuesday 06 July 2010 04:02 AM, Karthik Swaminathan Nagaraj wrote:
>
> 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?
>
> No, I think SVN keeps a copy in an internal format inside its .svn folder.
> In our case, we just need to differentiate between binary and text files.
> For text files, we use line based diffing (same as the shell diff utility)
> **, and for binary files, the simplest approach to forming diffs is using
> the rsync approach: http://samba.anu.edu.au/rsync/tech_report/
>
I think we misunderstood each other here. After a file is modified, we need
an unmodified version to perform the diff against the current version. I
mentioned that SVN keeps a copy of the unmodified version as
.svn/text-base/filename.svn-base. So the diff becomes
*diff .svn/text-base/filename.svn-base filename*

Svn stores this unmodified version in the same folder as the original.
However, it is unclear to me when svn makes this copy. It does not copy all
the files (mod and unmod) as that's a waste of space. So, how is svn
notified of a file write? Is it filesystem hooks which as called when a file
is edited?

I hope I've made my point clearer now.


>
> --
> Aditya
>
> _______________________________________________
> 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