SVN

The command line client for the Subversion is svn. The syntax of svn is:

svn [options] subcommands [arguments]

The options and subcommands may be provided in any order.

svn Options:

Subversion has many options for its subcommands. All the options of the Subversion are global, means each option means the same thing regardless of the subcommand. E.g. –verbose(-v) always means “verbose output” with whichever subcommand you use it with.

svn Subcommands:

The Subcommands are the main user interface to Subversion. It is with them that the user performs operations on the Subversion.

svn Arguments:

Arguments are the parameters provided to the subcommands to perform certain options. Each subcommand has its own set of arguments.

Keywords.

Subversion defines a set of keywords which are available for substitution. A keyword provides useful dynamic information about versioned files. They generally provide information about the last modification made to the file. The following are the list of keywords provided by Subversion.

1. LastChangedDate (Alias Date):

This gives us the date and time when the file was last changed in the repository. It’s in the form $LastChangedDate: 2009-06-12 10:53:37 (Fri, 12 June 2009) $.

2. LastChangedRevision (Alias Revision or Rev):

This describes the last revision to the repository in which this particular file was modified. It looks like $LastChangedRevision: 119 $

3. LastChangedBy (Alias Author):

This keyword describes the last user to change this file in the repository and looks like $LastChangedBy: sivardhan $

4. HeadURL (Alias URL):

The information about the full URL to the latest version of the file in the repository is described by this keyword. It looks like $HeadURL: http://svn.collab.net/repos/trunk/README $

5. Id:

This keyword is the compressed combination of all the above keywords. Its substitution looks like this $Id: filename.c 119 2009-06-12 10:53:37Z srivardhan $

Keyword expansion is a client side operation. The client knows about the changes in the repository until the user has updated the last time. If the user does not update the working copy frequently then the client will be showing the wrong metadata information. The Subversion does not expand the keywords until asked to do so.

Subversion defines a set of keywords which are available for substitution. A keyword provides useful dynamic information about versioned files. They generally provide information about the last modification made to the file. The following are the list of keywords provided by Subversion.

1. LastChangedDate (Alias Date):

This gives us the date and time when the file was last changed in the repository. It’s in the form $LastChangedDate: 2009-06-12 10:53:37 (Fri, 12 June 2009) $.

2. LastChangedRevision (Alias Revision or Rev):

This describes the last revision to the repository in which this particular file was modified. It looks like $LastChangedRevision: 119 $

3. LastChangedBy (Alias Author):

This keyword describes the last user to change this file in the repository and looks like $LastChangedBy: sivardhan $

4. HeadURL (Alias URL):

The information about the full URL to the latest version of the file in the repository is described by this keyword. It looks like $HeadURL: http://svn.collab.net/repos/trunk/README $

5. Id:

This keyword is the compressed combination of all the above keywords. Its substitution looks like this $Id: filename.c 119 2009-06-12 10:53:37Z srivardhan $

Keyword expansion is a client side operation. The client knows about the changes in the repository until the user has updated the last time. If the user does not update the working copy frequently then the client will be showing the wrong metadata information. The Subversion does not expand the keywords until asked to do so.

Special File Properties:

One of the special features of the Subversion is that it allows the user to associate properties with files of directories. A “Property” is a “Keyword/Value” pair associated with the file. Subversion has some reserved properties for its own use. They start with “svn:”. The following are the properties:

Svn:author

It’s the subversion username of the person who has committed a particular version.

Svn:date

The date when the change was committed.

Svn:eol-style

The conventions used to indicate the end-of-line(eol) in a text file varies between operating systems. Unix and its workalikes use single Line Feed(LF) character, MS Windows use Carriage Return + Line Feed (CRLF) and older Macintosh systems use only CR. This could pose a problem when some file is committed to the repository from one operating system and checked out from another! This property of Subversion is to solve this problem.

This can have any one of the following values:

1. CR : No matter what the native format of the file is, while committing to the repository client should always use CR line terminators.

2. CRLF : The clients should use CR-LF as line terminators, no matter what the native format is.

3. LF : Client should use only LF line terminators.

4. native : Clients should use the native format when checking out the files.

While storing the files in the repository, Subversion always stores in LF format.

Svn:executable

This property is valid only for files. Its presence indicates that the files should be made executable when checked out or updated from the repository. This property has no effect for the file systems like FAT-32 or NTFS, that does not support execute bit concept.

Svn:externals

This property is valid only for directories. When set, it allows the user to specify the location of external repositories to use for particular local subdirectories. After set, whoever checks out the working copy that directory will automatically get the third party files checked out automatically.

Svn:ignore

This property should be set on directories. It works as a filter to the unversioned files and directories for certain Subversion operations.

Svn:keywords

This property contains a list of keywords for which Subversion has to perform “keyword expansion” when checking out a file.

Svn:log

These are the log messages associated with the commit of a particular revision.

Svn:mime-type

This is an indication of the type of data stored in the file. By default, if it does not begin with text/, Subversion assumes that the file is a binary file. The Subversion renames these binary files with “.orig” extension and replace the file with the current version from the repository. This action prevents an attempt to perform a “merge” on data that cannot be merged.

Svn:realmstring

It’s a special property that describes the “authentication realm” for a file in Subversion’s cached copy of the authentication credentials.

One of the special features of the Subversion is that it allows the user to associate properties with files of directories. A “Property” is a “Keyword/Value” pair associated with the file. Subversion has some reserved properties for its own use. They start with “svn:”. The following are the properties:

Svn:author

It’s the subversion username of the person who has committed a particular version.

Svn:date

The date when the change was committed.

Svn:eol-style

The conventions used to indicate the end-of-line(eol) in a text file varies between operating systems. Unix and its workalikes use single Line Feed(LF) character, MS Windows use Carriage Return + Line Feed (CRLF) and older Macintosh systems use only CR. This could pose a problem when some file is committed to the repository from one operating system and checked out from another! This property of Subversion is to solve this problem.

This can have any one of the following values:

1. CR : No matter what the native format of the file is, while committing to the repository client should always use CR line terminators.

2. CRLF : The clients should use CR-LF as line terminators, no matter what the native format is.

3. LF : Client should use only LF line terminators.

4. native : Clients should use the native format when checking out the files.

While storing the files in the repository, Subversion always stores in LF format.

Svn:executable

This property is valid only for files. Its presence indicates that the files should be made executable when checked out or updated from the repository. This property has no effect for the file systems like FAT-32 or NTFS, that does not support execute bit concept.

Svn:externals

This property is valid only for directories. When set, it allows the user to specify the location of external repositories to use for particular local subdirectories. After set, whoever checks out the working copy that directory will automatically get the third party files checked out automatically.

Svn:ignore

This property should be set on directories. It works as a filter to the unversioned files and directories for certain Subversion operations.

Svn:keywords

This property contains a list of keywords for which Subversion has to perform “keyword expansion” when checking out a file.

Svn:log

These are the log messages associated with the commit of a particular revision.

Svn:mime-type

This is an indication of the type of data stored in the file. By default, if it does not begin with text/, Subversion assumes that the file is a binary file. The Subversion renames these binary files with “.orig” extension and replace the file with the current version from the repository. This action prevents an attempt to perform a “merge” on data that cannot be merged.

Svn:realmstring

It’s a special property that describes the “authentication realm” for a file in Subversion’s cached copy of the authentication credentials.

Features

The Subversion provides the following features

1. Directory Versioning:

The subversion tracks the history of individual file as well as the whole directory. It implements a “virtual” versioned filesystem that tracks changes to whole directory tree over time. All the files and directories are kept versioned.

2. True Version History:

With Subversion, the user can add, delete, copy, move and rename both files and directories. Every new file or directory begins with fresh history. If the file/directory existed before, then user has the option to inherit its history or start with a fresh history for that file/directory. This gives the user more flexibility to maintain history of the file/directory.

3. Atomic Commits:

If you have done more than one change. Then, with Subversion, The collection of modifications either goes into the repository completely, or not at all! This is a boon to the developer as the developer can commit changes as logical chunks. More over he can prevent problems that can occur when only a portion of a set of changes is sent to the repository.

4. Versioned Metadata:

Each file and directory has a set of properties associated with. These are known as “Metadata”. The user can create his any arbitrary property for the file or directory. A property is a Key/Value pair. Just like file/directory contents these properties are versioned over time.

5. Consistent Data Handling:

The Subversion uses binary differencing algorithm to express file differences. This algorithm works identically for both text and binary files. Hence both the files are stored equally compressed in the repository.

6. Efficient Branching And Tagging:

The Subversion creates branches and tags by simply copying the project. This mechanism is similar to a hard link. These operations take only very small and constant amount of time. Hence the cost of branching and tagging is not proportional to the project size.

7. Hackability:

Subversion is implemented as a collection of C libraries with API’s. This makes it extremely maintainable and usable by other applications and languages.

