Subversion treats the following files as text:
Files with no svn:mime-type
Files with a svn:mime-type starting "text/"
Files with a svn:mime-type equal to "image/x-xbitmap"
Files with a svn:mime-type equal to "image/x-xpixmap"
All other files are treated as binary, meaning that Subversion will:
Not attempt to automatically merge received changes with local changes
during svn update or svn merge
Not show the differences as part of svn diff
Not show line-by-line attribution for svn blame
a little OT, but nevermind
Sorry. Renamed to start a separate thread.
two basic thing
application/ecmascript;version=5 is not necesary a mimetype
the full tag is <meta http-equiv="Content-Script-Type"
content="application/ecmascript;version=4">
and I think this would be interpreted as plain text mimetype
Ok. So it's a content-type which is not a mime-type even though it looks
like one?
Is there a separate recommendation that defines a mime-type for ecmascript?
Many SVN HTML gateways use the svn:mime-type property as the content of the
Content-type response header.
Is there some other svn property that determines that?
even if all that was causing svn to see those files as binary
you can still force the mimetype by editing autoprops in your subversion
config
Cool, so what guidance would we give to administrators of large hosted SVN
repos such as Apache and code.google? SVN should not have to include an
incorrect mime-type, and the mime-type definition should not encourage
charset guessing attacks, but you really don't want to disallow merging of
javascript.
If I do
svn add foo.es3
svn propset svn:mime-type "application/ecmascript;version=3;charset=UTF-8'
foo.es3
does it end up as a text file? If served by an svn HTML gateway, will it be
served with charset=UTF-8 or will it be served as text/plain and/or with an
unknown charset?
2008/5/14 zwetan <zwetan at gmail.com>:
> Hi Mike,
>
> 2008/5/13 Mike Samuel <mikesamuel at gmail.com>:
> >
> >
> > 2008/5/13 <es4-discuss-request at mozilla.org>:
> >
> > >
> > > what about
> > > http://wiki.ecmascript.org/doku.php?id=proposals:versioning
> > > and
> > > http://wiki.ecmascript.org/doku.php?id=discussion:versioning
> > >
> [snip]
> >
> > On developer tools and mime-types, subversion will treat
> > application/ecmascript as binary.
> >
> > http://subversion.tigris.org/faq.html#binary-files
> >
> >
> > Subversion treats the following files as text:
> > Files with no svn:mime-type
> > Files with a svn:mime-type starting "text/"
> > Files with a svn:mime-type equal to "image/x-xbitmap"
> > Files with a svn:mime-type equal to "image/x-xpixmap"
> >
> > All other files are treated as binary, meaning that Subversion will:
> > Not attempt to automatically merge received changes with local changes
> > during svn update or svn merge
> > Not show the differences as part of svn diff
> > Not show line-by-line attribution for svn blame
> >
>
>
> a little OT, but nevermind
>
Sorry. Renamed to start a separate thread.
two basic thing
>
> 1) application/ecmascript;version=5 is not necesary a mimetype
> the full tag is <meta http-equiv="Content-Script-Type"
> content="application/ecmascript;version=4">
> and I think this would be interpreted as plain text mimetype
>
Ok. So it's a content-type which is not a mime-type even though it looks
like one?
Is there a separate recommendation that defines a mime-type for ecmascript?
Many SVN HTML gateways use the svn:mime-type property as the content of the
Content-type response header.
Is there some other svn property that determines that?
> 2) even if all that was causing svn to see those files as binary
> you can still force the mimetype by editing autoprops in your subversion
> config
>
> for ex:
> [auto-props]
> *.es = svn:eol-style=native; svn:mime-type=text/plain
> *.es3 = svn:eol-style=native; svn:mime-type=text/plain
> *.es4 = svn:eol-style=native; svn:mime-type=text/plain
>
Cool, so what guidance would we give to administrators of large hosted SVN
repos such as Apache and code.google? SVN should not have to include an
incorrect mime-type, and the mime-type definition should not encourage
charset guessing attacks, but you really don't want to disallow merging of
javascript.
If I do
svn add foo.es3
svn propset svn:mime-type "application/ecmascript;version=3;charset=UTF-8'
foo.es3
does it end up as a text file? If served by an svn HTML gateway, will it be
served with charset=UTF-8 or will it be served as text/plain and/or with an
unknown charset?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080514/f105fe99/attachment-0002.html
Ok. So it's a content-type which is not a mime-type even though it looks
like one?
Is there a separate recommendation that defines a mime-type for ecmascript?
2008/5/14 Mike Samuel <mikesamuel at gmail.com>:
> Ok. So it's a content-type which is not a mime-type even though it looks
> like one?
> Is there a separate recommendation that defines a mime-type for ecmascript?
<uri:http://www.ietf.org/rfc/rfc4329.txt>
--
David "liorean" Andersson
2008/5/14 zwetan <zwetan at gmail.com>:
Sorry. Renamed to start a separate thread.
two basic thing
Ok. So it's a content-type which is not a mime-type even though it looks like one? Is there a separate recommendation that defines a mime-type for ecmascript?
Many SVN HTML gateways use the svn:mime-type property as the content of the Content-type response header. Is there some other svn property that determines that?
Cool, so what guidance would we give to administrators of large hosted SVN repos such as Apache and code.google? SVN should not have to include an incorrect mime-type, and the mime-type definition should not encourage charset guessing attacks, but you really don't want to disallow merging of javascript.
If I do svn add foo.es3 svn propset svn:mime-type "application/ecmascript;version=3;charset=UTF-8' foo.es3 does it end up as a text file? If served by an svn HTML gateway, will it be served with charset=UTF-8 or will it be served as text/plain and/or with an unknown charset?