Josh Pieper <jjp@pobox.com> writes:
> 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?
So the main thing is: *every* platform supports at least files and
directories. For any other types, all bets are off, hence those types
are "special".
Is that the gist of it?
Oh, plus what Brane said in his reply:
> Because that's not really the goal. The goal is to have a type of
> file node whose contents get interpreted as a sort of file-creation
> command. So if the file contents are, e.g., "symlink ../..", you'd
> get that in the text base, but an actual symbolic link in the
> working copy itself. You only need one new node kind for all of
> those.
Okay. I can buy that.
> 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.
I think what's going on here is I'm slowly making my peace with the
fact that if we're going to get this feature compatibly, it will be
via a horrible hack :-).
So, this is a horrible hack too, but maybe it's right way to go. At
least it's small.
> 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.
Sounds sane.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 30 23:18:14 2004