Ben Collins-Sussman <sussman@collab.net> writes:
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
>
> > Eric Gillespie <epg@pretzelnet.org> writes:
> > > He thinks this should be a repository option (which places it
> > > post-1.0, waiting on the mechanism for the repository to send the
> > > client configuration info), but i'm not so sure. After all,
> > > merging is a client-side operation. Nevertheless, the web
> > > editors should not have to jump through hoops to get configured.
> > > Maybe the best way would be to have both repo and client options,
> > > with the latter overriding the former.
> >
> > That sounds good to me. And we can implement the client side now,
> > leaving the repository side for post-1.0.
> >
> > Anyone see a problem? If not, Eric, can you file the feature request?
>
> libsvn_wc is the *only* thing that pays attention to the concept of
> text-ness and binari-ness. So I don't understand why the solution
> should have anything to do with repository bits.
>
> A file has some svn:mime-type property; well and good, that value
> gets sent out to web browers in a Content-type: header. Maybe that
> value is xml/foo or whatever.
>
> Now libsvn_wc sees the property, and assumes that any non-NULL value
> that doesn't start with text/* means binariness -- no more contextual
> merging, when this file is really still a text file.
>
> So why not fix this purely on the client side? In a site-wide or
> personal ~/.subversion config area, set a list of mime-type patterns
> that are assumed to be text.
I dunno, Ben. I think it would be cool if Subversion's repository
could propogate default config options to working copies associated
with that repository. Think repos-wide svn:ignores,
svn:textual-mimetype, etc. Without such, every user, on every machine
on which they use Subversion, has just that many more magic steps they
have to take before their working copies are properly set up. What's
more, those configuration may not be desirable for all working copies
they have -- these are per-repository types of options.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 19:23:36 2002