Version Control with Subversion - Login

Advanced Topicsall, and sensible only when interpreted by software that understands the PNG formatand can render the information in that format as a raster image.Unfortunately, some of those extensions have changed their meanings over time.When personal computers first appeared, a file named README.DOC would have almostcertainly been a plain-text file, just like today's .txt files. But by the mid-1990s,you could almost bet that a file of that name would not be a plain-text file at all, but insteada Microsoft Word document in a proprietary, non-human-readable format. Butthis change didn't occur overnight—there was certainly a period of confusion for computerusers over what exactly they had in hand when they saw a .DOC file. 3The popularity of computer networking cast still more doubt on the mapping betweena file's name and its content. With information being served across networks andgenerated dynamically by server-side scripts, there was often no real file per se, andtherefore no filename. Web servers, for example, needed some other way to tellbrowsers what they were downloading so that the browser could do something intelligentwith that information, whether that was to display the data using a program registeredto handle that datatype or to prompt the user for where on the client machineto store the downloaded data.Eventually, a standard emerged for, among other things, describing the contents of adata stream. In 1996, RFC 2045 was published. It was the first of five RFCs describingMIME. It describes the concept of media types and subtypes and recommends asyntax for the representation of those types. Today, MIME media types—or “MIMEtypes”—are used almost universally across email applications, web servers, and othersoftware as the de facto mechanism for clearing up the file content confusion.For example, one of the benefits that Subversion typically provides is contextual, linebasedmerging of changes received from the server during an update into your working file.But for files containing nontextual data, there is often no concept of a “line.” So, for versionedfiles whose svn:mime-type property is set to a nontextual MIME type (generally,something that doesn't begin with text/, though there are exceptions), Subversion doesnot attempt to perform contextual merges during updates. Instead, any time you have locallymodified a binary working copy file that is also being updated, your file is left untouchedand Subversion creates two new files. One file has a .oldrev extension and containsthe BASE revision of the file. The other file has a .newrev extension and containsthe contents of the updated revision of the file. This behavior is really for the protection ofthe user against failed attempts at performing contextual merges on files that simply cannotbe contextually merged.The svn:mime-type property, when set to a value that does not indicate textualfile contents, can cause some unexpected behaviors with respect to otherproperties. For example, since the idea of line endings (and therefore, lineendingconversion) makes no sense when applied to nontextual files, Subversionwill prevent you from setting the svn:eol-style property on such files.This is obvious when attempted on a single file target—svn propset will errorout. But it might not be as clear if you perform a recursive property set, whereSubversion will silently skip over files that it deems unsuitable for a given property.Beginning in Subversion 1.5, users can configure a new mime-types-file runtime configurationparameter, which identifies the location of a MIME types mapping file. Subversionwill consult this mapping file to determine the MIME type of newly added and importedfiles.Also, if the svn:mime-type property is set, then the Subversion Apache module will use3 You think that was rough? During that same era, WordPerfect also used .DOC for their proprietary fileformat's preferred extension!50