Learning is an Art

What is CSS
CSS is an acronym for Cascading Style Sheets. CSS is a style language that defines layout of HTML documents. CSS covers fonts, colors, margins, lines, height, width, background images, advanced positions and a lot more things.

Why CSS was required?

HTML tags were originally designed to define the content of a document. The layout of the document was supposed to be taken care of by the browser, without using any formatting tags. As the Netscape and Internet Explorer started adding new HTML tags and attributes (like font and color attribute) to the original HTML specifications, it become pretty difficult to create Web Sites where the content of HTML documents was clearly separated from the document’s presentation layout. To solve this problem, the World Wide Web Consortium (W3C) – the non profit, standard setting consortium, responsible for standardizing HTML – created STYLES in addition to HTML 4.0.

What I Should Know Before Starting?

You should have basic understanding HTML 4.0 or XHTML 1.0

What CSS can do For Me?

You can control layout of many HTML documents from single style sheet

You can change layout at will, without messing with HTML code

Getting Started

CSS is made of three parts: a selector a property and value

Selector

The selector is normally the HTML element/tag you wish to define, the property is the attribute you wish to change, and each property can take a value. The property and value are separated by a colon, and surrounded by curly braces:

Assigns Times New Roman font to all h1 tags.

If you wish to assign multiple properties, you can do it by separating properties by separating by a semicolon as shown below:

Above example shows how to define a right aligned paragraph, with a green text color.

Grouping Selectors

You can group selectors. Separate each selector with a comma. In the example below we have grouped all the header elements. All header elements will be have font family Times New Roman:

Selector with Classes

With classes you can assign different styles to same type of HTML elements

You have to use the class atribute in your HTML document as shown below

Do not start a class name with numeral. It will not work in Firefox.

Writing Comments in CSS

Comments are as important as code itself, so now we will see how to write comment in CSS. Comment in a CSS file starts with “/*” and ends with “*/”. As shown in example below

Inserting Style Sheet in Your HTML Document

Where BlueMariner is the name of your CSS File.

CSS validator

To make it easier to observe the CSS standard, W3C has made a so-called validator which reads your stylesheet and returns a status listing errors and warnings, if your CSS does not validate. CSS Validator can be also downloaded from W3C WebSite.

This article assumes that you have installed and running Apache Server 2.0.59 and Apache is hosting your Subversion 1.4.4 repositories on windows XP machine. Might work with other versions and other Operating Systems also but same is not tested as far as I am concerned.

Step1: Changes in Apache httpd.conf

Add SVNAutoversioning directive in your Apache’s configuration file as shown below, which can be found in conf directory Apache installation.

When SVNAutoversioning is active, write requests from WebDAV clients result in automatic commits. A generic log message is auto-generated and attached to each revision. Before activating this feature, however, understand what you’re getting into. WebDAV clients tend to do many write requests, resulting in a huge number of automatically committed revisions. For example, when saving data, many clients will do a

of a 0-byte file (as a way of reserving a name) followed by another

with the real file data. The single file-write results in two separate commits. Also consider that many applications auto-save every few minutes, resulting in even more commits.

If you have a post-commit hook program that sends email or generates RSS feeds, you may want to disable email and feed generation either altogether, or on certain sections of the repository.

<Location /repos>

DAV svn

SVNPath /path/to/repository

SVNAutoversioning on

ModMimeUsePathInfo on

</Location>

ModMimeUsePathInfo allows

which is Apache’s module to attempt automatic deduction of the mime-type on new files that enter the repository via autoversioning. The module looks at the file’s named extension and possibly the contents as well; if the file matches some common patterns, then the the file’s

property will be set automatically. For this you will have to uncomment or add the load module directive for mod_mime.

LoadModule mime_module modules/mod_mime.so

Make sure that this line is present in load module section of httpd.conf and uncommented.

Now your Apache is set to accept DeltaV or WebDAV Clients.

Step2: Creating Network Share

Create network share i.e. a web share on some client machine or you can do it on same machine.

Go to My Network places -> add network place

You will see add a network place wizard click on next, than you will ask where you want to create this network place click next.

You will see a window as shown below asking you to enter Internet or network address

Enter http path to your repository, please don’t forget to add port number to it. e.g. http://myserver/repos and click next than you will be asked for authentication enter your credentials for repository access and than it will ask you the name of your network share enter any name you want.

Your repository is mounted as network or Web Share.

Now you can edit your files and cross check your repositories log messages to see auto commits and auto generated log messages. Which say’s commit by a non DeltaV client.

But before really using it you should make sure that you should know what you are doing. As far as I see this can be of great help to people who are non-developer and want to manage documentations with customers and among there team with actually needing a Subversion client lie Tortoise, many people think it’s a killer feature and I am no exception to it but the bottom line is that it comes at cost and you should know what the cost is and you are willing to pay it.

There has been a lot of fuss about which is the better version control system among the likes of CVS, Subversion, Git, SVK, Perforce, Accurev, the list goes on and on. But I am going to limit myself to Git and Subversion which are frequently being compared in the arena of SCM. These two version control systems fall in two different categories

• Distributed version control systems like Git and Code Co-Op
• Centralized version control systems like CVS and SVN

Distributed Version Control system

• In a distributed version control system every developer has his own private copy of the complete source code on his or her machine.
• They can put changes in their modules and can sync their changes with other developers.
• If by any means, access to the developer’s machine with whom you generally sync is not available, you have options to sync it with others. Also there is no bottleneck as you can sync with anyone in your project.
• This system is generally structured as a pyramid, as developers at a particular level can deliver changes with other developers on their level or the level above them and at the top of the pyramid is the person who holds the decision of what actually goes in the main line of development.
• Developers can work on the source code their own way without affecting anyone else. These developers can work with their fellow developers and sync changes with each other.
• Each can decide what changes to accept or reject from their fellow developers.
• The advantage is that the code is distributed and there is no “point of failure”.
• Distributed systems enable a lot of private work in a way that is bad for the development.
• Maintenance tends to be sloppier on distributed systems.
• Git falls in this category; this type of development is not used very commonly. Perhaps the biggest example of this is Linux kernel development.

Centralized Version Control system

• In a centralized system there is a repository on the central server where all the source code goes.
• Every developer checks out the working copy of the same piece of code and then makes changes in their working copy and everyone can commit changes to the main line of development.
• Anybody can put changes in anyone’s module if no folder level control is exercised.
• In such a system every one gets the changes of other developers whether they are willing to do so or not. A centralized system is much more likely to be backed up and its hardware kept up to date.
• Subversion falls in this category. This type of development is very common. Sourceforge.net follows this type of version control.

The distributed systems do work by not needing a server (except for rsync and any web server). But truly speaking the server-less system they set up is more complicated in actual practice than a single well-maintained server.

The official claim is that a centralized server cannot handle distributed type of development. I disagree that centralized servers cannot handle this development methodology. Let’s imagine a centralized version control system that has excellent branch development capabilities. No developer directly works off the trunk. Instead, each developer has one branch that is created from the trunk. Developers can merge their branches into the trunk or in other branches as done in distributed systems. For this to work, branching and merging operations must be smooth. And even the pyramid structure of distributed system can be implemented by controlling which all branches are to be merged in the trunk.

Subversion can be better but this has nothing to do with centralization. With the benefits of a centralized system, Subversion also gives you the flexibility to be used as a distributed system if you use right approach to it.

This is my personal opinion based upon my experiences working in the software engineering field. Feel free to comment on it and point out errors in judgment, if any.