And, yet another scheme to save storage would be to store the delta rather
than the whole pristine file. Initially, the delta would be an empty file!
This would not have redundancy, but one does have the repository to fall
back on. The client side is not a backup, it is a working copy.
This has probably been considered in the initial design stages of subversion.
Mark Bainter wrote on Wed, 18 Dec 2002 21:34:20 -0600:
>Bob Gustafson [bobgus@rcnChicago.com] wrote:
>> Hmm, the file that the client user wants to edit is already on the client -
>> in the workspace.
>>
>> If the client user edits a pristine file, we need a mechanism that will
>> copy the pristine file to the .svn space *before* the edited file is
>> written back to the workspace.
>>
>> I don't know how to implement that magic. Need some brainstorming.
>>
>> Maybe work in a modified shell space that senses when a write will happen?
>> Or maybe make the pristine file read-only and then have the editor (vim?)
>> say "This file is read-only, do you want to stash a pristine copy in
>> .svn?", or something like that.
>>
>
>While I can appreciate that that would certainly be a great way to
>implement it, and would then still not require network connectivity
>or bandwidth usage I think it'd be difficult to implement in a portable
>fashion, let alone implement it reliably.
>
And Martin Pool wrote on Thu, 19 Dec 2002 15:06:45 +1100
>Some kernel developers I know make heavy use of trees of hardlinks.
>If you make sure your editor creates a new file on save then this
>essentially gives you a large number of copy-on-write trees. Not only
>are they cheap in disk space, but it also saves buffer memory and
>makes a smart diff run quickly.
>
>I wonder how well Subversion would cope with the text-base being
>initially a hardlink to the working copy? Or with two wcs that are
>mostly hardlinks?
>
>The drawback is that if your editor doesn't break the link and
>therefore also writes to text-base then things will get very
>confusing.
>
>Some wise person wrote "more computing sins have been committed in the
>name of efficiency (without necessarily achieving it) than for any
>reason."
Yes, this last comment is probably the most meaningful. We are flailing
away to gain a few (mega?) bytes of storage. But, at this stage, the
thinking is cheap. Implementing a scheme is something else.. Portability
is also a big issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 19 16:46:39 2002