Version Control with Subversion - Login

Advanced Topicsal way. Where was that bug really fixed? On what line was a syntax error introduced?The solution to this problem is the svn:eol-style property. When this property is set toa valid value, Subversion uses it to determine what special processing to perform on thefile so that the file's line-ending style isn't flip-flopping with every commit that comes from adifferent operating system. The valid values are:nativeThis causes the file to contain the EOL markers that are native to the operating systemon which Subversion was run. In other words, if a user on a Windows machine checksout a working copy that contains a file with an svn:eol-style property set to native,that file will contain CRLF EOL markers. A Unix user checking out a working copythat contains the same file will see LF EOL markers in his copy of the file.Note that Subversion will actually store the file in the repository using normalized LFEOL markers regardless of the operating system. This is basically transparent to theuser, though.CRLFThis causes the file to contain CRLF sequences for EOL markers, regardless of the operatingsystem in use.LFCRThis causes the file to contain LF characters for EOL markers, regardless of the operatingsystem in use.This causes the file to contain CR characters for EOL markers, regardless of the operatingsystem in use. This line-ending style is not very common.Ignoring Unversioned ItemsIn any given working copy, there is a good chance that alongside all those versioned filesand directories are other files and directories that are neither versioned nor intended to be.Text editors litter directories with backup files. Software compilers generate intermediate—oreven final—files that you typically wouldn't bother to version. And users themselvesdrop various other files and directories wherever they see fit, often in version control workingcopies.It's ludicrous to expect Subversion working copies to be somehow impervious to this kindof clutter and impurity. In fact, Subversion counts it as a feature that its working copies arejust typical directories, just like unversioned trees. But these not-to-be-versioned files anddirectories can cause some annoyance for Subversion users. For example, because thesvn add and svn import commands act recursively by default and don't know which filesin a given tree you do and don't wish to version, it's easy to accidentally add stuff to versioncontrol that you didn't mean to. And because svn status reports, by default, every item ofinterest in a working copy—including unversioned files and directories—its output can getquite noisy where many of these things exist.So Subversion provides two ways for telling it which files you would prefer that it simplydisregard. One of the ways involves the use of Subversion's runtime configuration system(see the section called “Runtime Configuration Area”), and therefore applies to all the Subversionoperations that make use of that runtime configuration—generally those performedon a particular computer or by a particular user of a computer. The other way makes use ofSubversion's directory property support and is more tightly bound to the versioned tree itself,and therefore affects everyone who has a working copy of that tree. Both of the mechanismsuse file patterns (strings of literal and special wildcard characters used to matchagainst filenames) to decide which files to ignore.52