Josh Pieper <jjp@pobox.com> writes:
> After considering the feedback, I think a workable solution would be
> to introduce just one new type, svn_node_special, and have it be
> stored in the repository that way as well doing away with the
> svn:special property. The server could translate this to a
> svn_node_file for 1.0 clients. Then, the only system specific logic
> would not be exported directly in any API, since it would consist of
> just the stuff necessary to create and read the special files.
Well, why not just introduce 'svn_node_symlink', since that's the
goal?
For example, we don't have an 'svn_node_normal' kind. Instead we have
'svn_node_file' and 'svn_node_directory'. Although both are "normal",
that's a category, not an equivalence class. Likewise, the only thing
"special" node kinds have in common is that they are special. But
knowing that something is special is not enough information to tell us
what to actually *do* with such an beast; for that, we need to know
its actual kind.
In other words, there's no point diving node kinds into special and
non-special. Let's just, you know, have a node kind for each node
kind :-). Right now we have two, the most common node kinds in the
world: files and directories. Tomorrow, maybe we'll have three:
files, directories, and symlinks.
Of course, every engineer always claims that they're arguing for
simplicity, directness, and elegance. So when I claim that I'm
arguing here for simplicity, directness, and elegance, please
understand that it's only because I'm on the side of goodness, truth,
and beauty.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 30 20:43:03 2004