8. Optimized Around The Network:

Local access is faster in several orders of magnitude when compared to remote access to repositories. Hence the Subversion design is optimized to avoid network connectivity whenever possible. It maintains a pristine copy of each file as it was checked out of the repository in the form of “.svn”. This helps in producing the differences very quickly, with no need to contact the repository.

The Subversion provides the following features

1. Directory Versioning:

The subversion tracks the history of individual file as well as the whole directory. It implements a “virtual” versioned filesystem that tracks changes to whole directory tree over time. All the files and directories are kept versioned.

2. True Version History:

With Subversion, the user can add, delete, copy, move and rename both files and directories. Every new file or directory begins with fresh history. If the file/directory existed before, then user has the option to inherit its history or start with a fresh history for that file/directory. This gives the user more flexibility to maintain history of the file/directory.

3. Atomic Commits:

If you have done more than one change. Then, with Subversion, The collection of modifications either goes into the repository completely, or not at all! This is a boon to the developer as the developer can commit changes as logical chunks. More over he can prevent problems that can occur when only a portion of a set of changes is sent to the repository.

4. Versioned Metadata:

Each file and directory has a set of properties associated with. These are known as “Metadata”. The user can create his any arbitrary property for the file or directory. A property is a Key/Value pair. Just like file/directory contents these properties are versioned over time.

5. Consistent Data Handling:

The Subversion uses binary differencing algorithm to express file differences. This algorithm works identically for both text and binary files. Hence both the files are stored equally compressed in the repository.

6. Efficient Branching And Tagging:

The Subversion creates branches and tags by simply copying the project. This mechanism is similar to a hard link. These operations take only very small and constant amount of time. Hence the cost of branching and tagging is not proportional to the project size.

7. Hackability:

Subversion is implemented as a collection of C libraries with API’s. This makes it extremely maintainable and usable by other applications and languages.

8. Optimized Around The Network:

Local access is faster in several orders of magnitude when compared to remote access to repositories. Hence the Subversion design is optimized to avoid network connectivity whenever possible. It maintains a pristine copy of each file as it was checked out of the repository in the form of “.svn”. This helps in producing the differences very quickly, with no need to contact the repository.

Subversion Version Control System.

Introduction:

The Subversion version control system is a powerful Open Source system for management of file and directory versions. It lets you track changes to an individual file as well as an entire project directory tree. Every change made to the tree or an individual file is recorded and can be retrieved at any phase of the project.

It is an Open Source project which was started in 2000 by CollabNet Inc. If you wish to participate then http://subversion.tigris.org/ follow this link and participate in its development. For more detailed explanation about Subversion you may refer to “Version Control with Subversion” book.

How it works?

The Subversion stores the actual data in a repository. A “Repository” is a set of directories and files managed by Subversion. Subversion provides a client program known as ‘svn’ to access the repository and make changes to it.

The Copy-Modify-Merge Development model.

Subversion uses the copy-modify-merge development model.

Copy:

The user makes a private copy of a given project in a sandbox (Sandbox is the term used for local copy of the project). This operation is known as “checking out a copy”.

Modify:

The user can make changes to the private copy within the sandbox. He need not have to worry about what other developers are doing. The user can compare the changes to the version he has started with as well as to the version which is currently in the repository. Once the user is satisfied with the changes, he can copy the required files back to the repository. This process is known as checking-in or “commit”.

Merge:

If another developer has modified the file which the user wanted to check-in, then Subversion notices and indicates to the user that a conflict exists. The Subversion stores the pristine copy of both the files i.e, the one in the repository and the other is the one which user wants to check-in. It marks the conflicts in the file. The user can resolve the conflict and tell the Subversion about it. It then commits the final version of the file.

Branching:

The Subversion lets the user to create a separate development branch which has a separate stream of development versions. The user can periodically merge changes from this development branch to the main branch and vise versa.

Tagging:

Subversion allows the user to “tag” a particular copy of the project. Tagging means, when a project is ready for a release, the user can create a “snapshot” of the project and give a descriptive “tag” to that. It allows the user to re-create the project tree exactly as it was for the release.

Horizontal Rule Line.

In HTML a horizontal line could be drawn using <hr> tag.
E.g.:
<html>
<body>
<p> This is a paragraph. Now I will draw a line <hr /> Now continuing with the paragraph. This is the end </p>
</body>
</html>

Copy the above code and paste in a notepad and save it as .htm or .html. Then open in a web browser to see the output.

It is enough to user <hr> to draw a line. But according to World Wide Web consortium you should close the tag. Hence it is always suggested to close the tag <hr />.

The alignment, color, width, height and even shadow feature of the line could be controlled by the user with the help of attributes. The following are some the attributes which could be used with line.
1.    “width”: It accepts the value as pixels.
E.g. width = “100”
The above example will display a line with a width of 100 pixels. You could also use width = “50%”. But it is deprecated and some browsers don’t support this format.
2.    “size”: It takes the value as pixels. It controls the height of the line.
E.g. size = “10”.
The above example will display a line which has a width of 10 pixels. You could also use “%” format, but that format is deprecated.
3.    “color”: It takes the hex code or the name of the color to apply as background color of horizontal line. Netscape navigator does not support this feature.
E.g. color=”green”
The above example will turn the color of the line to green.
4.    “noshade”: It can be used without any value. But W3C markup validation does not accept it. W3C suggest to use it as
noshade=”noshade”
According to W3C every attribute should have a value assigned. This attribute hides the shadow of horizontal line.
5.    “align”: It takes 3 values namely “left”, “right” and “center”. It aligns the horizontal line to its value. The effect could be seen only if the length of the line is less than that of the browser.

E.g. 1: <hr />

---

E.g. 2: <hr width=”50” size=”20” />

---

Headings

In general Headings are elements that describes the content that follows and also define a document structure. An HTML heading should be similar and should briefly describe what the page or section is about, making it clear to the reader what to expect if he continues to read.

Headings are important in any document. In HTML you can have six kinds of headings. The tags <h1> to <h6> could be used for headings. <h1> defines the largest heading and <h6> defines the smallest heading. Browsers automatically add an empty line before and after headings.

Heading 6

Heading 5

Heading 4

Heading 3

Heading 2

Heading 1

Headings are very important in an HTML document and it should be used only for Heading and should not be used to make the text appear big or bold. Search engines use the headings to index the structure and content of the web page. Since users may skim the web page by its headings, it is important to use the headings to show the document structure. H1 heading should be used as main heading, followed by H2, H3 etc.

Headings do not have any unique attributes tied to them. The attributes associated with headings are general attribute.

What if your document has more than 6 headings?
Well in that case you should rearrange your document in such a way that it has max of 6 headings. The World Wide Web consortium thinks that having more than 6 level of heading in a document is confusing!
If you still want more than 6 headings in your HTML document then you should manually make the text to look like a heading using style. You will learn about this in the later chapters.

The headings should be nested. This should be taken care by you because the Browsers doesn’t check for the levels of headings. They just read and display it. If you put a H2 heading after H3 or even H6, the browser will just display as it is and does not check. You should take care of how your document should look.

Choosing which heading tag to use at a specific spot should not be a matter of thought. First heading defines a large section, usually an entire document. The next one could be second heading and so on. If the content you are describing could be treated as the “child” of the previous content, then the heading which is one step down the hierarchy could be used. If the content could be treated as “sibling” of the previous content then the same heading could be used. That would create a certain logical flow.

Attributes

Attributes provide additional information about HTML Elements. They are always specified in the start tag or opening tag. They always come in Name/Value pair i.e, name = “value” type. The ‘value’ should always be enclosed within the quotes

E.g: <a href=”www.vocationaltechie.wordpress.com”> This is a link </a>
In the above example “href” is an attribute and “www.vocationaltechie.wordpress.com” is its value. The href attribute tells the hyperlink to where the page should navigate when the user clicks on the “This is a link”.

The attribute value should always be enclosed in quotes. It could be double or single quotes. Double quotes are most commonly used. In rare situations where value itself contains a quotes then single quotes are used.

E.g: name = ‘Manoj “Manu” Kumar’.

The attribute names and their values are case-insensitive. However World Wide Web consortium recommends using lowercase for attribute names and values in HTML 4. So it is always better to follow the standard. So use only lowercase for attributes and their values. Newer versions of HTML and XHTML demands lowercase for attributes and their values.

The following are list of standard attributes which are supported by almost all (there are exceptions) HTML and XHTML tags.
Attriute…………….:class
Value……………….:classname
Description………….:Specifies a classname for an element.
Not Valid in these Tags    :base, head, html, meta, param, script, style and title.

Attriute…………….:id
Value……………….:id
Description………….:Specifies a unique id for an element.
Not Valid in these Tags    :base, head, html, meta, param, script, style and title.

Attriute…………….:style
Value……………….:style_definition
Description………….:Specifies a inline style for an element.
Not Valid in these Tags    :base, head, html, meta, param, script, style and title.

Attriute…………….:title
Value……………….:text
Description………….:Specifies extra information about an element.
Not Valid in these Tags    :base, head, html, meta, param, script, style and title.

Attriute…………….:dir
Value……………….:ltr(left to right), rtl(right to left)
Description………….:Specifies the text direction for the content in an element.
Not Valid in these Tags    :base, br, frame, frameset, hr, iframe, param and script.

Attriute…………….:lang
Value……………….:language_code
Description………….:Specifies a language code for the content in an element.
Not Valid in these Tags    :base, br, frame, frameset, hr, iframe, param and script.

Attriute…………….:xml:lang
Value……………….:language_code
Description………….:Specifies a language code for the content in an element in a XHTML document.
Not Valid in these Tags    :base, br, frame, frameset, hr, iframe, param and script

Attriute…………….:accesskey
Value……………….:character
Description………….:Specifies a keyboard shortcut to access an element.

Attriute…………….:tabindex
Value……………….:number
Description………….:Specifies the tab order of an element.

Element

All HTML documents are defined by HTML elements. An Element is everything from the opening tag to the end tag.
E.g: <p> This is a paragraph</p>
In the above everything starting from <p> to </p> including the tags is considered as one element.

An element could have empty content.
E.g: <td></td>

Some elements are closed in the start tag itself.
E.g: <br />

Some elements will have attributes describing them.
E.g: <img src=”image.jpg” width=”50” height=”40” \>

Elements could also be nested. In fact in a HTML document most of the elements are nested. A nested element is one whose start tag and end tag are within other element.
E.g:
<html>
<body>
<p>
This is a paragraph
</p>
</body>
</html>
The above HTML document contains 3 elements.
1.    The Paragraph Element: Everything between <p> and </p> is considered as one element. This is a paragraph element in HTML. The content of this element is “This is a paragraph”.
2.    The Body Element: Everything between <body> and </body> is a body element. The element content is another element (i.e, a paragraph element). The content of the body element are visible.
3.   The HTML Element: Everything between <html> and </html> is a HTML element. The content of this element is another element(i.e, a body element). The content of this element constitutes the HTML document.

Most browsers display the contents correctly even if it does not contain closing tag. But it is always better to practice to close a tag soon after opened. If not, sometime it could produce unexpected result.

As mentioned before an element could have empty content. This element is called Empty Element. Empty elements could be closed in the opening tag itself.
E.g: <br /> (it defines a line break).

HTML tags are not case sensitive, i.e, <p> and <P> are both same. The World Wide Web consortium suggests to use lowercase for tags in HTML 4, and demands lowercase tags in future version of HTML i.e, XHTML. Though some websites user upper case for HTML tags it is better for you to practice with lowercase.

Basics

To learn HTML you need a notepad and a browser that’s it. Notepad is to edit and the browser is to view the output. The professional web designers use HTML editors like Microsoft FrontPage or Dreamweaver. But it is always better to practice using notepad and then migrate to these editors, because it will help you in learning HTML. The best way to learn anything is to practice. So if you want to learn just open a notepad and go on using the tags you come across and try to design a page by yourself.

The HTML files could be of either of the 2 extension “.htm” or “.html”. Many use “.htm” as it is a habit from the past when the softwares allowed only 3 letters for the extension of the file. But now it is perfectly safe to use .html.

Now let us start learning with the tags.

1.   HTML Headings: There are totally 6 tags for HTML headings i.e, from <h1> to <h6>. This means you can have 6 kinds of headings in HTML. Any text between the 2 tags <h1> </h1>  is considered as 1st heading. Similarly for <h2>  </h2> etc.
ex: <h1>First heading</h1>
<h2>second heading</h2>
2.    HTML Paragraphs: HTML paragraphs are defined with tags <p> & </p>. Any text between these 2 tags is considered as a paragraph. The browsers automatically insert a line before and after every paragraph.
ex: <p> This is a paragraph. </p>
3.   HTML Links: HTML links are defined with the tags <a>. The link address is provided as an attribute “href” i.e, html reference.
ex: <a href = “www.vocationaltechie.wordpress.com”> Pressing on this text will take you to that link. </a>
4.   HTML Images: The HTML images are defined with <img> tag. The name of the image and its size are provided as attributes.
ex: <img src=”nameofimage.jpg” width=”104” height=”50” />
Note that this is a single tag which closes itself and does not have another closing tag.