[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn:mime-type and */*+xml

From: Travis P <svn_at_castle.fastmail.fm>
Date: 2004-05-17 19:42:25 CEST

On May 17, 2004, at 11:51 AM, Vincent Lefevre wrote:

> I don't think that PS files can contain binary data (contrary to PDF).
> Binary is in fact encoded in hexadecimal (0-9,a-f).

I've some evidence that that isn't the case.

http://www.rfc-editor.org/rfc/rfc2046.txt
Page 17:
" (7) It is possible to include raw binary information inside
           PostScript in various forms."

First this message:
    http://www.imc.org/ietf-822/old-archive2/msg00424.html

Then, I did this:
   acroread -toPostScript -level3 -binary < ImageMagick.pdf >
ImageMagick.ps
======== begin snip from ImageMagick.ps =======
/Width 573
/Height 437
/Filter /DCTDecode
/BitsPerComponent 8
/Decode [0 1 0 1 0 1]
/ColorSpace DefaultRGB
ID
????^@^NAdobe <binary data>

EI

Q
BT
======== end snip from ImageMagick.ps =======

Definitely non-ASCII data there.

> On 2004-05-17 11:44:29 -0500, Travis P wrote:
>
>> Even if it is completely text, do you really want PS files merged and
>> then resolve the conflicts yourself?
>
> Why not? Probably not with PS-generated files (anyway, marking files
> as binary doesn't solve conflicts magically),

I never even implied that it did. But if a merge occurs on an
unmerge-able file, recovering the original modified file could be very
difficult (maybe even impossible in some cases?). The user might want
an uncorrupted copy of the modified file to view his changes so as to
hand-incorporate them into the version that was checked in and which
conflicts which his own.

> but with hand-written
> PS files, yes, like with any other programming language.

You're right about hand-written text PS files. I think that
hand-written is probably quite the rare exception compared to generated
files. Too bad there isn't a recognized text/postscript mime-type for
the case you wish to deal with.

A related issue is: is this override-able? I suppose anything could
be set to application/octet-stream to force no merges.
If application/postscript change were made merge-able, I'd have to go
through my repos and change all my PS files which are currently marked
application/postscript to application/octet-stream because they are all
automatically generated files.

 From that same RFC (http://www.rfc-editor.org/rfc/rfc2046.txt):

Page 4-5:
3. Overview Of The Initial Top-Level Media Types

    The five discrete top-level media types are:
  .....
    (5) application -- some other kind of data, typically
           either uninterpreted binary data or information to be
           processed by an application. The subtype "octet-
           stream" is to be used in the case of uninterpreted
           binary data, in which case the simplest recommended
           action is to offer to write the information into a file
           for the user. The "PostScript" subtype is also defined
           for the transport of PostScript material. Other
           expected uses for "application" include spreadsheets,
           data for mail-based scheduling systems, and languages
           for "active" (computational) messaging, and word
           processing formats that are not directly readable.
           Note that security considerations may exist for some
           types of application data, most notably
           "application/PostScript" and any form of active
           messaging. These issues are discussed later in this
           document.

I would think that anything application/* (including application/xml)
should not be treated as mergeable text.

-Travis

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 17 19:43:59 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.