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
<mailto: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?
