OK, how is this for a scheme to save on text-base storage:
When the project is first checked out from the repository, all of the files
are set as read-only.
Suppose now that you want to edit a file. Using your favorite editor, you
make a few changes and then go to save it. Since it is a read-only file,
the editor complains.
You execute a shell command then - an svn_init command (to be written)
which is pretty simple, it copies the read-only file from the working space
to the .svn text-base area and then changes the read-only to a read-write.
After this command executes, you go back to the editor and redo the save.
The situation is then exactly the same as it is now with regard to that
single file.
======
I haven't figured out how to save only the delta in the .svn area though...
Maybe the svn_init command in the paragraph above could reconstruct the
previous file from the read-only file, do the diff with the editor buffered
file, and add the delta to ... Nah, too much interaction..
BobG
Bob Gustafson wrote awhile ago:
>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 18:15:22 2002