Jack Repenning <jrepenning@collab.net> writes:
> At 9:01 AM -0600 11/4/03, C. Michael Pilato wrote:
> >I say all this to promote the idea that it isn't too much to ask of a
> >repos administrator to run some out-of-process deltification routine
> >-- even per-commit -- because if they are truly concerned about disk
> >space, they'll already have some out-of-process log-file cleanup
> >process. And if you have a cronjob/post-commit hook to cleanup
> >logfiles, what's an extra line in that script to deltify?
>
> I must not understand this proposal. Expressing my ignorance and
> confusion: how can the repo admin be made responsible for
> deltification, when deltas are needed for the next update of the new
> node-revision? If I, as an admin, choose to defer all deltification
> to the wee small hours, does that mean no one can see the new
> node-revision until tomorrow? Surely not! So what *is* the idea
> here?
Hm... you don't really know how deltification works, do you? :-)
You're forgiven.
All data written to the filesystem by external processes is stored
full-text in the database. After each commit is recorded, and as a
kindness to people's hard drives (in theory, anyway), the filesystem
code enumerates the set of node-revisions changed in that commit, and
replaces the full-text contents of one or more previous versions of
each of those node-revision with deltas against the new version of
that file. At all times, both the new and previous versions are
accessible, and their contents are exposed via the FS API in a manner
that hides whether or not those contents are stored as fulltext or as
deltas against some other version.
In other words, if right now you skip the call to deltify_mutable() in
svn_fs_commit_txn(), you're repository will behave (from a user POV)
exactly as it does today -- except it will run quite a bit faster,
create fewer log files, and bloat in the 'strings' table.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 4 18:53:30 2003