kfogel@collab.net wrote:
> 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.
The reason for having a separate node class would be that not every
platform can support all of the non-file and non-directory types.
Also, there are lots of different platform dependent file types. Do
we want to go through the work of adding a new repository type for
each and every one?
I hacked around a bit seeing what it would take to add _any_ new type
of node into the client/repository. In short, it is a lot of code
churn. There are many cases where it is assumed that a node is either
a file or directory, and many other places where we would need to add
things like 'if (kind == svn_node_file || kind == svn_node_symlink ||
...)' since all the special files are most often treated identically
to normal files. In addition, we would need new interfaces for things
like the update editor and possibly the reporter.
I have a new proposal that avoids some of these problems. It is
certainly very simple to implement and may be slightly easier to
accept than my first one.
1. Change nothing in the repository/server.
2. Use just the svn:special property to indicate that a file is
platform dependent. (do not have a new WC entry type)
3. Teach svn_subst_copy_and_translate to translate the new files.
4. Have a new svn_io_check_special_path return svn_node_special for
any platform dependent file, and use svn_io_stat to figure out what
type it actually is. svn_io_check_path will just return
svn_node_file for anything that isn't a directory.
My original idea that a new type of entry would be needed in the WC
was unwarranted. (Testing for the svn:special property is sufficient
in all cases.)
This approach is very simple, does not require any APIs to be modified
in order to support additional platform dependent types, and
the only platform dependent APIs it introduces are those necessary to
create and read the special files. The patch is actually pretty
small, with most of the changes just in changing all callers of
svn_subst_copy_and_translate.
About Brane's suggestion to fix the interface to
svn_subst_copy_and_translate at the same time: While I agree the
interface is ugly, fixing it is a parallel effort that can be done at
any time, regardless of this work on handling special files. I may
even clean it up myself, but would rather not intermingle that work
with this and thus will look at it later.
-Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 30 21:05:52 2004