September 19, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

A Crash Course in Subversion, Part 2

  • May 6, 2005
  • By Garrett Rooney
  • Send Email »
  • More Articles »

svn:mime-type

The simplest of Subversion's special properties is svn:mime-type, which tells Subversion what mime type a particular file is. This is used in two ways. First, if a file has a mime type that doesn't start with text (or some other prefix that Subversion knows refers to a textual file), it won't try to automatically merge changes into the file, or do end-of-line translation or keyword expansion, all of which rely on a file being textual in nature. This keeps Subversion from accidentally mangling binary files, something that can be a constant problem in other version control systems (specifically CVS, and to a lesser degree Perforce). When you run svn add on a file, Subversion will attempt to determine if the file you're adding is textual, and if it isn't, it will set the mime type to application/octet-stream, which just means that the file is some kind of binary format. If you want a more specific mime type, you'll have to set it manually with svn propset or svn propedit. The second reason for setting a svn:mime-type property is so that Subversion's mod_dav_svn Apache module can serve the file as the correct mime type. This allows you to browse the repository in a web browser and have things generally work as you expect (e.g., HTML pages are rendered as HTML instead of plain text, images can be viewed as the appropriate image type, and so on). You'll explore mod_dav_svn further in the next chapter.

svn:ignore

The other special property you've already seen is svn:ignore, which is Subversion's equivalent of CVS's .cvsignore feature. Often, files will show up in your working copy that don't want to be checked in to Subversion—for example, object files that are generated as part of a program's build process or backup files that are generated by text editors. To keep these files from constantly showing up in the output of svn status and generally being annoying, you can simply add an entry to the directory's svn:ignore property that matches their filenames, and svn status will ignore them, unless you pass it the --no-ignore option. This can probably be best shown with an example:

$ ls -a
./          Makefile        main.c    foo.c
../         .svn/main.c    ~foo.c     ~
$svn status
?     main.c~
?     foo.c~
$ svn propset svn:ignore "*~"
property 'svn:ignore' set on ''
$ svn status
 M     .
$ svn commit -m "added *~to svn:ignore"
Sending        .
Committed revision 70.
$ svn status
$ svn status --no-ignore
I      main.c~
I      foo.c~
$

As usual, you can find some more information about the output of svn status in this example. At first, the main.c~ and foo.c~ file shows up as an unversioned file.3 This is somewhat irritating and clutters up the output of svn status, because you normally don't care about the backup files generated by your editor. To get rid of that output, you set the svn:ignore property on the directory to "*~", and you can see that the next svn status shows you the property modification on the directory, but doesn't say anything about the files that end in a tilde (~). You then commit, and the third svn status shows you nothing at all. Finally, you see that it's possible to run svn status --no-ignore, and you're informed by the I in the first column that the main.c~ and foo.c~ files are indeed being ignored. To add more patterns to the list of things to be ignored, just place them on separate lines in the property.

svn:keywords

One feature of the RCS-based version control systems that you haven't yet seen in Subversion is the ability to embed special keywords in files and have Subversion expand them into something when the file is checked out. You'll generally use this to embed the revision in which the file was last changed or the URL of the file in the repository (or something like that) in the file so that the information will be easy to access without having to use Subversion. This can be important if you're rolling a release of some software, and you want people to be able to accurately report what version of a particular file they have when sending in bug reports. In some other version control systems, keywords turn out to be a mixed blessing, because it's quite possible for there to be a file that contains the keyword but it would be a bad idea for Subversion to expand it (binary files come to mind). For this reason, Subversion defaults to not expanding any keywords. If you want Subversion to do so, you need only set the svn:keywords property on the file to a string containing the names of the keywords you would like expanded, separated by spaces, and it will expand them for you. Subversion supports the following keywords: HeadURL (abbreviated as URL), which expands to the URL of the file in the repository; LastChangedBy (abbreviated as Author), which expands to the username of the last person who modified the file; LastChangedDate (abbreviated as Date), which stores the date on which the file was last modified; LastChangedRevision (abbreviated as Rev), which stores the revision in which the file last changed; and Id, which stores a compressed version of the other four keywords. Let's take a look at how these keywords work in an example.

$ cat main.c
#include <stdio.h>
int
main (int argc, char *argv [])
{
   printf ("hello world \n");
   return 0;
}
$ vi main.c
[ ... add keywords ... ]
$ cat main.c
/*$URL$
 *$Rev$
 *$Author$
 *$Date$
 *$Id$
 */
#include <stdio.h>
int
main (int argc, char *argv [])
{
   printf ("hello world \n");
   return 0;
}
$ svn propset svn:keywords "Url Rev Author Date Id" main.c
property 'svn:keywords'set on 'main.c'
$ svn commit -m "Set svn:keywords on main.c"
Sending        main.c
Committed revision 75.
$ cat main.c
/*$URL:file:///path/to/repos/main.c $
 *$ Rev:3 $
 *$ Author:rooneg $
 *$ Date:2003-06-30 18:37:06 -0400 (Mon,30 Jun 2003)$
 *$ Id:main.c 3 2003-06-30 22:37:06Z rooneg $
 */
#include <stdio.h>
int
main (int argc, char *argv [])
{
   printf ("hello world \n");
   return 0;
}
$

In this example, a comment is added to the top of main.c, which contains the $URL$, $Rev, $Author$, $Date$, and $Id$ keywords. Then, the svn:keywords property is set to Url Rev Author Date Id, and the change is committed. After the commit, the keywords in main.c expand to hold information about the current version of main.c.

svn:eol-style

A constant issue for developers of cross-platform software is the fact that different operating systems use different characters to indicate the end of a line in a text file. Worse yet, some tools are extremely picky about the line endings of the files they consume. svn:eol-style makes it a bit easier to deal with such tools. By setting it to native, you can ensure that the file in question is always in the native end-of-line style, making it easy to interoperate with tools on the system. Unix operating systems (including Mac OS X) use LF line endings when native is specified, Windows-based systems use CRLF and, hypothetically, Classic Mac OS systems would use CR, but that's academic because Subversion doesn't run on Classic Mac OS. For cases in which a specific line-ending style is always required (for example, the .dsp files Microsoft Visual Studio uses must use a carriage return and linefeed at the end of each line), you can set it to either LF to indicate only linefeeds should be used, CR to indicate only carriage returns should be used, or CRLF to indicate carriage return/linefeed-style endings. As mentioned in the svn:mime-type discussion, these line-ending conversions can be applied only to files with a textual mime type.

svn:executable

Another common need for software development is to specify that certain files are executable, meaning that the operating system can run them as full-fledged programs. This is a somewhat platform-specific thing to do, as some operating systems, such as Microsoft Windows, don't have a way to indicate that a particular file is executable. In any case, if the svn:executable property is set to on, Subversion will use whatever platform-specific means it can to make the file executable when it's checked out into a working copy.





Page 4 of 6



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel