On Mon, 2008-08-11 at 02:09 -0400, Karl Fogel wrote:
> Matt Slot <fprefect_at_ambrosiasw.com> writes:
> > The data is in a standardized and supported format, so it should be
> > forward compatible. It's also "optional", in that platforms which
> > don't recognize Mac resource forks won't be affected, nor will older
> > subversion releases.
>
> The sole and only issue here, as far as I can see, is the additional
> complexity this would put in the Subversion core code. We'll have to
> maintain it, and naturally are a little reluctant. It's not that the
> patch is bad, nor the feature undesirable. It's just a question of
> overall cost/benefit (yes, I understand that the benefit for Mac
> developers is huge, but that's still a subset of all users).
(Matt, apologies for diverting into a meta-discussion.)
I ask you all:
Do we intend Subversion to be...
(a) ... a system for versioning a set of files (and directories) which
exist in your operating system's file system, able to store such a file
and later retrieve it back into your filesystem almost exactly as it was
there before;
or
(b) ... a system for versioning a set of files (and directories) which
are arbitrary blobs of (text or binary) data with named properties
attached, and to present these files into your OS filesystem for you to
edit and use, and also to present them through a web browser interface
and through other interfaces?
I think the answer is that the original remit was firmly just (b), but
several people want Subversion to be (a) as well as (b). We, the
community of developers, have not clearly answered this question.
This AppleDouble storage feature falls into the same category as the
feature for storing and restoring mod-time and permissions, which has
also been "done" for a long time but not included in the main-line
Subversion source code, and which some people also say is necessary for
them to be able to use Subversion.
We need to recognise that if we try to be (a), we will never get there
because the combinations of file naming rules, and meta-data, and
special node types (sym-links, hard links, device files) across systems,
and the portability behaviours that would enable Subversion to cope with
them all in a sane way, are (both theoretically and practically)
impossible to complete.
A system that achieves (a) is likely to be a dedicated filesystem
archiver for a particular platform. It is of course possible to build
such a system _on top of_ Subversion, because we can store any arbitrary
data, but building such a system _into_ Subversion as an integrated part
of the feature set is something we could only hope to get part way with.
All of this does not necessarily mean that we should or should not do
this "AppleDouble" thing or the "mtimes and permissions and special
nodes" thing. It just means we should have our eyes open, looking in the
direction we are going.
Note that the "mtimes and permissions and special nodes" thing is
currently available as a wrapper on top of Subversion called
"asvn" ("Archive SVN")
<http://svn.collab.net/repos/svn/trunk/contrib/client-side/asvn>.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-11 12:30:18 CEST