svn:mime-type and detecting mergeability

[Eric Gillespie <ep...@pretzelnet.org>]

I personally have no interest in doing this, but it occurs to me
that people might want to serve a web site directly out of a
Subversion repository.  That's fine, just set the svn:mime-type
on all the files.  But, what if your target audience is an
internal network running Mozilla exclusively and you use features
of XHTML not backwards-compliant with HTML?  This means you must
use the unfortunately named application/xhtml+xml media type.
And that means Subversion (rightfully so, IMHO) thinks the file
is not text.

The obvious work-around is simply not to do it that way.  Stop
being lazy and write Makefiles to publish from a wc to your web
site.  A co-worker proposed a better idea, though.  Make the list
of media types which are to be considered text configurable.

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.

-- 
Eric Gillespie, Jr. <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[Eric Gillespie <ep...@pretzelnet.org>]

Ben Collins-Sussman <su...@collab.net> writes:

> 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.

The admin controls the repository.  She does not control your
client.  It has nothing to do with whether or not the
configuration item affects purely client-side code.

--  
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: repos-side config bits (was: svn:mime-type and detecting mergeability)

[Brian Huddleston <br...@huddleston.net>]

Greg Stein:.
>
> And a replacement for CVS's rcstemplate (the default text for commits that
> pop up $EDITOR).
>

I would second this (hopefully pre-1.0?).   Our whole build system/issue
tracking/CVS integration runs off a commit template.  So we would be
boogered (technical term) without it.

-Brian



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: repos-side config bits (was: svn:mime-type and detecting mergeability)

[Karl Fogel <kf...@newton.ch.collab.net>]

Greg Stein <gs...@lyra.org> writes:
> Adding features, Karl? Alpha means they go into the post-1.0 bucket and need
> to "work hard" to get out of the bucket. IMO, this feature doesn't really
> seem to hit the bar for a post-alpha feature addition.

See below...

> [ of course, if a patch comes along and it is obviously low-impact... ]

That's what I meant :-).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

repos-side config bits (was: svn:mime-type and detecting mergeability)

[Greg Stein <gs...@lyra.org>]

On Thu, Aug 22, 2002 at 12:23:26PM -0500, cmpilato@collab.net wrote:
>...
> > Karl Fogel <kf...@newton.ch.collab.net> writes:
> > > Eric Gillespie <ep...@pretzelnet.org> writes:
> > > > He thinks this should be a repository option (which places it
>...
> > > That sounds good to me.  And we can implement the client side now,
> > > leaving the repository side for post-1.0.

Adding features, Karl? Alpha means they go into the post-1.0 bucket and need
to "work hard" to get out of the bucket. IMO, this feature doesn't really
seem to hit the bar for a post-alpha feature addition.

[ of course, if a patch comes along and it is obviously low-impact... ]

>...
> 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.

And a replacement for CVS's rcstemplate (the default text for commits that
pop up $EDITOR).

> 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.

Right.

It would be nice to file these as post-1.0, tho...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[cm...@collab.net]

kevin@pilch-bisson.net writes:

> While I agree that it might be nice to have subversion repository
> properties for doing things like this, I'm not sure how necessary it
> is.
> 
> Here's another suggestion: Users can store default
> ~/.subversion/config file in their repository, check them out, and
> copy the files to their own home dirs.
> 
> I.e. have a repos layout like this (for perhaps a corporate network):
> 
> /
>  trunk/
>  branches/
>  tags/
>  config/
>         proxies
>         options
>         ....
> 
> Then, when a new employee starts they
> ~ $ svn co http://svn.mycompany.com/repos/config/ ~/.subversion
> 
> And all is happy!

...until one of those configuration options one day conflicts with the
options needed by a different project's working copies.  I have no
concrete examples, but I would like to see configuration options have
this precedence heirarchy:

  - working copy (as dictated by settings on the repos)
  - ~/.subversion (user default)
  - /etc/subversion (system-wide default)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[cm...@collab.net]

Ben Collins-Sussman <su...@collab.net> writes:

> Karl Fogel <kf...@newton.ch.collab.net> writes:
> 
> > Eric Gillespie <ep...@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

Re: svn:mime-type and detecting mergeability

[Ben Collins-Sussman <su...@collab.net>]

Karl Fogel <kf...@newton.ch.collab.net> writes:

> > 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 think the idea is that the repository might be able to keep a
> central database (as a text file, whatever) mapping mime-types to a
> boolean indicating binary or text.  Thus, clients wouldn't have to
> contain all this knowledge themselves, they could get it from the
> repos.
> 
> Not sure if this is good or bad, just trying to clarify Eric's
> proposal.

Ah, thanks.  I misunderstood.

I think this is Yet Another Example of a long-wanted feature -- some
kind of server-side config options.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[Karl Fogel <kf...@newton.ch.collab.net>]

Ben Collins-Sussman <su...@collab.net> writes:
> 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 think the idea is that the repository might be able to keep a
central database (as a text file, whatever) mapping mime-types to a
boolean indicating binary or text.  Thus, clients wouldn't have to
contain all this knowledge themselves, they could get it from the
repos.

Not sure if this is good or bad, just trying to clarify Eric's
proposal.

-K


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[Ben Collins-Sussman <su...@collab.net>]

Karl Fogel <kf...@newton.ch.collab.net> writes:

> Eric Gillespie <ep...@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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[Karl Fogel <kf...@newton.ch.collab.net>]

Branko Čibej <br...@xbc.nu> writes:
> And design doc. I suggest our policy should be: Every feature request
> must be accompanied by a detailed design doc, or it goes to /dev/null
> immediately.

Nah, not necessary imho.  Many feature requests have been so simple
and non-controversial that they've been easy to implement without any
bureacracy.

I suggest that we ask for more details when we feel we need them, and
don't ask when we don't :-).  That's a nice, simple recipe, that
avoids needless overspec'ing.

(If you're suggesting that Eric's feature in particular leaves
unanswered questions, that's different.  Probe a bit to show the
weaknesses, and ask the questions, then.)

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[Eric Gillespie <ep...@pretzelnet.org>]

<br...@xbc.nu> writes:

> And design doc. I suggest our policy should be: Every feature request 
> must be accompanied by a detailed design doc, or it goes to /dev/null 
> immediately.

This is asinine.  Were i planning to submit a patch, or had i
submitted a patch, you would have a point.  But users will always
have feature requests.  Many of them will be legitimate, many
will not.  None will be accompanied by design documents.  This is
as it should be.

Lusers do not write design documents.  When it comes to
Subversion, i am nothing more than a luser.

--  
Eric Gillespie <*> epg@pretzelnet.org

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[Branko Čibej <br...@xbc.nu>]

Karl Fogel wrote:

>Eric Gillespie <ep...@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?
>
And design doc. I suggest our policy should be: Every feature request 
must be accompanied by a detailed design doc, or it goes to /dev/null 
immediately.


-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn:mime-type and detecting mergeability

[Karl Fogel <kf...@newton.ch.collab.net>]

Eric Gillespie <ep...@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?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org