Version Control with Subversion - Login

Advanced Topicsits value to populate the Content-type: HTTP header when responding to GET requests.This gives your web browser a crucial clue about how to display a file when youuse it to peruse your Subversion repository's contents.File ExecutabilityOn many operating systems, the ability to execute a file as a command is governed by thepresence of an execute permission bit. This bit usually defaults to being disabled, and mustbe explicitly enabled by the user for each file that needs it. But it would be a monumentalhassle to have to remember exactly which files in a freshly checked-out working copy weresupposed to have their executable bits toggled on, and then to have to do that toggling. So,Subversion provides the svn:executable property as a way to specify that the executablebit for the file on which that property is set should be enabled, and Subversion honorsthat request when populating working copies with such files.This property has no effect on filesystems that have no concept of an executable permissionbit, such as FAT32 and NTFS. 4 Also, although it has no defined values, Subversionwill force its value to * when setting this property. Finally, this property is valid only on files,not on directories.End-of-Line Character SequencesUnless otherwise noted using a versioned file's svn:mime-type property, Subversion assumesthe file contains human-readable data. Generally speaking, Subversion uses thisknowledge only to determine whether contextual difference reports for that file are possible.Otherwise, to Subversion, bytes are bytes.This means that by default, Subversion doesn't pay any attention to the type of end-of-line(EOL) markers used in your files. Unfortunately, different operating systems have differentconventions about which character sequences represent the end of a line of text in a file.For example, the usual line-ending token used by software on the Windows platform is apair of ASCII control characters—a carriage return (CR) followed by a line feed (LF). Unixsoftware, however, just uses the LF character to denote the end of a line.Not all of the various tools on these operating systems understand files that contain lineendings in a format that differs from the native line-ending style of the operating system onwhich they are running. So, typically, Unix programs treat the CR character present in Windowsfiles as a regular character (usually rendered as ^M), and Windows programs combineall of the lines of a Unix file into one giant line because no carriage return-linefeed (orCRLF) character combination was found to denote the ends of the lines.This sensitivity to foreign EOL markers can be frustrating for folks who share a file acrossdifferent operating systems. For example, consider a source code file, and developers thatedit this file on both Windows and Unix systems. If all the developers always use tools thatpreserve the line-ending style of the file, no problems occur.But in practice, many common tools either fail to properly read a file with foreign EOLmarkers, or convert the file's line endings to the native style when the file is saved. If theformer is true for a developer, he has to use an external conversion utility (such asdos2unix or its companion, unix2dos) to prepare the file for editing. The latter case requiresno extra preparation. But both cases result in a file that differs from the original quiteliterally on every line! Prior to committing his changes, the user has two choices. Either hecan use a conversion utility to restore the modified file to the same line-ending style that itwas in before his edits were made, or he can simply commit the file—new EOL markersand all.The result of scenarios like these include wasted time and unnecessary modifications tocommitted files. Wasted time is painful enough. But when commits change every line in afile, this complicates the job of determining which of those lines were changed in a nontrivi-4 The Windows filesystems use file extensions (such as .EXE, .BAT, and .COM) to denote executable files.51