On Mon, 2008-08-11 at 15:46 +0200, Stefan Sperling wrote:
> On Mon, Aug 11, 2008 at 11:29:53AM +0100, Julian Foad wrote:
> > 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.
>
> Yes. By natively supporting symlinks and svn:executable, we already
> cater to the UNIX platform more than we should if we wanted to be
> just (b).
>
> > 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.
>
> That is true. But still, by that argument we should all be using
> wrapped clients on UNIX to version symlinks and exectutable bits.
> It would be nice if we could, in the long term, support more
> OS-specific features out of the box.
>
> I wonder if the patch is the way to go.
> I mean, where do we draw the line?
> If we have svn:executable, why not have svn:appledouble?
Good question. My personal feeling is that we SHOULD be willing to have
some features like this that support OS filesystem features, and also
that each addition of such a feature should improve the modularity of
the implementation for such features. I expect the existing support for
svn:executable and symlinks is rather tightly tied in to low-level code,
and we should endeavour to uncouple it a bit and make sure that any new
code like this AppleDouble feature is not too tightly mixed in with
everything else, as far as we can. If we decide that the best
(maintainable) way to do this is to have a wrapper layer around
Subversion, then
* we should help to create and support this layer;
* we should move the svn:executable and symlink support into it.
This wrapper layer might be a C-language layer above libsvn_wc, rather
than outside the "svn" client, so it available to all clients.
As for this particular AppleDouble feature: I don't imagine the feature
complexity (likelihood of complex bugs, interactions with other
features, ...) being much greater than for, say, symlink support. So
let's have a look at it.
- Julian
> This problem must be really old. I can't imagine that this argument
> hasn't come up before. Wasn't some consensus about the validity of
> such special properties reached somewhere in the past already?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
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 16:29:20 CEST