Results 1 to 16 of 16

Thread: Setting of mime types for service files in public repository.

  1. #1

    Setting of mime types for service files in public repository.

    Hello Forum

    Our client has been using UberSvn since November 2011 and has requested that a few xml files be hosted on a public reposition on their server, the files have a requirement that they need to have specific mime type mime = text/xml so that they work properly.

    No matter what changes we make the system will only server the files up a text/plain.

    Changes made:

    We have made the following changes so far but have had no success with the outcome with these variations to the config files.

    Edit:

    # opt/ubersvn/httpd.conf

    Have tried the following variations to the file:

    # DefaultType text/plain
    # DefaultType text/xml
    DefaultType application/octet-stream

    Have turned off

    # TypesConfig conf/mime.types

    So that it defaults to the DefaultType listed above.

    Have edited

    opt/ubersvn/conf/mime.types

    To include

    Text/xml xml xslt xls

    None of these changes have worked as the files are still being served up as text/plain when they should be served as text/xml

    The repository being used is public so anyone can have access to the files, repository URL below.

    https://svn2.subversion.net.au/public/

    Any help would be greatly appreciated.
    Thank you.

  2. #2
    You have done everything but the simplest, most correct thing.

    Code:
    svn propset svn:mime-type text/xml <filename>
    I am neither an employee nor customer of WANDisco.

  3. #3
    Hi Andy

    Thanks for the reply i forgot to mention that i also tried that as well
    Since this is an UberSVN install of SVN the standard svn commands fail to work and come back with

    # -bash: svn: command not found

    so im not 100% sure if there is a direct path to the command for the above due to the proprietary install of UberSvn.

    Any ideas would be greatly appreciated.

    ""Cheers

  4. #4
    Senior Member Site ModeratorSite Admin
    Join Date
    Mar 2011
    Location
    Chesterfield, UK
    Posts
    771
    With uberSVN, the client tools are found in /opt/ubersvn/bin by default. So you can try invoking them with their full path (for example: /opt/ubersvn/bin/svn propset blah) or adding the path to your environment (for example: export PATH=/opt/ubersvn/bin:$PATH)
    Mat Booth
    Software Engineer
    WANdisco, Inc.

    I joined the blog-o-web-o-sphere! Linux and Coding Blog

    How To Ask Smart Questions

  5. #5
    You don't set file properties on the server, you have to do it within a working copy, and commit the changes.
    I am neither an employee nor customer of WANDisco.

  6. #6
    Hi andyl

    Not sure what you mean the UberSvn setup was done exactly as directed in their instructions its a self automated script that pretty much dose all the work and leaves you with a completed install from go > wo.

    Apart from some minor changes via the GUI its an easy setup.

    Back to the actual problem at hand

    After setting the path and even using the direct path we still get the following error:

    /opt/ubersvn/bin/svn propset svn:mime-type text/xml CONF-ATO-AS_001.01_List_Request.xml
    svn: '.' is not a working copy

    Any ideas please mbooth or andyl?

    Thank you kindly.

  7. #7
    Quote Originally Posted by velocity08 View Post
    After setting the path and even using the direct path we still get the following error:

    /opt/ubersvn/bin/svn propset svn:mime-type text/xml CONF-ATO-AS_001.01_List_Request.xml
    svn: '.' is not a working copy
    The directory you're working in isn't a working copy. Did you check out from your repository to that directory? Have you tried it from one of your other workstations, where you're (presumably) already working with those files?
    I am neither an employee nor customer of WANDisco.

  8. #8
    Hi andyl

    Thanks for the quick reply.

    Im still getting the hang of this setup as having UberSvn as an additional layer may be causing me difficulties in understanding how it all fits together, I'm not familiar with the structure of how UberSvn works with subversion.

    Did you check out from your repository to that directory?
    The files are in a repository at the moment they had not been moved form the repo.

    Have you tried it from one of your other workstations
    I'm working directly from the server don't have a workstation with an SVN client to do this, should i install one and try from my MAC? If so can you recommend 1.

    where you're (presumably) already working with those files?
    No they are just sitting in the repo.

    May i please ask what are the correct steps to do this from server side?
    Do i need to check the files out and then run the command and check them in again?

    thanks for your help again, in advance.

  9. #9
    You really, really, really need to read the manual before you do anything else. You aren't going to get very far by just throwing things at the wall to see what sticks.
    I am neither an employee nor customer of WANDisco.

  10. #10
    Hi Andy

    which manual? i have gone over the UberSvn manual completely and there is no mention of setting mime types in there.

    Even tho I'm reasonably versed in setting up apache and have level 2 linux skills i don't have much experience with SVN until this project started.

    Can you please point me in the correct direction, is this an UbrSvn issue or a SVN issue and which manual are you referring to?

    Thank you.

  11. #11
    Thanks for your help Andy i have worked out the issue

    Downloaded tortoise svn client to a VM, read over the manual, checked out the document and changed the properties to text/xml checked it back in again.

    Its now showing as mime type text/xml.

    So it may be that the users accessing the system and uploading the files by default are checking in the files as text/plain and this is set as default for the actual document's so no matter what i was changing on the apache side (server side) of things the document was always displayed as text/plain as this was set from the client side properties.

    Thanks for your help.

  12. #12
    Quote Originally Posted by velocity08 View Post
    Hi Andy

    which manual? i have gone over the UberSvn manual completely and there is no mention of setting mime types in there.
    The manual that I linked in my previous post. It's not about UberSVN, it's a lack of understanding the basic process of working with Subversion.
    I am neither an employee nor customer of WANDisco.

  13. #13
    Hi Andy

    Sorry I had not noticed the link or wouldn't have asked
    Ill do a little reading on it this evening appreciate your help and time.

    Thank you.

  14. #14
    Hi Andyl & Mbooth

    1 more thing even tho i worked out a solution client side what I'm still after is a server side solution to make sure that the server side properly detects and treats the appropriate file extension as it should be and not treating them as text/plain.

    This was part of the problem not just changing the mime type for an individual file.

    Im guessing that the client side properties over write the server side properties or we wouldn't have had success with the changes i had made previously.

    Mbooth if you could please chime in on what needs to be done in UberSvn to make the detection of the appropriate file extension possible as i have already advised of the server side changes made to apache & mime.types config files and this is still not having the desired effect.

    Thank you all for your time and patience.

  15. #15
    Quote Originally Posted by velocity08 View Post
    Hi Andyl & Mbooth

    1 more thing even tho i worked out a solution client side what I'm still after is a server side solution to make sure that the server side properly detects and treats the appropriate file extension as it should be and not treating them as text/plain.

    This was part of the problem not just changing the mime type for an individual file.

    Im guessing that the client side properties over write the server side properties or we wouldn't have had success with the changes i had made previously
    It's not a "client side property." It is a property of the file (Subversion metadata) which you are editing and then committing to the repository (please, read the manual, it will start making sense then).

    What you are doing, when you set svn:mime-type, is telling Subversion how to handle the file. When you request the file via HTTP, it's not "just" Apache that's handling the request, it's also the Subversion libraries (as implemented via mod_dav_svn) and that's where the mime-type is coming out of.

    The proper way to make this work is what I've already described here - set the mime-type property on the file stored in Subversion itself.

    To really lock this in properly, you need to also:
    • Instruct all committers to be sure that they set this property on all new files they add
    • Encourage them to set an auto-prop in their client configuration so they don't have to remember to do it (you'll find this in the manual)
    • Put a pre-commit hook in place on the server to inspect commits and reject any where an XML file is added without this property, or the property is removed from an existing file that already has the property set.
    I am neither an employee nor customer of WANDisco.

  16. #16
    Thanks Andyl

    Ill advise to have these policies put into place and work it out with our client.

    I really do appreciate you taking the time to explain the overall concept and ill start understand it better once i go over the supplied manual.

    Thanks again speak soon.

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •