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
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..
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
>>The drawback is that if your editor doesn't break the link and
>>therefore also writes to text-base then things will get very
>>Some wise person wrote "more computing sins have been committed in the
>>name of efficiency (without necessarily achieving it) than for any
>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: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Dec 19 18:15:22 2002