Hi Raju,

Changeset

A change set is a means by which one organization can send customizations to another organization. For example, you could create a new object in a sandbox organization and send it to your production organization using a change set. Change sets can only contain modifications you can make through the Setup menu; therefore, you can't use a change set to upload a list of contact records. In other words, change sets contain metadata, not data.
When you want to send customizations from your current organization to another organization, you create an outbound change set. Once you send the change set, the receiving organization sees it as an inbound change set.
Sending a change set between two organizations requires a deployment connection. Currently, change sets can only be sent between organizations that are affiliated with a production organization, for example, a production organization and asandbox, or two sandboxes created from the same organization.
Deploy all dependent components
Make sure each outbound change set contains all interdependent components that don't exist in the target organization. If you try to deploy a component that refers to another component missing from the target organization and from the change set, the deployment fails.
Change sets give you fine-grained control over what you deploy. For example, you can migrate custom fields individually. To deploy a custom object and all of its fields, you must add the custom object and every field to the change set; adding just the custom object to the change set won't cause deployment to fail, but results in an empty custom object.
Add permissions and access settings to outbound change sets
Adding profiles or permission sets to outbound change sets allows administrators to migrate permissions for users so they can access the new functionality. Profiles contain access settings for more components than permission sets, including page layouts, record types, and tab settings. However, permission sets contain access to standard object permissions, standard field permissions, and user permissions (such as “API Enabled”).
Clone a change set to add dependent components to an uploaded change set
After you upload a change set, you can't change its contents. If you need to add dependent components to a change set you already uploaded, clone the change set, add the dependent components, and then upload it again.
Plan deployments around maintenance schedule
Plan your deployment activities around the maintenance schedule for both your production and sandbox organizations. Some features require information from your production organization when accessed from a sandbox.
Validate change sets before deployment
You can perform a test deployment of an inbound change set to view the success or failure messages that would occur with an actual deployment. This is a good idea if you are planning a deployment on a schedule (for example during low-use hours) and want to determine if the deployment will succeed ahead of time. However, you don't need to perform a test deployment every time you deploy, as this process takes time to complete. To test deploy an inbound change set, click its name and then click Validate.
View component details
You can view the XML representation of a component before you upload an outbound change set or deploy an inbound change set.
Change sets limited to 2500 components and 400 MB
Change sets are limited to 2500 components and a total file size of 400 MB. If your change set exceeds either of these limits, you can create separate change sets for email templates, dashboards, and reports. These components are often the most numerous and have fewer dependencies.
Deleting and renaming components
You can't use change sets to delete or rename components. To delete components, use the Web interface on the target organization. To rename a component, first delete the component on the target organization and then upload the new component in a change set.

Eclipse

The Force.com IDE is a powerful client application for creating, modifying, testing and deploying Force.com applications. Based on the Eclipse platform, it provides a comfortable environment for programmers familiar with integrated development environments, allowing you to code, compile, test, and deploy all from within the IDE itself.
Salesforce.com's PaaS product is known as the Force.com Platform. The platform allows external developers to create add-on applications that integrate into the main salesforce.com application and are hosted on salesforce.com's infrastructure. These applications are built using Apex (a proprietary Java-like programming language for the Force.com Platform) and Visualforce (an XML-like syntax for building user interfaces in HTML, Ajax or Flex).
Feature
•Apex Code: Use the full power of Eclipse’s code-editing tools to create, edit, and test your Apex code. These capabilities include syntax and error highlighting and test suite execution.
•Source Control Support: The Eclipse toolkit allows you to use the native source control capabilities available in Eclipse when editing, tracking, and deploying your changes to Salesforce, allowing multi-developer teams to collaborate on Apex code-based projects more effectively.
•Apex Code Deployment: Use a wizard-based process to migrate your Apex code between Force.com Sandbox, Developer Edition, and production environments.
•Initial Metadata API Support: This release of the Eclipse toolkit provides initial support for creating, editing, and managing text-based metadata enabled by the metadata API enhancements described in that section of the admin preview.

Did this answer your question? If not, let me know what didn't work, or if so, please mark it solved.

Regards,
Rajesh Potnuru