Martin Pool wrote:
>I'll just throw this out because nobody has mentioned it yet:
>
>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?
>
This idea has been thrown in the pool before, but it won't work, even
ignoring the fact that hard links are a Unix thing. The text base is
_not_ the same as the working file. The working file is text base +
end-of-line conversions + keyword expansions.
>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.
>
As far as I'm concerned, the fact that Subversion doesn't control the
editor is sufficient reason to drop this idea.
>Some wise person wrote "more computing sins have been committed in the
>name of efficiency (without necessarily achieving it) than for any
>reason."
>
>If your trees are this big it might be time to split them into
>modules. (I suppose if they're that big and that old then it's
>infeasible though.)
>
I can't imagine a person actively editing the whole LK tree, for
example. She'll have to have the whole source available, but only small
subtree actually has to be a Subversion working copy. The rest can be
just a (read-only) copy of the sources.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 20 02:43:44 2002