Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6j ss

2010-11-18T00:16:17Z

Marashid:

'''Service-Oriented Architecture'''

A few years ago, it was realized that eventually software capabilities are going to be delivered and consumed as services. Implementing them as tightly coupled systems was definitely an option, but, a service-based interface was required between the point of usage to the portal, device or another end-point. Thus, there was the need of a service-oriented architecture that would facilitate the management of delivery, acquisition, consumption etc in terms of services that are related. This hinted at changes in how software life cycle is managed —right from requirements specifications as services, designing these services, acquisition and outsourcing in the form of services, asset management of services, and so on. Thus, after moving from modules to objects, to components, now was the time to move to services.

This wiki chapter aims at providing an introduction to the vast and growing field of '''''Service Oriented Architecture'''''. The chapter also discusses the different '''design patterns'''[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29] currently in practice for the field of Service-Oriented Architecture. The utilization of the concepts of '''coupling'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29] and '''cohesion'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29] in Service-Oriented Architecture are described. SOA is contrasted with a similar concept called Enterprise Architecture.

= Introduction =

Service-oriented architecture (SOA) is a collection or set of services communicating with each other. Two or more services can communicate either via a simple data passing system or could be coordinating on some activity. For these kind of communications to be possible between the services, some means to connect the various services is required. 

Service-oriented architectures were existing in the past and are not a new thing. Many people are familiar with the use of '''DCOM''' [http://en.wikipedia.org/wiki/Distributed_Component_Object_Model] or '''Object Request Brokers''' (ORBs) [http://en.wikipedia.org/wiki/Object_request_broker] which are based on the '''CORBA'''[http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture] specification.These are the first service-oriented architectures deployed for practical applications. The following section gives a brief description about the evolution of SOA: 

== Evolution of SOA ==

In many respects, SOA is an evolution based on the '''component-based development''' (CBD). It, in fact, is a quantum leap in bringing business and information technology into closer alignment by supporting business processes. The SOA services are made visible to the consumer, but, the underlying components are kept transparent. 

The Internet and XML standardization efforts demanded a service definition and description published by a service provider (SP) that could be located and invoked by a service consumer (SC). The service description can be implemented by different service providers, each offering various choices of qualities of service (QoS). The invocation can be across Internet or intranet in a distributed object connotation and standards such as '''WSDL'''[http://en.wikipedia.org/wiki/Web_Services_Description_Language] and '''SOAP'''[http://en.wikipedia.org/wiki/SOAP] have been created.

The roles of SC and SP are illustrated in the following figure: 

[[Image:Scsp.jpg|frame|center|Figure 1: Service Provider and Service Consumer in a SOA]]

== Terminologies ==

=== Services ===

A '''service''' is a specific function (business function). For instance, analyzing an individual's credit history or processing a purchase order. It can either provide a single discrete function, such as converting one type of currency into another, or it can perform a set of related business functions, such as handling the various operations in an airline reservations system. Services performing a related set of business functions are said to be '''coarse grained'''. Multiple services work in a coordinated way. This aggregated service can be used for a more complex business requirement.

=== Connections ===

'''''Web services''''' is the most likely connection technology of SOAs. Web services essentially use XML to create a robust connection. A web service can be defined as a service that communicates with clients through a set of standard protocols and technologies. These are standardized and are implemented in platforms and products from various vendors, giving clients and services an opportunity to communicate in a consistent way across a wide spectrum of platforms and operating environments.

'' The important concept is service. Web Services are the set of protocols by which Services are discovered, published and put to use in a technology neutral, standard form. ''

=== Service Oriented Architecture ===

Often is the case that one person's needs being met by capabilities offered by someone else. In the world of distributed computing, this scenario can be thought of one computer agent’s requirements being met by a computer agent belonging to a different owner. A one-to-one correlation is not not necessarily needed between these needs and capabilities.

SOA is a ''view'' of architecture focusing on services as the action boundaries between the needs and capabilities in order to service discovery and re-purposing. Thus, Service Oriented Architecture (SOA) can be defined as a paradigm for organizing and utilizing distributed capabilities that may be in different ownership domains and implemented using various technology stacks.

'' SOA is not only an architecture of services (seen from a technology perspective). It includes the policies, practices, and frameworks to ensure the right services are provided and consumed.''

 

= Example =

This example depicts how an information system scenario could benefit from a migration to SOA. Consider an organization that has an application using three business processes using the same functionality. 

[[Image:Exampless1.jpg|frame|center|Figure 2: Three business processes within one company duplicating functionality ]]

 
The main disadvantages in the above scenario are:
* The company pays to implement the same functionality multiple times.
* Maintainence issues : Consider the situation wherein, a manager wants to deny a user access to all three processes.This requires three different procedures (one for each of the applications).

This system can be made efficient if common tasks are shared across all three processes. This requires decoupling the functionality from each process or application and making a standalone authentication and user management application that could be accessed as a service. Thus, the service itself is being repurposed, and, applications and the company owning it can now have a central point for maintaining it. This shows a simple example of Service Oriented Architecture in practice. The following diagram depicts the same: 

[[Image:Exampless2.jpg|frame|center|Figure 3: Three business processes repurposing one service for common tasks ]]

 

= Discussion =

== Benefits of SOA ==

The following are the primary reasons which encourages an enterprise to take SOA approach:

* '''Reusability''': SOA allows reuse of business services by enabling developers within an enterprise and/or across enterprises to take the code developed for existing business applications, convert them as web services, and then reuse it to meet new business requirements. This results in huge savings in the cost and time for application development. The more business services get built and get incorporated into different applications, the more are the benefits of reuse.

* '''Interoperability''': One of the main objectives of SOA is to allow clients and services to communicate and understand each other independent of the platform they use. This objective is met when clients and services have a standard and consistent way of communicating with each other. Web services are used for this purpose.

* '''Scalability''': SOA stresses on having few dependencies between the requesting application and the services it uses. Thus, services tend to be coarse-grained, document-oriented, and asynchronous. Coarse-grained services have the advantage of offering a set of related business functions, a document-oriented service accepts a document as input instead of a numeric value or Java object and an asynchronous service doesn't require the client to wait while it performs its processing. This relatively limited interaction from a client for communicating with a coarse-grained, asynchronous service, provides the scope for applications using these services to scale without increasing the communication load on the network.

* '''Flexibility''': SOA discourages sharing semantics, libraries, and often sharing state. This makes it easier for the application to evolve and keep up with changing business requirements.

* '''Cost Efficiency''': As SOA is a standards-based approach, it results in less costly solutions since the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because ervices ins an SOA are less costly to maintain and easier to extend. Also many enterprises have a lot of the Web-based infrastructure for a web services-based SOA, further limiting the cost. The biggest cost saving of all comes from the reusability feature of SOA.

*'''Agility''': Services can now be delivered quickly and need not depend on the larger projects common in the organization. The business can understand systems and requires simpler user interfaces calling on services. This in turn, speeds up the time-to-market.

* Promotes good design as the service is designed independent of who its consumers are or will be.

* Eases documentation and testing by separating them from the issues of the implementation. 

It should be noted that SOA doesn't provide the bebefits mentioned below:

* Simple software engineering

* Free integration or interoperability

* Technology independence

* Vendor independence

* The ultimate architecture for the modern enterprise
 

== Challenges ==

* Maintaining '''metadata''' related to the services is difficult as each service involves various messages used in communicating and an application can involve many such services, generating a huge number of messages. Also, services are delivered by different organizations within the company or different companies and this needs ''SOA Governance''.

* SOA space lacks testing. This indicates that investment is required in a testing framework that would help find the culprit in the architecture.

* As more services get added for extensibility of the system, security models might require changes. Coming up with appropriate levels of security is a concern.

* SOA with Web Services result in addition of XML layers, requiring XML parsing and composition. Applications run slower and require more processing power when used without '''Remote Procedure Calls'''(RPC) [http://en.wikipedia.org/wiki/Remote_procedure_call] and thus, increase costs. 

 
== SOA Principles ==

There is a set of 10 principles for SOA. The first four are based on Don Box's '''four tenets'''. These principles are as listed below:

* '''Explicit boundaries''': ''Services are inextricably tied to messaging in that the only way into and out of a service are through messages''. This means that everything a service would require for its functionality should be passed to it when it is invoked.

* '''Shared Contract and Schema, not Class''': The service consumer and a service provider involved in the contract should have everything they need to consume or provide the service and should not rely upon each other for any kind of reuse.

* '''Policy- Driven''': Since a service can be accessed from various consumers, a policy mechanism is needed. The functional aspects are described in the service interface, and, policies specify the orthogonal, non-functional capabilities and needs.

* '''Autonomous''': It should be possible to change and deploy, version and manage services independent of each other. The consumers need not quickly adapt to the new version.

* '''Wire Formats''': A service must be accessible independent of the platform, as long as the platform supports the exchange of messages adhering to the service interface and policies.

* '''Document-Oriented''': Documents are used to send data to interact with services. These documents might contain redundant information.

* '''Loosely-Coupled''': As far as possible, components must be loosely coupled which enables extensibility, easier maintainence and a better system. But it is not always possible.

* '''Standard-complaint''': Standards for technical aspects like data formats, metadata, transport and transfer protocols etc, must be followed.

* '''Vendor Independent''': It should be possible to build a service provider or service consumer using any technology supporting the appropriate standards.

* '''Metadata - Driven''': The metadata artifacts in the SOA should be discoverable, retrievable and interpretable at both design and run time.
 

= Design Patterns in SOA =

''Design Patterns'' describe common problems with their solutions that can be applied repeatedly under a set of constraints. The collection of SOA design patterns forms a master pattern language applicable in various combination and sequences. Compound patterns comprising of multiple individual patterns is also possible. SOA has a huge number of design patterns which can be divided into the following categories: 

* Foundational Inventory Patterns
* Logical Inventory Layer Patterns
* Inventory Centralization Patterns
* Inventory Implementation Patterns
* Inventory Governance Patterns
* Foundational Service Patterns
* Service Implementation Patterns
* Service Security Patterns
* Service Contract Design Patterns
* Legacy Encapsulation Patterns
* Service Governance Patterns
* Capability Composition Patterns
* Service Messaging Patterns
* Composition Implementation Patterns
* Service Interaction Security Patterns
* Transformation Patterns
* Common Compound Design Patterns 

A more elaborate list and description of these patterns is available at SOA website[http://soapatterns.org/masterlist_c.php]. 

As it can be seen, the SOA design pattern catalog is very broad. These patterns provide design techniques ranging from adjusting minute validation logic in a service contract to design strategies and help structure pools of services across an entire enterprise. An SOA initiative
requires attention to the various design details associated with every service delivered, while not loosing the big picture. Design patterns help maintaining this balance by helping overcome common obstacles that have historically inhibited or derailed SOA project plans.

== Working with SOA patterns ==

Here are a few guidelines for utilizing the SOA design patterns to their maximum extent:

* Patterns should be viewed with a Strategic Context
* Governance has to be considered
* Patterns can be applied to various extents
* Some patterns can be evolutionary
* Patterns can relate to other patterns
* Every pattern is not suitable for everyone
 

= Coupling in SOA =

'''Coupling''' specifies the degree of dependency between 2 or more modules. As we know, coupling can be classified as '''Loose Coupling''' and ''' Tight Coupling'''. Loose coupling can be defined as ''the state in which the impact of change (change in consumers, providers, or cross-cutting policies) is minimized across dependencies''. Loose coupling is important across units of deployment, whereas tight coupling is sufficient within a unit of deployment.

The essence of SOA is building composite distributed systems efficiently. In order for the distributed components to be reusable, reliable, available, scalable and fault tolerant, an appropriate level of loose coupling is needed. The impact of any change or modification and failures should be minimum on the landscape of a system as a whole. Loose coupling provides this property by defining and describing interaction patterns between components and technologies involved. Loose coupling also brings the advantage of '''versionability''' in SOA. If A and B depend on each other, loose coupling is needed only when A may version independently from B. That is, if A and B are versioned together, loose coupling between them is unnecessary.

Services in SOA require described interfaces. This provides a measure of loose coupling as the service dependency isn't a software to software dependency; rather it is N software to interface dependencies. This shows the importance of individual interface contracts. If an interface contract allows anything, then it has tight coupling between components.

There is no one way to build useful distributed systems that are completely decoupled, rather a variety of choices have to be considered based on various aspects of the systems. A property of a system can become a trade-off compared to other properties. For example, an asynchronous service usually requires the client open up its address space for a "callback" which increases the coupling. Also, loosely couple Web Services wait for messages via queuing mechanism before taking action. A large number of such services would be required to exceed the system load. So, tight coupling them can be considered. New mechanisms to switch loosely coupled Web Services to tightly coupled Web Services to avoid system overloads of scarce resources are being considered.

In summary, Loose coupling manifests itself in the SOA paradigm as follows:

* Creates an abstraction layer between the service producers and service consumers.
* Promotes flexibility in making changes to the service implementation without impacting the service consumers.
* In the SOA approach, functionality is organized as a set of modular, reusable shared services that have well-defined interfaces and encapsulate the key rules for accessing the services. They're also built without making any assumptions of who will use or consume these services.
 

= Cohesion in SOA =
'''Cohesion''' is defined as the measure of the relationship between the functionality expressed aby a module and the module itself. It is contrasted with the concept of '''coupling'''. High cohesion correlates to loose coupling.

Cohesion can be classified into various types. Below mentioned are the three "good" types of cohesion identified over the years:

* '''Functional Cohesion''': An individual module does only one thing, resulting in low coupling and reusability.
* '''Sequential Cohesion''': A module carries out several ordered tasks.
* '''Communication Cohesion''': A module carries out multiple operations based on the same input and lacks any prescribed ordering requirements.

The following are identified forms of "bad" cohesion:

* '''Procedural Cohesion''': This is similar to Sequential Cohesion with different data to work on for each task.
* '''Temporal Cohesion''': A module's tasks are related only by time.
* '''Logical Cohesion''': Modules sharing common implementations are grouped.
* '''Coincidental Cohesion''': A module's tasks are related only when residing in the same module.

In today's vernacular, low cohesion is termed as ''coarse-grained''. "Buy a car" and "run credit history" are examples of two such coarse-grained services offered in an SOA. SOA's success requires adopting "course-grained" services that can be plug-n-played with other sources interchangeably. But it is very much possible that within coarse-grained services, such as buy a car, there may be smaller or finer-grained services like Check Inventory, Schedule Detailing, etc. that make up the larger service, buy a car. Thus SOA and high cohesion as a principle aren't incongruent with each other. High cohesion is rather the foundation of creating coarse-grained services which is the fundamental element of creating a successful SOA implementation.

 

= Enterprise Architecture Vs SOA =

An enterprise architecture (EA) is defined as a conceptual blueprint defining the structure and operation of an organization. The enterprise architecture determines how an organization can achieves its current and future objectives effectively. An enterprise architecture has the following four perspectives:

* '''Business perspective''': This defines the processes and standards used by the business on a day-to-day basis.
* '''Application perspective''': This defines the interactions among the processes and standards used by the organization.
* '''Information perspective''': This defines and classifies the raw data (such as document files), that the organization requires.
* '''Technology perspective''': This defines the hardware, operating systems, programming, and networking solutions used by the organization.

Such an EA offers the following benefits:

* Better decision making.
* Organizations can adapt better to changing demands or market conditions.
* Eliminates inefficient and redundant processes.
* Optimizes the use of organizational assets.
* Minimizes employee turnover.

Both SOA and EA are used for the benefit of the organization. These two concepts are often confused. The following section discusses how these two concepts are similar, and how they differ.

== Similarities and Differences between SOA and EA ==

The different domains in SOA and EA architecture overlap. But the domains in SOA are a subset of that of EA. For instance, SOA models and develops services and the components that realize them, while the EA architecture deals with SOA-specific artifacts along with other components, packages, and systems for the whole enterprise. The following table shows the mapping between the architecture domains of SOA and EA:

{|cellspacing="0" border="2" style="color:black; background-color:LightGrey;"
!style="width:25%"|ARCHITECTURE DOMAIN
!style="width:25%"|SOA STACK
!style="width:25%"|EA FRAMEWORK
|-
|Business
|Business process
|Business architecture
|-
|Applications
|Services and components
|Appliaction architecture
|-
|Operations
|Quality of Service, security, monitoring, and infrastructure
|Technology architecture
|-
|Data
|Data architecture
|Information architecture
|-
|Integration and Middleware
|Integration architecture / ESB
|Technology architecture
|-

|} 

The following are the similarities between SOA and EA:
* Both address similar architectural domains.
* Both intend to align IT closely with business.
* Both require input based on business objectives.
* Both involve similar strategies and planning activities. 

While EA architecture domains focuses on the macro level, the SOA architecture domains work on a micro level. To be specific,

* EA tends to focus on defining business components, while SOA focuses on business services.
* EA deals with application frameworks and enterprise applications and SOA with only service modeling.
* EA deals with enterprise-level infrastructure including servers, databases, etc. while SOA is for the Enterprise Service Bus.
* EA addresses enterprise integration patterns and when they should be used. SOA provides a services based integration approach.
 

== Role of SOA in EA ==

As we can see from the above section, though both SOA and EA serve the same purpose, SOA is not same as EA. Instead, SOA can play a role in most of the domains/perspectives of an EA. SOA is one of the best tools for the success of EA projects. SOA bridges EA with the solution architecture and implementation by using layered service components across business and application models, and technology implementation.

SOA helps EA to overcome its challenges. Some of these challenges are as listed below:
* Reduced stakeholder participation.
* Modeling the Big picture.
* Producing meaningful models and conceptual abstractions.
* Difficulties in EA management life cycle and governance.

Thus, for the smooth and efficient working of an EA, SOA should be an integral part of the EA. Service Oriented Enterprise, Service Oriented Applications/Systems and Service Oriented Infrastructure are a few examples of how SOA can be adopted in an EA.

 

= Conclusion =

To sum up, SOA is an architectural style and modeling approach that emphasizes on well-defined, loosely-coupled, reusable and shareable services. Its also a practical modeling approach that suits enterprise architecture development very well. It has its criticisms but its benefits far outweigh those.

CSC/ECE 517 Fall 2010/ch6 6j ss

2010-11-18T00:13:09Z

Marashid:

CSC/ECE 517 Fall 2010/ch6 6j ss

2010-11-18T00:12:39Z

Marashid:

'''Service-Oriented Architecture'''

A few years ago, it was realized that eventually software capabilities are going to be delivered and consumed as services. Implementing them as tightly coupled systems was definitely an option, but, a service-based interface was required between the point of usage to the portal, device or another end-point. Thus, there was the need of a service-oriented architecture that would facilitate the management of delivery, acquisition, consumption etc in terms of services that are related. This hinted at changes in how software life cycle is managed —right from requirements specifications as services, designing these services, acquisition and outsourcing in the form of services, asset management of services, and so on. Thus, after moving from modules to objects, to components, now was the time to move to services.

This wiki chapter aims at providing an introduction to the vast and growing field of '''''Service Oriented Architecture'''''. The chapter also discusses the different '''design patterns'''[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29] currently in practice for the field of Service-Oriented Architecture. The utilization of the concepts of '''coupling'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29] and '''cohesion'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29] in Service-Oriented Architecture are described. SOA is contrasted with a similar concept called Enterprise Architecture.

= Introduction =

Service-oriented architecture (SOA) is a collection or set of services communicating with each other. Two or more services can communicate either via a simple data passing system or could be coordinating on some activity. For these kind of communications to be possible between the services, some means to connect the various services is required. 

Service-oriented architectures were existing in the past and are not a new thing. Many people are familiar with the use of '''DCOM''' [http://en.wikipedia.org/wiki/Distributed_Component_Object_Model] or '''Object Request Brokers''' (ORBs) [http://en.wikipedia.org/wiki/Object_request_broker] which are based on the '''CORBA'''[http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture] specification.These are the first service-oriented architectures deployed for practical applications. The following section gives a brief description about the evolution of SOA: 

== Evolution of SOA ==

In many respects, SOA is an evolution based on the '''component-based development''' (CBD). It, in fact, is a quantum leap in bringing business and information technology into closer alignment by supporting business processes. The SOA services are made visible to the consumer, but, the underlying components are kept transparent. 

The Internet and XML standardization efforts demanded a service definition and description published by a service provider (SP) that could be located and invoked by a service consumer (SC). The service description can be implemented by different service providers, each offering various choices of qualities of service (QoS). The invocation can be across Internet or intranet in a distributed object connotation and standards such as '''WSDL'''[http://en.wikipedia.org/wiki/Web_Services_Description_Language] and '''SOAP'''[http://en.wikipedia.org/wiki/SOAP] have been created.

The roles of SC and SP are illustrated in the following figure: 

[[Image:Scsp.jpg|frame|center|Figure 1: Service Provider and Service Consumer in a SOA]]

== Terminologies ==

=== Services ===

A '''service''' is a specific function (business function). For instance, analyzing an individual's credit history or processing a purchase order. It can either provide a single discrete function, such as converting one type of currency into another, or it can perform a set of related business functions, such as handling the various operations in an airline reservations system. Services performing a related set of business functions are said to be '''coarse grained'''. Multiple services work in a coordinated way. This aggregated service can be used for a more complex business requirement.

=== Connections ===

'''''Web services''''' is the most likely connection technology of SOAs. Web services essentially use XML to create a robust connection. A web service can be defined as a service that communicates with clients through a set of standard protocols and technologies. These are standardized and are implemented in platforms and products from various vendors, giving clients and services an opportunity to communicate in a consistent way across a wide spectrum of platforms and operating environments.

'' The important concept is service. Web Services are the set of protocols by which Services are discovered, published and put to use in a technology neutral, standard form. ''

=== Service Oriented Architecture ===

Often is the case that one person's needs being met by capabilities offered by someone else. In the world of distributed computing, this scenario can be thought of one computer agent’s requirements being met by a computer agent belonging to a different owner. A one-to-one correlation is not not necessarily needed between these needs and capabilities.

SOA is a ''view'' of architecture focusing on services as the action boundaries between the needs and capabilities in order to service discovery and re-purposing. Thus, Service Oriented Architecture (SOA) can be defined as a paradigm for organizing and utilizing distributed capabilities that may be in different ownership domains and implemented using various technology stacks.

'' SOA is not only an architecture of services (seen from a technology perspective). It includes the policies, practices, and frameworks to ensure the right services are provided and consumed.''

 

= Example =

This example depicts how an information system scenario could benefit from a migration to SOA. Consider an organization that has an application using three business processes using the same functionality. 

[[Image:Exampless1.jpg|frame|center|Figure 2: Three business processes within one company duplicating functionality ]]

 
The main disadvantages in the above scenario are:
* The company pays to implement the same functionality multiple times.
* Maintainence issues : Consider the situation wherein, a manager wants to deny a user access to all three processes.This requires three different procedures (one for each of the applications).

This system can be made efficient if common tasks are shared across all three processes. This requires decoupling the functionality from each process or application and making a standalone authentication and user management application that could be accessed as a service. Thus, the service itself is being repurposed, and, applications and the company owning it can now have a central point for maintaining it. This shows a simple example of Service Oriented Architecture in practice. The following diagram depicts the same: 

[[Image:Exampless2.jpg|frame|center|Figure 3: Three business processes repurposing one service for common tasks ]]

 

= Discussion =

== Benefits of SOA ==

The following are the primary reasons which encourages an enterprise to take SOA approach:

* '''Reusability''': SOA allows reuse of business services by enabling developers within an enterprise and/or across enterprises to take the code developed for existing business applications, convert them as web services, and then reuse it to meet new business requirements. This results in huge savings in the cost and time for application development. The more business services get built and get incorporated into different applications, the more are the benefits of reuse.

* '''Interoperability''': One of the main objectives of SOA is to allow clients and services to communicate and understand each other independent of the platform they use. This objective is met when clients and services have a standard and consistent way of communicating with each other. Web services are used for this purpose.

* '''Scalability''': SOA stresses on having few dependencies between the requesting application and the services it uses. Thus, services tend to be coarse-grained, document-oriented, and asynchronous. Coarse-grained services have the advantage of offering a set of related business functions, a document-oriented service accepts a document as input instead of a numeric value or Java object and an asynchronous service doesn't require the client to wait while it performs its processing. This relatively limited interaction from a client for communicating with a coarse-grained, asynchronous service, provides the scope for applications using these services to scale without increasing the communication load on the network.

* '''Flexibility''': SOA discourages sharing semantics, libraries, and often sharing state. This makes it easier for the application to evolve and keep up with changing business requirements.

* '''Cost Efficiency''': As SOA is a standards-based approach, it results in less costly solutions since the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because ervices ins an SOA are less costly to maintain and easier to extend. Also many enterprises have a lot of the Web-based infrastructure for a web services-based SOA, further limiting the cost. The biggest cost saving of all comes from the reusability feature of SOA.

*'''Agility''': Services can now be delivered quickly and need not depend on the larger projects common in the organization. The business can understand systems and requires simpler user interfaces calling on services. This in turn, speeds up the time-to-market.

* Promotes good design as the service is designed independent of who its consumers are or will be.

* Eases documentation and testing by separating them from the issues of the implementation. 

It should be noted that SOA doesn't provide the bebefits mentioned below:

* Simple software engineering

* Free integration or interoperability

* Technology independence

* Vendor independence

* The ultimate architecture for the modern enterprise
 

== Challenges ==

* Maintaining '''metadata''' related to the services is difficult as each service involves various messages used in communicating and an application can involve many such services, generating a huge number of messages. Also, services are delivered by different organizations within the company or different companies and this needs ''SOA Governance''.

* SOA space lacks testing. This indicates that investment is required in a testing framework that would help find the culprit in the architecture.

* As more services get added for extensibility of the system, security models might require changes. Coming up with appropriate levels of security is a concern.

* SOA with Web Services result in addition of XML layers, requiring XML parsing and composition. Applications run slower and require more processing power when used without '''Remote Procedure Calls'''(RPC) [http://en.wikipedia.org/wiki/Remote_procedure_call] and thus, increase costs. 

 
== SOA Principles ==

There is a set of 10 principles for SOA. The first four are based on Don Box's '''four tenets'''. These principles are as listed below:

* '''Explicit boundaries''': ''Services are inextricably tied to messaging in that the only way into and out of a service are through messages''. This means that everything a service would require for its functionality should be passed to it when it is invoked.

* '''Shared Contract and Schema, not Class''': The service consumer and a service provider involved in the contract should have everything they need to consume or provide the service and should not rely upon each other for any kind of reuse.

* '''Policy- Driven''': Since a service can be accessed from various consumers, a policy mechanism is needed. The functional aspects are described in the service interface, and, policies specify the orthogonal, non-functional capabilities and needs.

* '''Autonomous''': It should be possible to change and deploy, version and manage services independent of each other. The consumers need not quickly adapt to the new version.

* '''Wire Formats''': A service must be accessible independent of the platform, as long as the platform supports the exchange of messages adhering to the service interface and policies.

* '''Document-Oriented''': Documents are used to send data to interact with services. These documents might contain redundant information.

* '''Loosely-Coupled''': As far as possible, components must be loosely coupled which enables extensibility, easier maintainence and a better system. But it is not always possible.

* '''Standard-complaint''': Standards for technical aspects like data formats, metadata, transport and transfer protocols etc, must be followed.

* '''Vendor Independent''': It should be possible to build a service provider or service consumer using any technology supporting the appropriate standards.

* '''Metadata - Driven''': The metadata artifacts in the SOA should be discoverable, retrievable and interpretable at both design and run time.
 

= Design Patterns in SOA =

''Design Patterns'' describe common problems with their solutions that can be applied repeatedly under a set of constraints. The collection of SOA design patterns forms a master pattern language applicable in various combination and sequences. Compound patterns comprising of multiple individual patterns is also possible. SOA has a huge number of design patterns which can be divided into the following categories: 

* Foundational Inventory Patterns
* Logical Inventory Layer Patterns
* Inventory Centralization Patterns
* Inventory Implementation Patterns
* Inventory Governance Patterns
* Foundational Service Patterns
* Service Implementation Patterns
* Service Security Patterns
* Service Contract Design Patterns
* Legacy Encapsulation Patterns
* Service Governance Patterns
* Capability Composition Patterns
* Service Messaging Patterns
* Composition Implementation Patterns
* Service Interaction Security Patterns
* Transformation Patterns
* Common Compound Design Patterns 

A more elaborate list and description of these patterns is available at SOA website[http://soapatterns.org/masterlist_c.php]. 

As it can be seen, the SOA design pattern catalog is very broad. These patterns provide design techniques ranging from adjusting minute validation logic in a service contract to design strategies and help structure pools of services across an entire enterprise. An SOA initiative
requires attention to the various design details associated with every service delivered, while not loosing the big picture. Design patterns help maintaining this balance by helping overcome common obstacles that have historically inhibited or derailed SOA project plans.

== Working with SOA patterns ==

Here are a few guidelines for utilizing the SOA design patterns to their maximum extent:

* Patterns should be viewed with a Strategic Context
* Governance has to be considered
* Patterns can be applied to various extents
* Some patterns can be evolutionary
* Patterns can relate to other patterns
* Every pattern is not suitable for everyone
 

= Coupling in SOA =

'''Coupling''' specifies the degree of dependency between 2 or more modules. As we know, coupling can be classified as '''Loose Coupling''' and ''' Tight Coupling'''. Loose coupling can be defined as ''the state in which the impact of change (change in consumers, providers, or cross-cutting policies) is minimized across dependencies''. Loose coupling is important across units of deployment, whereas tight coupling is sufficient within a unit of deployment.

The essence of SOA is building composite distributed systems efficiently. In order for the distributed components to be reusable, reliable, available, scalable and fault tolerant, an appropriate level of loose coupling is needed. The impact of any change or modification and failures should be minimum on the landscape of a system as a whole. Loose coupling provides this property by defining and describing interaction patterns between components and technologies involved. Loose coupling also brings the advantage of '''versionability''' in SOA. If A and B depend on each other, loose coupling is needed only when A may version independently from B. That is, if A and B are versioned together, loose coupling between them is unnecessary.

Services in SOA require described interfaces. This provides a measure of loose coupling as the service dependency isn't a software to software dependency; rather it is N software to interface dependencies. This shows the importance of individual interface contracts. If an interface contract allows anything, then it has tight coupling between components.

There is no one way to build useful distributed systems that are completely decoupled, rather a variety of choices have to be considered based on various aspects of the systems. A property of a system can become a trade-off compared to other properties. For example, an asynchronous service usually requires the client open up its address space for a "callback" which increases the coupling. Also, loosely couple Web Services wait for messages via queuing mechanism before taking action. A large number of such services would be required to exceed the system load. So, tight coupling them can be considered. New mechanisms to switch loosely coupled Web Services to tightly coupled Web Services to avoid system overloads of scarce resources are being considered.

In summary, Loose coupling manifests itself in the SOA paradigm as follows:

* Creates an abstraction layer between the service producers and service consumers.
* Promotes flexibility in making changes to the service implementation without impacting the service consumers.
* In the SOA approach, functionality is organized as a set of modular, reusable shared services that have well-defined interfaces and encapsulate the key rules for accessing the services. They're also built without making any assumptions of who will use or consume these services.
 

= Cohesion in SOA =
'''Cohesion''' is defined as the measure of the relationship between the functionality expressed aby a module and the module itself. It is contrasted with the concept of '''coupling'''. High cohesion correlates to loose coupling.

Cohesion can be classified into various types. Below mentioned are the three "good" types of cohesion identified over the years:

* '''Functional Cohesion''': An individual module does only one thing, resulting in low coupling and reusability.
* '''Sequential Cohesion''': A module carries out several ordered tasks.
* '''Communication Cohesion''': A module carries out multiple operations based on the same input and lacks any prescribed ordering requirements.

The following are identified forms of "bad" cohesion:

* '''Procedural Cohesion''': This is similar to Sequential Cohesion with different data to work on for each task.
* '''Temporal Cohesion''': A module's tasks are related only by time.
* '''Logical Cohesion''': Modules sharing common implementations are grouped.
* '''Coincidental Cohesion''': A module's tasks are related only when residing in the same module.

In today's vernacular, low cohesion is termed as ''coarse-grained''. "Buy a car" and "run credit history" are examples of two such coarse-grained services offered in an SOA. SOA's success requires adopting "course-grained" services that can be plug-n-played with other sources interchangeably. But it is very much possible that within coarse-grained services, such as buy a car, there may be smaller or finer-grained services like Check Inventory, Schedule Detailing, etc. that make up the larger service, buy a car. Thus SOA and high cohesion as a principle aren't incongruent with each other. High cohesion is rather the foundation of creating coarse-grained services which is the fundamental element of creating a successful SOA implementation.

 

= Enterprise Architecture Vs SOA =

An enterprise architecture (EA) is defined as a conceptual blueprint defining the structure and operation of an organization. The enterprise architecture determines how an organization can achieves its current and future objectives effectively. An enterprise architecture has the following four perspectives:

* '''Business perspective''': This defines the processes and standards used by the business on a day-to-day basis.
* '''Application perspective''': This defines the interactions among the processes and standards used by the organization.
* '''Information perspective''': This defines and classifies the raw data (such as document files), that the organization requires.
* '''Technology perspective''': This defines the hardware, operating systems, programming, and networking solutions used by the organization.

Such an EA offers the following benefits:

* Better decision making.
* Organizations can adapt better to changing demands or market conditions.
* Eliminates inefficient and redundant processes.
* Optimizes the use of organizational assets.
* Minimizes employee turnover.

Both SOA and EA are used for the benefit of the organization. These two concepts are often confused. The following section discusses how these two concepts are similar, and how they differ.

== Similarities and Differences between SOA and EA ==

The different domains in SOA and EA architecture overlap. But the domains in SOA are a subset of that of EA. For instance, SOA models and develops services and the components that realize them, while the EA architecture deals with SOA-specific artifacts along with other components, packages, and systems for the whole enterprise. The following table shows the mapping between the architecture domains of SOA and EA:

{|cellspacing="0" border="2" style="color:black; background-color:LightGrey;"
!style="width:25%"|ARCHITECTURE DOMAIN
!style="width:25%"|SOA STACK
!style="width:25%"|EA FRAMEWORK
|-
|Business
|Business process
|Business architecture
|-
|Applications
|Services and components
|Appliaction architecture
|-
|Operations
|Quality of Service, security, monitoring, and infrastructure
|Technology architecture
|-
|Data
|Data architecture
|Information architecture
|-
|Integration and Middleware
|Integration architecture / ESB
|Technology architecture
|-

|} 

The following are the similarities between SOA and EA:
* Both address similar architectural domains.
* Both intend to align IT closely with business.
* Both require input based on business objectives.
* Both involve similar strategies and planning activities. 

While EA architecture domains focuses on the macro level, the SOA architecture domains work on a micro level. To be specific,

* EA tends to focus on defining business components, while SOA focuses on business services.
* EA deals with application frameworks and enterprise applications and SOA with only service modeling.
* EA deals with enterprise-level infrastructure including servers, databases, etc. while SOA is for the Enterprise Service Bus.
* EA addresses enterprise integration patterns and when they should be used. SOA provides a services based integration approach.
 

== Role of SOA in EA ==

As we can see from the above section, though both SOA and EA serve the same purpose, SOA is not same as EA. Instead, SOA can play a role in most of the domains/perspectives of an EA. SOA is one of the best tools for the success of EA projects. SOA bridges EA with the solution architecture and implementation by using layered service components across business and application models, and technology implementation.

SOA helps EA to overcome its challenges. Some of these challenges are as listed below:
* Reduced stakeholder participation.
* Modeling the Big picture.
* Producing meaningful models and conceptual abstractions.
* Difficulties in EA management life cycle and governance.

Thus, for the smooth and efficient working of an EA, SOA should be an integral part of the EA. Service Oriented Enterprise, Service Oriented Applications/Systems and Service Oriented Infrastructure are a few examples of how SOA can be adopted in an EA.

 

== Conclusion ==

To sum up, SOA is an architectural style and modeling approach that emphasizes on well-defined, loosely-coupled, reusable and shareable services. Its also a practical modeling approach that suits enterprise architecture development very well.

CSC/ECE 517 Fall 2010/ch6 6j ss

2010-11-17T22:13:47Z

Marashid:

'''Service-Oriented Architecture'''

A few years ago, it was realized that eventually software capabilities are going to be delivered and consumed as services. Implementing them as tightly coupled systems was definitely an option, but, a service-based interface was required between the point of usage to the portal, device or another end-point. Thus, there was the need of a service-oriented architecture that would facilitate the management of delivery, acquisition, consumption etc in terms of services that are related. This hinted at changes in how software life cycle is managed —right from requirements specifications as services, designing these services, acquisition and outsourcing in the form of services, asset management of services, and so on. Thus, after moving from modules to objects, to components, now was the time to move to services.

This wiki chapter aims at providing an introduction to the vast and growing field of '''''Service Oriented Architecture'''''. The chapter also discusses the different '''design patterns'''[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29] currently in practice for the field of Service-Oriented Architecture. The utilization of the concepts of '''coupling'''[http://en.wikipedia.org/wiki/Coupling_%28computer_science%29] and '''cohesion'''[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29] in Service-Oriented Architecture are described.

= Introduction =

Service-oriented architecture (SOA) is a collection or set of services communicating with each other. Two or more services can communicate either via a simple data passing system or could be coordinating on some activity. For these kind of communications to be possible between the services, some means to connect the various services is required. 

Service-oriented architectures were existing in the past and are not a new thing. Many people are familiar with the use of '''DCOM''' [http://en.wikipedia.org/wiki/Distributed_Component_Object_Model] or '''Object Request Brokers''' (ORBs) [http://en.wikipedia.org/wiki/Object_request_broker] which are based on the '''CORBA'''[http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture] specification.These are the first service-oriented architectures deployed for practical applications. The following section gives a brief description about the evolution of SOA: 

== Evolution of SOA ==

In many respects, SOA is an evolution based on the '''component-based development''' (CBD). It, in fact, is a quantum leap in bringing business and information technology into closer alignment by supporting business processes. The SOA services are made visible to the consumer, but, the underlying components are kept transparent. 

The Internet and XML standardization efforts demanded a service definition and description published by a service provider (SP) that could be located and invoked by a service consumer (SC). The service description can be implemented by different service providers, each offering various choices of qualities of service (QoS). The invocation can be across Internet or intranet in a distributed object connotation and standards such as '''WSDL'''[http://en.wikipedia.org/wiki/Web_Services_Description_Language] and '''SOAP'''[http://en.wikipedia.org/wiki/SOAP] have been created.

The roles of SC and SP are illustrated in the following figure: 

[[Image:Scsp.jpg|frame|center|Figure 1: Service Provider and Service Consumer in a SOA]]

== Terminologies ==

=== Services ===

A '''service''' is a specific function (business function). For instance, analyzing an individual's credit history or processing a purchase order. It can either provide a single discrete function, such as converting one type of currency into another, or it can perform a set of related business functions, such as handling the various operations in an airline reservations system. Services performing a related set of business functions are said to be '''coarse grained'''. Multiple services work in a coordinated way. This aggregated service can be used for a more complex business requirement.

=== Connections ===

'''''Web services''''' is the most likely connection technology of SOAs. Web services essentially use XML to create a robust connection. A web service can be defined as a service that communicates with clients through a set of standard protocols and technologies. These are standardized and are implemented in platforms and products from various vendors, giving clients and services an opportunity to communicate in a consistent way across a wide spectrum of platforms and operating environments.

'' The important concept is service. Web Services are the set of protocols by which Services are discovered, published and put to use in a technology neutral, standard form. ''

=== Service Oriented Architecture ===

Often is the case that one person's needs being met by capabilities offered by someone else. In the world of distributed computing, this scenario can be thought of one computer agent’s requirements being met by a computer agent belonging to a different owner. A one-to-one correlation is not not necessarily needed between these needs and capabilities.

SOA is a ''view'' of architecture focusing on services as the action boundaries between the needs and capabilities in order to service discovery and re-purposing. Thus, Service Oriented Architecture (SOA) can be defined as a paradigm for organizing and utilizing distributed capabilities that may be in different ownership domains and implemented using various technology stacks.

'' SOA is not only an architecture of services (seen from a technology perspective). It includes the policies, practices, and frameworks to ensure the right services are provided and consumed.''

 

= Example =

This example depicts how an information system scenario could benefit from a migration to SOA. Consider an organization that has an application using three business processes using the same functionality. 

[[Image:Exampless1.jpg|frame|center|Figure 2: Three business processes within one company duplicating functionality ]]

 
The main disadvantages in the above scenario are:
* The company pays to implement the same functionality multiple times.
* Maintainence issues : Consider the situation wherein, a manager wants to deny a user access to all three processes.This requires three different procedures (one for each of the applications).

This system can be made efficient if common tasks are shared across all three processes. This requires decoupling the functionality from each process or application and making a standalone authentication and user management application that could be accessed as a service. Thus, the service itself is being repurposed, and, applications and the company owning it can now have a central point for maintaining it. This shows a simple example of Service Oriented Architecture in practice. The following diagram depicts the same: 

[[Image:Exampless2.jpg|frame|center|Figure 3: Three business processes repurposing one service for common tasks ]]

 

= Discussion =

== Benefits of SOA ==

The following are the primary reasons which encourages an enterprise to take SOA approach:

* '''Reusability''': SOA allows reuse of business services by enabling developers within an enterprise and/or across enterprises to take the code developed for existing business applications, convert them as web services, and then reuse it to meet new business requirements. This results in huge savings in the cost and time for application development. The more business services get built and get incorporated into different applications, the more are the benefits of reuse.

* '''Interoperability''': One of the main objectives of SOA is to allow clients and services to communicate and understand each other independent of the platform they use. This objective is met when clients and services have a standard and consistent way of communicating with each other. Web services are used for this purpose.

* '''Scalability''': SOA stresses on having few dependencies between the requesting application and the services it uses. Thus, services tend to be coarse-grained, document-oriented, and asynchronous. Coarse-grained services have the advantage of offering a set of related business functions, a document-oriented service accepts a document as input instead of a numeric value or Java object and an asynchronous service doesn't require the client to wait while it performs its processing. This relatively limited interaction from a client for communicating with a coarse-grained, asynchronous service, provides the scope for applications using these services to scale without increasing the communication load on the network.

* '''Flexibility''': SOA discourages sharing semantics, libraries, and often sharing state. This makes it easier for the application to evolve and keep up with changing business requirements.

* '''Cost Efficiency''': As SOA is a standards-based approach, it results in less costly solutions since the integration of clients and services doesn't require the in-depth analysis and unique code of customized solutions. Also, because ervices ins an SOA are less costly to maintain and easier to extend. Also many enterprises have a lot of the Web-based infrastructure for a web services-based SOA, further limiting the cost. The biggest cost saving of all comes from the reusability feature of SOA.

*'''Agility''': Services can now be delivered quickly and need not depend on the larger projects common in the organization. The business can understand systems and requires simpler user interfaces calling on services. This in turn, speeds up the time-to-market.

* Promotes good design as the service is designed independent of who its consumers are or will be.

* Eases documentation and testing by separating them from the issues of the implementation. 

It should be noted that SOA doesn't provide the bebefits mentioned below:

* Simple software engineering

* Free integration or interoperability

* Technology independence

* Vendor independence

* The ultimate architecture for the modern enterprise
 

== Challenges ==

* Maintaining '''metadata''' related to the services is difficult as each service involves various messages used in communicating and an application can involve many such services, generating a huge number of messages. Also, services are delivered by different organizations within the company or different companies and this needs ''SOA Governance''.

* SOA space lacks testing. This indicates that investment is required in a testing framework that would help find the culprit in the architecture.

* As more services get added for extensibility of the system, security models might require changes. Coming up with appropriate levels of security is a concern.

* SOA with Web Services result in addition of XML layers, requiring XML parsing and composition. Applications run slower and require more processing power when used without '''Remote Procedure Calls'''(RPC) [http://en.wikipedia.org/wiki/Remote_procedure_call] and thus, increase costs. 

 
== SOA Principles ==

There is a set of 10 principles for SOA. The first four are based on Don Box's '''four tenets'''. These principles are as listed below:

* '''Explicit boundaries''': ''Services are inextricably tied to messaging in that the only way into and out of a service are through messages''. This means that everything a service would require for its functionality should be passed to it when it is invoked.

* '''Shared Contract and Schema, not Class''': The service consumer and a service provider involved in the contract should have everything they need to consume or provide the service and should not rely upon each other for any kind of reuse.

* '''Policy- Driven''': Since a service can be accessed from various consumers, a policy mechanism is needed. The functional aspects are described in the service interface, and, policies specify the orthogonal, non-functional capabilities and needs.

* '''Autonomous''': It should be possible to change and deploy, version and manage services independent of each other. The consumers need not quickly adapt to the new version.

* '''Wire Formats''': A service must be accessible independent of the platform, as long as the platform supports the exchange of messages adhering to the service interface and policies.

* '''Document-Oriented''': Documents are used to send data to interact with services. These documents might contain redundant information.

* '''Loosely-Coupled''': As far as possible, components must be loosely coupled which enables extensibility, easier maintainence and a better system. But it is not always possible.

* '''Standard-complaint''': Standards for technical aspects like data formats, metadata, transport and transfer protocols etc, must be followed.

* '''Vendor Independent''': It should be possible to build a service provider or service consumer using any technology supporting the appropriate standards.

* '''Metadata - Driven''': The metadata artifacts in the SOA should be discoverable, retrievable and interpretable at both design and run time.
 

= Design Patterns in SOA =

''Design Patterns'' describe common problems with their solutions that can be applied repeatedly under a set of constraints. The collection of SOA design patterns forms a master pattern language applicable in various combination and sequences. Compound patterns comprising of multiple individual patterns is also possible. SOA has a huge number of design patterns which can be divided into the following categories: 

* Foundational Inventory Patterns
* Logical Inventory Layer Patterns
* Inventory Centralization Patterns
* Inventory Implementation Patterns
* Inventory Governance Patterns
* Foundational Service Patterns
* Service Implementation Patterns
* Service Security Patterns
* Service Contract Design Patterns
* Legacy Encapsulation Patterns
* Service Governance Patterns
* Capability Composition Patterns
* Service Messaging Patterns
* Composition Implementation Patterns
* Service Interaction Security Patterns
* Transformation Patterns
* Common Compound Design Patterns 

A more elaborate list and description of these patterns is available at SOA website[http://soapatterns.org/masterlist_c.php]. 

As it can be seen, the SOA design pattern catalog is very broad. These patterns provide design techniques ranging from adjusting minute validation logic in a service contract to design strategies and help structure pools of services across an entire enterprise. An SOA initiative
requires attention to the various design details associated with every service delivered, while not loosing the big picture. Design patterns help maintaining this balance by helping overcome common obstacles that have historically inhibited or derailed SOA project plans.

== Working with SOA patterns ==

Here are a few guidelines for utilizing the SOA design patterns to their maximum extent:

* Patterns should be viewed with a Strategic Context
* Governance has to be considered
* Patterns can be applied to various extents
* Some patterns can be evolutionary
* Patterns can relate to other patterns
* Every pattern is not suitable for everyone
 

= Coupling in SOA =

'''Coupling''' specifies the degree of dependency between 2 or more modules. As we know, coupling can be classified as '''Loose Coupling''' and ''' Tight Coupling'''. Loose coupling can be defined as ''the state in which the impact of change (change in consumers, providers, or cross-cutting policies) is minimized across dependencies''. Loose coupling is important across units of deployment, whereas tight coupling is sufficient within a unit of deployment.

The essence of SOA is building composite distributed systems efficiently. In order for the distributed components to be reusable, reliable, available, scalable and fault tolerant, an appropriate level of loose coupling is needed. The impact of any change or modification and failures should be minimum on the landscape of a system as a whole. Loose coupling provides this property by defining and describing interaction patterns between components and technologies involved. Loose coupling also brings the advantage of '''versionability''' in SOA. If A and B depend on each other, loose coupling is needed only when A may version independently from B. That is, if A and B are versioned together, loose coupling between them is unnecessary.

Services in SOA require described interfaces. This provides a measure of loose coupling as the service dependency isn't a software to software dependency; rather it is N software to interface dependencies. This shows the importance of individual interface contracts. If an interface contract allows anything, then it has tight coupling between components.

There is no one way to build useful distributed systems that are completely decoupled, rather a variety of choices have to be considered based on various aspects of the systems. A property of a system can become a trade-off compared to other properties. For example, an asynchronous service usually requires the client open up its address space for a "callback" which increases the coupling. Also, loosely couple Web Services wait for messages via queuing mechanism before taking action. A large number of such services would be required to exceed the system load. So, tight coupling them can be considered. New mechanisms to switch loosely coupled Web Services to tightly coupled Web Services to avoid system overloads of scarce resources are being considered.

In summary, Loose coupling manifests itself in the SOA paradigm as follows:

* Creates an abstraction layer between the service producers and service consumers.
* Promotes flexibility in making changes to the service implementation without impacting the service consumers.
* In the SOA approach, functionality is organized as a set of modular, reusable shared services that have well-defined interfaces and encapsulate the key rules for accessing the services. They're also built without making any assumptions of who will use or consume these services.
 

= Cohesion in SOA =
'''Cohesion''' is defined as the measure of the relationship between the functionality expressed aby a module and the module itself. It is contrasted with the concept of '''coupling'''. High cohesion correlates to loose coupling.

Cohesion can be classified into various types. Below mentioned are the three "good" types of cohesion identified over the years:

* '''Functional Cohesion''': An individual module does only one thing, resulting in low coupling and reusability.
* '''Sequential Cohesion''': A module carries out several ordered tasks.
* '''Communication Cohesion''': A module carries out multiple operations based on the same input and lacks any prescribed ordering requirements.

The following are identified forms of "bad" cohesion:

* '''Procedural Cohesion''': This is similar to Sequential Cohesion with different data to work on for each task.
* '''Temporal Cohesion''': A module's tasks are related only by time.
* '''Logical Cohesion''': Modules sharing common implementations are grouped.
* '''Coincidental Cohesion''': A module's tasks are related only when residing in the same module.

In today's vernacular, low cohesion is termed as ''coarse-grained''. "Buy a car" and "run credit history" are examples of two such coarse-grained services offered in an SOA. SOA's success requires adopting "course-grained" services that can be plug-n-played with other sources interchangeably. But it is very much possible that within coarse-grained services, such as buy a car, there may be smaller or finer-grained services like Check Inventory, Schedule Detailing, etc. that make up the larger service, buy a car. Thus SOA and high cohesion as a principle aren't incongruent with each other. High cohesion is rather the foundation of creating coarse-grained services which is the fundamental element of creating a successful SOA implementation.
 

= Enterprise Architecture Vs SOA =
this is enterprise arch vs soa

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T01:57:46Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Distributed Revision Control=

Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include [16][17]:

* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.

One of the first closed source DVCS was the [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] which was widely used in enterprise settings.

[http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar] is one of the most famous open distributed style tree versioning tool. In addition to Bazaar, many other distributed version control software are available. They include: [http://en.wikipedia.org/wiki/Darcs Darcs], [http://en.wikipedia.org/wiki/Monotone_(software) Monotone], [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Git_(software) Git], [http://en.wikipedia.org/wiki/SVK SVK].

Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Revision_control] Revision control, 2010. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Distributed_revision_control] Distributed revision control, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T01:57:17Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Distributed Revision Control=

Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include[16][17]:

* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.

One of the first closed source DVCS was the [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] which was widely used in enterprise settings.

[http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar] is one of the most famous open distributed style tree versioning tool. In addition to Bazaar, many other distributed version control software are available. They include: [http://en.wikipedia.org/wiki/Darcs Darcs], [http://en.wikipedia.org/wiki/Monotone_(software) Monotone], [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Git_(software) Git], [http://en.wikipedia.org/wiki/SVK SVK].

Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Revision_control] Revision control, 2010. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Distributed_revision_control] Distributed revision control, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T01:53:13Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Distributed Revision Control=

Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include:[16][17]

* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.

One of the first closed source DVCS was the [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] which was widely used in enterprise settings.

[http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar] is one of the most famous open distributed style tree versioning tool. In addition to Bazaar, many other distributed version control software are available. They include: [http://en.wikipedia.org/wiki/Darcs Darcs], [http://en.wikipedia.org/wiki/Monotone_(software) Monotone], [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Git_(software) Git], [http://en.wikipedia.org/wiki/SVK SVK].

Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Revision_control] Revision control, 2010. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Distributed_revision_control] Distributed revision control, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T01:40:52Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Distributed Revision Control=

Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include:

* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.

One of the first closed source DVCS was the [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] which was widely used in enterprise settings.

[http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar] is one of the most famous open distributed style tree versioning tool. In addition to Bazaar, many other distributed version control software are available. They include: [http://en.wikipedia.org/wiki/Darcs Darcs], [http://en.wikipedia.org/wiki/Monotone_(software) Monotone], [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Git_(software) Git], [http://en.wikipedia.org/wiki/SVK SVK].

Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Revision_control] Revision control, 2010. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Distributed_revision_control] Distributed revision control, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T01:36:53Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Distributed Revision Control=

Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include:

* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.

One of the first closed source DVCS was the [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] which was widely used in enterprise settings.

[http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar] is one of the most famous open distributed style tree versioning tool. In addition to Bazaar, many other distributed version control software are available. They include: [http://en.wikipedia.org/wiki/Darcs Darcs], [http://en.wikipedia.org/wiki/Monotone_(software) Monotone], [http://en.wikipedia.org/wiki/Mercurial Mercurial], [http://en.wikipedia.org/wiki/Git_(software) Git], [http://en.wikipedia.org/wiki/SVK SVK].

Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T01:34:29Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Distributed Revision Control=

Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include:

* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.

One of the first closed source DVCS was the [http://en.wikipedia.org/wiki/Sun_WorkShop_TeamWare Sun WorkShop TeamWare] which was widely used in enterprise settings.

[http://en.wikipedia.org/wiki/Bazaar_(software) Bazaar] is one of the most famous open distributed style tree versioning tool. In addition to Bazaar, many other distributed version control software are available. They include:Darcs, Monotone, Mercurial, Git, Monotone, SVK.

Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T01:27:36Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Distributed Revision Control=

Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include:

* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.

Bazaar is one of the most famous open distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other distributed version control software are available. They include:Darcs, Monotone, Mercurial, Git,Monotone, SVK
Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T01:24:35Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Distributed Revision Control=

Distributed revision control (DVCS) is a fairly new concept in revision control. With it's peer-to-peer approach, each peer's copy of the code base is a bona-fide repository. It synchronizes by exchanging patches between peers. It's advantages over centralized revision control include:

* By default, only the working copy of the code base exist.
* Since, communication with a central server is not required, common operations are much more faster. Peers need to communicate only when pushing or pulling changes with other peers.
* Each working copy exists as a remote backup of the code base.

Open systems are the most recent phenomenon in distributed revision control. They are characterized by their support for independent branches, and heavy reliance on merge operations. It is generally characterized by the following features -

* Peers are free to join as and when they wish without going through any elaborate approval process
* Each working copy works like a branch
* Selective changes can be "cherry-picked", pulling them from specific peers.

Bazaar is one of the most famous open distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T00:26:08Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward [http://docstore.mik.ua/orelly/unix/upt/ch20_13.htm deltas] grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, [http://en.wikipedia.org/wiki/Branch_(software) branching] and [http://en.wikipedia.org/wiki/Trunk_(software) tagging] are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar and others=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T00:15:02Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar and others=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS, 2005. Retrieved September, 2010.

[http://www.linux.ie/articles/subversion/] Neary, David, Subversion Building a better CVS.Linux Magazine, (30), 59-63.

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Amitash, Difference between CVS and Subversion. Retrieved September, 2010.

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion, 2010. Retrieved September, 2010.

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-17T00:07:53Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar and others=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems, 2010. Retrieved September, 2010.

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter F., RCS-A system for Version Control.Software—Practice & Experience, 15 (7), 637-654.

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System, 2010. Retrieved September, 2010.

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System, 2010. Retrieved September, 2010.

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] Vasudevan, Alavoor, CVS-RCS-HOWTO Document for Linux (Source Code Control System),2003. Retrieved September, 2010.

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] Collins-Sussman, Ben, Fitpatrick, Brian W. and Pilato, C. Michael, Version Control with Subversion (for Subversion 1.5). O'Reilly Media Inc., California, 2004.

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-16T23:52:57Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar and others=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Introducing Bazaar. Retrieved September, 2010.

[http://code.google.com/p/pysync/wiki/VCSHistory] Aran, A Brief History of Version Control Systems. Retrieved September, 2010.

[http://sccs.berlios.de/] Schilling, Jörg, SCCS project. Retrieved September 16,2010.

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-16T23:27:05Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar and others=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4), 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Louridas, Panagiotis, Version Control.IEEE Software, 23 (1), 108–109.

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-16T23:22:54Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar and others=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] Rochkind, Marc J., The Source Code Control System.IEEE Transactions on Software Engineering, SE-1 (4). 364-370.

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-15T20:40:52Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, there have been 4 generations of VCS[1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning tools-central style, example: CVS
#Tree versioning tools-central style: take two, example: Subversion
#Tree versioning tool-distributed style, example: Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar and others=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch2 S20 st

2010-09-08T05:13:06Z

Marashid:

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE 517 Fall 2010/ch1 1a br]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]

*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]

*[[CSC/ECE 517 Fall 2010/ch1 S23 GP]]

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-08T05:12:59Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are being released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [10]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of [http://www.collab.net CollabNet, Inc]. And by late 2001, it started being deployed. [11]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following [12] [13] [14] [15]:
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar and others=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms]. In addition to Bazaar, many other version control software are available. Comparison of version control systems can be found [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software here].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =
[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T22:09:21Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [10]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells. [11]

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of CollabNet, Inc [http://www.collab.net]. And by late 2001, it started being deployed. [12]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([13] [14] [15] [16]):
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =

[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T22:08:10Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells [10].

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of CollabNet, Inc [http://www.collab.net]. And by late 2001, it started being deployed. [12]

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([13] [14] [15] [16]):
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =

[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T22:06:25Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by [http://www.cs.vu.nl/~dick/ Dick Grune] of VU University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells [10].

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of CollabNet, Inc [http://www.collab.net]. And by late 2001, it started being deployed.

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([10] [11] [12] [13]):
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =

[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T22:05:49Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by Dick Grune [http://www.cs.vu.nl/~dick/] of University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells [10].

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of CollabNet, Inc [http://www.collab.net]. And by late 2001, it started being deployed.

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([10] [11] [12] [13]):
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =

[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T22:04:45Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by Dick Grune of University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells [10].

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

In early 2000 work began on Subversion by Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999) and his friend Jim Blandy with the backing of CollabNet, Inc [http://www.collab.net]. And by late 2001, it started being deployed.

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([10] [11] [12] [13]):
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =

[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://svnbook.red-bean.com/en/1.5/svn.intro.whatis.html] What Is Subversion?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch2 S20 st

2010-09-07T20:32:27Z

Marashid:

*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]

*[[CSC/ECE_517_Fall_2010/ch1_1a_br]]

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T20:30:20Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by Dick Grune of University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution. [9]

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells [9].

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([10] [11] [12] [13]):
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =

[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T20:29:55Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by Dick Grune of University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution.

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells [9].

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([10] [11] [12] [13]):
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =

[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://en.wikipedia.org/wiki/Concurrent_Versions_System] Concurrent Versions System

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T20:28:58Z

Marashid:

"A source code system is a giant UNDO key-a project-wide time machine"

-Andy Hunt and Dave Thomas
 

= Introduction =

Dozens of version control systems are available in the market. Most of them are open source and free. First version control system was released in the early 1970s and new tools are released even today. Briefly, VCSs can be categorized into four [1]:
#File versioning tools, examples: SCCS, RCS
#Tree versioning Tools-central style, example: CVS
#Tree versioning tools-central style, example: Subversion
#Tree versioning tool-distributed style, example Bazaar

= Source Code Control System =

The very first version control system[5] is the Source Code Control System, which was originally written by [http://www.informit.com/authors/bio.aspx?a=AFAC0A13-A141-47D6-B508-04A03D7B4634 Marc J. Rochkind] in 1972 at Bell Labs, NJ. It is designed to help programming projects control changes to source code. SCCS provides facilities for storing, updating and retrieving all versions of modules by version number, and it records: who made software change, when and where it was made as well as the reason of the change. The first two implementations of SCCS were: one for IBM 370 under OS and other one for PDP 11under UNIX. [2][3]

Source Code control System can be categorized under file versioning tools. It only versions individual files. SCCS was an effective method for small projects. One Source file results in one SCCS history file. It is easy to understand format of the history files that allows manual intervention. Also, checksums and forward deltas grant file integrity and immediate detection of corruption. It was the major form of source code control especially on UNIX platforms until the release of Revision Control Systems.

= Revision Control System=

Revision Control System[7] is the successor to SCCS and written by [http://www.ipd.uni-karlsruhe.de/~tichy/ Walter F. Tichy] (now a faculty of University Karlsruhe, Germany) in 1982 at Purdue University. Just like SCCS, RVS is a file versioning tool. The fundamental storage unit is a revision group. Also it supports branches within a file. Unlike SCCS it supports merges. RCS storage on the mainline uses reserve deltas: The latest revision is stored intact but earlier revisions are stored as deltas from the latest. On branches, revisions are stored as forward deltas. Thus checking out branches is slow. For Example:Main line of code has 100 revisions. Assume that there is branch at revision 10. This branch has 80 revisions. To check out the branch tip, RCS must do the followings:

* Retrieve mainline revision 100
* Retrieve and apply reverse deltas from 99 down to 10
* Retrieve and apply 80 forward deltas on the branch

Additionally, in the early 80s, when RCS was released, there were also competitors such as: IBM CLEAR/CASTER, AT&T SCCS, and CMU Software Development control system.

=Concurrent Version System=

CVS was originally created by Dick Grune of University of Amsterdam between 1984 and 1985 and was open sourced in 1986. However the code that eventually evolved into the widely used CVS was started by Brian Berliner in early 1989. By late 1990, with help from several others, the first edition was up for distribution.

CVS , while using RCS underneath, is a lot more powerful tool and can control a complete source code tree. It can be greatly customized with scripting languages like PERL, Korn and bash shells [9].

CVS offers the following significant advantages over RCS:
* It can run scripts which log CVS operations or enforce site-specific polices.
* CVS enables developers from different geographical location to function as a single team. Information is stored on a single central server and the client machines have a copy of all the files. The client- server connection must be up to perform CVS operations but need not be up to edit or manipulate the current versions of the files.
* It can merge changes from non-CVS vendor branches.
* Allows more than one developer to work on the same file at the same time
* CVS servers run on most OS including unix-variants, Windows and OS/2 etc

=Subversion=

Subversion is the next-in-line of version control system. CVS has a number of problems, primarily caused by its dependency on the RCS file format for versioning files. These and other issues addressed by Subversion include the following ([10] [11] [12] [13]):
* In CVS, atomicity is not guaranteed. Subversion ensures atomicity.
* CVS has no way to rename files and save versioning history. In Subversion, the common history of file1 and file2 is conserved. Additionally, Subversion can be used for versioning a lot of different things. Directories and file metadata, as well as renamed or copied files, all have their own versioning.
* In CVS, branching and tagging are expensive operations for big repositories and directory trees, which have a cost proportional to the number of files being branched or tagged. Subversion has made both branching and tagging constant time operations. They are implemented simply by copying the directory being tagged.
* CVS is not binary file friendly. Any change to a binary file results in the replacement of the old file. Subversion uses a different approach to provide efficient binary diffing which means it can store pdfs and other binary files efficiently.
* If we change a file locally using CVS, and we want to know the difference, then the entire file has to be sent to the server. When we change a file using Subversion repository, a copy of the latest repository revision is made locally. The differences are sent in both directions, which mean a lot less use of bandwidth.

=Bazaar=

Bazaar is one of the most famous distributed style tree versioning tool. Distributed structure is superior to central style version control systems in [http://wiki.bazaar.canonical.com/BzrWhy many terms].

= Summary =

Using VCS has many benefits. For example: if a team conducts the project, there will be harmony among the team members, and no one will write over other people’s code. Moreover, every change (version) will be stored in VCS repository. This will enable team members to see the differences between versions of the same file, and they will know the time of the changes as well as the responsible team member. Furthermore, Development can be spit into different branches, each branch, lets say keeping track of the fixes associated with a software release. Then file versions can be obtained with a branch and can be applied to the same fix to multiple branches. Another benefit is that, VCS repository can be useful to understand how good the project was: How many lines changed from the previous version? Which are the most and least productive days of the week? Which team member made the most contribution? [8]

= References =

[http://doc.bazaar.canonical.com/bzr.2.1/en/user-guide/introducing_bazaar.html] Bazaar v2.1 Documentation

[http://code.google.com/p/pysync/wiki/VCSHistory] A Brief History of VCS

[http://sccs.berlios.de/] SCCS - The POSIX Source Code Control System

[http://basepath.com/aup/talks/SCCS-Slideshow.pdf] The Source Code Control System by Marc J. Rochkind

[http://en.wikipedia.org/wiki/Source_Code_Control_System] Source Code Control Systems

[http://www.cs.purdue.edu/homes/trinkle/RCS/rcs.ps] Tichy, Walter RCS-A system for Version Control

[http://en.wikipedia.org/wiki/Revision_Control_System] Revision control System

[http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2006.32] Version Control Systems,” by Diomidis Spinellis (IEEE Software, vol. 22, no. 5, 2005, pp. 108–109)

[http://www.faqs.org/docs/Linux-HOWTO/CVS-RCS-HOWTO.html#s2] CVS or RCS ?

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

[http://www.linux.ie/articles/subversion/] Subversion - a better CVS

[http://www.differencebetween.net/technology/difference-between-cvs-and-subversion/] Difference between CVS and Subversion

[http://en.wikipedia.org/wiki/Apache_Subversion] Apache Subversion

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T15:33:26Z

Marashid:

CSC/ECE 517 Fall 2010

2010-09-07T06:11:55Z

Marashid:

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 S10 ms]]

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 1a br]]

CSC/ECE 517 Fall 2010

2010-09-07T06:11:31Z

Marashid:

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 S10 ms]]

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 1a br]]

CSC/ECE 517 Fall 2010

2010-09-07T06:11:23Z

Marashid:

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

CSC/ECE 517 Fall 2010

2010-09-07T06:11:12Z

Marashid:

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 S10 ms]]

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 1a br]]

[http://www.pushok.com/soft_svn_vscvs.php] SVN vs CVS

CSC/ECE 517 Fall 2010/ch1 1a br

2010-09-07T06:08:33Z

Marashid:

CSC/ECE 517 Fall 2010

2010-09-07T06:07:46Z

Marashid:

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 S10 ms]]

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 1a br]]

CSC/ECE 517 Fall 2010

2010-09-07T06:06:18Z

Marashid:

#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 S10 ms]]
#REDIRECT [[CSC/ECE 517 Fall 2010/ch1 S10 br]]

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:34:46Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:34:16Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:33:17Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:30:32Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:21:42Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:17:48Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:17:17Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:15:15Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T20:13:08Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T19:58:26Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-06T19:56:09Z

Marashid:

History of version-control systems (Wiki textbook Team4)

2010-09-03T18:43:32Z

Marashid:

= RBP/OO Interactions =

:It would be good if OO programs could interact with OO databases, but alas, relational databases have a 99% market share. This has led to many attempts to access them from OO languages. Design patterns and implementations for doing this have been developed, starting with [http://c2.com/cgi/wiki?CrossingChasms Crossing Chasms] and extending to [http://en.wikipedia.org/wiki/ActiveRecord_(Rails) Rails' ActiveRecord] [http://wiki.rubyonrails.org/rails/pages/ActiveRecord][http://ar.rubyonrails.com/]. Here, we investigate the various approaches for marrying OO programs to relational databases, comparing them in terms of ease of programming, robustness, and efficiency.

= Introduction =

This article explores object-relation mapping [http://en.wikipedia.org/wiki/Object-relational_mapping (ORM)], a programming technique that bridges object-oriented languages against relational databases, and compares them against more traditional approaches to database programming such as stored procedures and dynamic [http://en.wikipedia.org/wiki/Sql SQL]. In the process, we examine basic design patterns for bridging this gap, and evaluate several popular ORM frameworks found in popular program languages in the process.

One of the primary problems that object-relational mapping (ORM) attempts to solve is that of [http://www.service-architecture.com/object-oriented-databases/articles/transparent_persistence.html transparent object persistence], which allows an object to outlive the process that created it. The state of an object can be stored to disk, and an object with the same state can be re-created in the future. This object data is typically internally stored in a relational database using SQL.

Unfortunately, relational databases lie at the core of any modern Enterprise application, and such tabular representation of SQL data is fundamentally different than the network of objects used in object-oriented applications. ORM allows us to interact with business objects directly in an object-oriented domain model, instead of having to work with rows and columns at the programming level. For further introduction to ORM and the surrounding issues, refer to [http://www.agiledata.org/essays/mappingObjects.html][http://www.acmqueue.org/modules.php?name=Content&pa=printer_friendly&pid=538&page=1][http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/][http://www.rgoarchitects.com/Files/ormappin.pdf].

= Design Patterns =

Design patterns provide the theoretical underpinnings for the object-relational tools that we use in practice today. One of the first design pattern languages exploring the bridge between object-oriented domains and relational domains is Crossing Chasms.

# The ''Chasm'' in [http://www.ksc.com/articles/patternlanguage.htm Crossing Chasms] refers to the semantic and structural gap between data in an object oriented application and the representation and access of that data in a database. As a [http://en.wikipedia.org/wiki/Pattern_language Pattern Language], Crossing Chasms captures multiple proven methods for effectively integrating an object oriented application and a relational database. These solutions are grouped into two broad categories, [http://www.ksc.com/articles/staticpatterns.htm Static Patterns], useful in data modeling and database table design, and [http://www.ksc.com/articles/crossingchasms.htm Architectural Patterns], useful primarily for designing overall systems to be as effective as possible in the dynamic interaction between data and objects. Originally developed to integrate Smalltalk applications to relational databases, and rooted in the theory of Object Orientation from Jacobsen to Rumbaugh, the patterns have been abstracted and refined to capture the best practices of the experts in OO database integration, whatever the platform. The architectural patterns include ''Four Layer Architecture'', ''Trim And Fit Client'', and ''Phase In Tiers'', which we summarize here.
# The [http://c2.com/cgi/wiki?FourLayerArchitecture Four Layer Architecture] improves upon the classical 'Model-View-Controller' application design by first recognizing the 'M-V-C' architecture, while an evolutionary gain, is inadequate to support every possible application environment, especially, the challenges associated with database integration and communication. Three of the layers of the 'Four Layer Architecture' closely follow the 'Model', 'View', and 'Controller', with the addition of the 'Infrastructure' Layer to handle the database tables and communication links.
# Closely related to the Four Layer Architecture is the [http://c2.com/cgi/wiki?TrimAndFitClient Trim And Fit Client], the pattern describing how to partition the processing workload between the client and server. The factors driving the decision of how much work the client should do are very dynamic, given Moore's Law and increases in efficiency for communication links as well as memory, yet the 'Trim And Fit Client' pattern provides a timeless solution. Leveraging the architectural segments provided by the 'Four Layer Architecture', 'Trim And Fit Client' guides the designer to partition responsibility between the client and server at an arbitrary point either in the Application Models, or between the Application and Domain Model layers. This scheme gives the designer the flexibility to allocate the workload in an optimal way for the particular constraints in place, without being forced into a design situation with an imbalanced workload.
# [http://c2.com/cgi-bin/wiki/wiki?PhaseInTiers Phase In Tiers] presents the best practices to engage when designing a constantly expanding data center. Although it may be difficult for the architect to estimate the capacity required for the system, and nearly impossible for the developers to continuously migrate new applications and data to the growing network of database, client applications, and servers, the 'Phase In Tiers' pattern helps the enterprise architect stay ahead of the challenge. Incorporating another pattern, the [http://c2.com/cgi/wiki?ThreeTierDistributionArchitecture Three-Tier Distribution Architecture], which provides justification for the now commonplace three-tiered enterprise application-platform split of client-server-database, 'Phase In Tiers' shows how to implement new designs in stages, over time, without breaking existing applications, or slowing the roll-out of new features. The key idea of 'Phase In Tiers' is to build new functionality into clients, and execute staged migration of application layers from the client to servers.

= Concrete Examples =

To motivate our discussions, it is helpful to provide practical, concrete reference examples of object-relational frameworks against traditional dynamic SQL approaches. One can think of these examples as the "Hello World" of DB interfacing.

== Embedded (Ad-Hoc) SQL ==

The traditional approach uses simple strings and API calls to connect to databases and return their results. In this example in PHP, the title and date of the event with an ID greater than 5 is echoed:

<code>
<?php
$link = mysql_connect('localhost', 'mysql_user',
'mysql_password');
if (!$link) {
die('Could not connect: ' . mysql_error());
}
echo 'Connected successfully';
mysql_close($link);

$sql = "SELECT title, date
FROM events
WHERE id > 5";

$result = mysql_query($sql);

while ($row = mysql_fetch_assoc($result)) {
echo $row["title"];
echo $row["date"];
}
?>
</code>

== Stored Procedures ==

Stored procedures are mechanisms that encapsulate SQL queries and other SQL business logic within the database server itself. It has the advantage of decoupling the SQL syntax from the client application, but calls to these stored procedures themselves are still not transparent from within the client application. An [http://www.sqlteam.com/article/stored-procedures-an-overview example of a SQL stored procedure] in Microsoft SQL Server is as follows:

CREATE PROCEDURE spCaliforniaAuthors
AS
SELECT * FROM authors
WHERE state = 'CA'
ORDER BY zip

This stored procedure is kept on the database. The application can then call the stored procedure <tt>spCaliforniaAuthors</tt> directly, without concerning themselves with the lower level implementation details.

== The ORM Approach ==

Using object-relational mapping, the internal connection details are hidden, usually in external configuration files. The application developer need not have any knowledge of SQL programming, and can manipulate and access database objects in an object-oriented domain. In this example using Java and Hibernate, the programmer created a new event and then saves it to a database:

Session session = HibernateUtil.getSessionFactory().
getCurrentSession();
session.beginTransaction();

Event theEvent = new Event();
theEvent.setTitle(title);
theEvent.setDate(date);
session.save(theEvent);

session. getTransaction().commit();]

== Microsoft LINQ ==

Microsoft provides a hybrid approach to object-relational mapping, called LINQ, which [http://msdn.microsoft.com/en-us/library/bb425822.aspx interleaves database metadata with object-oriented programming] to allow for language-integrated querying of relational databases.

[Table(Name="Customers")]
public class Customer
{
[Column(IsPrimaryKey=true)]
public string CustomerID;
[Column]
public string City;
}

Unlike other ORM mechanics, which try to hide non-OO querying as much as possible, or use external library calls for direct SQL queries, LINQ to SQL provides a run time infrastructure for managing relational data as objects without losing the ability to query through SQL-like constructs:

var q =
from c in Customers
where c.City == "London"
select c;

foreach (var cust in q)
Console.WriteLine("id = {0}, City = {1}",
cust.CustomerID, cust.City);

These SQL-like constructs are integrated into the language itself, without the need for external library calls, and are available to non-database data structures as well, if they support the appropriate interfaces.

= Comparison =

With our examples in hand, we can now discuss the advantages and disadvantages of the various approaches to marrying object-oriented programming and relational databases.

== Ease of Programming ==

Those who come from a database background find embedded SQL easy to use because queries are written in a SQL language that they are already familiar with. The other advantage of embedded SQL is that it allows the application developers to exploit the properties and function of their particular database, at the expense of reducing portability of the application. From a debugging perspective, the database logic is directly embedded within the source code, which avoids the [http://wapedia.mobi/en/Yo-yo_problem yo-yo effect] between the application source and database source. [http://www.codinghorror.com/blog/archives/000117.html].

Stored procedures fare slightly better and have some benefits over embedded SQL. [http://articles.techrepublic.com.com/5100-10878_11-5766837.html] They decouple the database logic from the application logic, where database programmers can work on database logic and application programmers can independently work on application logic. In addition, stored procedures can be changed without having to recompile the application, leading to more modular implementations.

Still, the use of stored procedures is not without criticism. Stored Procedures are written in big iron database languages like PL/SQL or T-SQL, which tend to be archaic in functionality. Stored procedures cannot be debugged easily because they cannot be debugged in the same process as the application. Finally, stored procedures cannot pass objects, and instead must pass primitive data types back and forth, often resulting in passing back and forth an overly large number of parameters to these procedures to accomplish a task. [http://www.codinghorror.com/blog/archives/000117.html]

ORM frameworks have the advantage in that developers work with objects and the mapping tools that enable data persistence.
transparently. For most applications, this provides a natural object-oriented way to access relational databases. When queries are required that cannot easily be expressed in an object-oriented domain, these ORM tools typically provide standardized, proprietary SQL-like syntax, such as HSQL, thereby abstracting the details of the database itself.[http://espresso.cs.up.ac.za/publications/Espresso%20SAICSIT%20ODBMS%20Presentation%20v6.pdf]

While most ORM frameworks are easy to program from an application developer perspective, the initial configuration of such frameworks can be daunting due to the framework's generality and [http://www.hibernate.org/hib_docs/reference/en/html/session-configuration.html large number of configuration parameters]. Configuration of ORM is difficult enough that there exist meta code generation tools such as [http://www.hibernate.org/72.html XDoclet] and [http://boss.bekk.no/boss/middlegen/ Middlegen], which can be thought of as compilers in their own right.

Finally, let us look at [http://en.wikipedia.org/wiki/Language_Integrated_Query LINQ], a variation of ORM which adds querying capabilities to .NET 2.0 and provides operations similar to that of SQL. LINQ's major advantage is that it provides consistent domain modeling, while hiding the mundane code (LINQ-to-SQL) that often gets exposed either in configuration of ORM or in embedded SQL. [http://blogs.vertigo.com/personal/petar/Blog/archive/2008/01/04/why-we-notneed-to-use-linq.aspx] LINQ also provides one source and query language for multiple data stores, such as relational data, XML data, and other .NET objects [http://www.eleves.ens.fr/home/rossant/docs/linq.pdf], and it is integrated within the syntax of the language. With respect to ease of programming, LINQ is a clear winner, but its model of embedding database metadata and querying directly within application logic may be met with resistance by individuals who prefer separating database programmers from application developers. [http://reddevnews.com/features/article.aspx?editorialsid=707] LINQ is also specifically developed for use in Microsoft Visual Studio, and does not work in other languages or environments.

== Robustness ==

While embedded SQL is one of the easiest ways to connect to a database, it is also one of the least robust. Embedded SQL is commonly subject to [http://en.wikipedia.org/wiki/SQL_injection SQL injection] attacks, though these attacks can be mitigated by libraries with careful programming. Embedded SQL also reduces the elegance of code by increasing coupling between the database and the application itself. In the PHP sample code provided, for instance, the code is tied to a MySQL database using the <tt>mysql_connect</tt> function.

Since the SQL code is interspersed between lines of non-SQL code, it can be difficult to maintain and modify if the SQL code needs to be modified. Indeed, there is significant impact to the understandability, testability, adaptability, and other quality aspects of the overall system.[http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/scam/2007/2880/00/2880toc.xml&DOI=10.1109/SCAM.2007.23] Despite these issues, embedded SQL remains a popular choice because it works relatively well for many smaller business applications that mainly do basic [http://en.wikipedia.org/wiki/Create,_read,_update_and_delete CRUD] operations, even in languages like Java that support object-oriented design.

Stored procedures are certainly more robust than embedded SQL. Since SQL code stays in the database, and application code stays in the application, it is easier to maintain. The [http://msdn.microsoft.com/en-us/library/ms978510.aspx .NET Data Access Architecture Guide] specifies other reasons that stored procedures are more robust:

# Stored procedures can be individually secured within the database. A client can be granted permissions to execute a stored procedure without having any permissions on the underlying tables.
# Stored procedures result in easier maintenance because it is generally easier to modify a stored procedure than it is to change a hard-coded SQL statement within a deployed component.
# Stored procedures add an extra level of abstraction from the underlying database schema. The client of the stored procedure is isolated from the implementation details of the stored procedure and from the underlying schema.

Finally, we turn to ORM and LINQ. Both of these mechanisms can be considered robust because they [http://www.hibernate.org/hib_docs/reference/en/html/session-configuration.html abstract entirely the database connection details] and handling from the application developer. One can change databases from say, Microsoft SQL Server to PostgreSQL, with no change in application logic other than the editing of the ORM database configuration files. However, this increased robustness is a trade off and requires sacrifices in ease of programming with respect to smaller projects and potential sacrifices in performance and efficiency, as will be discussed in the following section.

== Efficiency ==

The efficiency of the different mechanisms for database access are depend on the application, implementation, and a variety of other factors. As such, we describe the differences in efficiency only qualitatively rather than quantitatively.

At first glance, it may appear that embedded SQL is highly efficient. After all, embedded SQL queries are low-level strings passed directly to the SQL database, and SQL queries can be custom written to take advantage of special capabilities of the particular database. Similarly, others believe that the overhead of processing stored procedures results in a performance penalty. The real answer is not as cut and dried, especially when comparing against stored procedures. Here's why: [http://codebetter.com/blogs/karlseguin/archive/2008/01/02/foundations-of-programming-part-6-nhibernate.aspx]

# In many cases, you can get better performance by looping and filtering data within the database than at the Data Access Layer. This is because databases are intrinsically designed to do this, while application developers have to write their own code.
# Stored procedures can be used to batch common work together or retrieve multiple sets of data. This batching of data reduces network traffic and and consolidates work.
# Many databases can also take advantage of execution plans, which allow them to cache stored procedures versus embedded SQL where each execution would have to be recalculated for each request.
# Databases tend to optimize better the closer they are to the bare metal. The easiest way to get performance out of your database is to do everything you can to take advantage of the platform you are running on, which means running queries as close to the database as possible.

ORM approaches have the opposite default criticism since many assume that their efficiency is lower than stored procedures or embedded SQL because of their overhead in performing O/R mapping. Again, the answer is not as clear cut. Let us examine one of more popular ORM frameworks, Hibernate, for evidence: Hibernate implements an extremely high-concurrency architecture with no resource-contention issues (apart from the obvious - contention for access to the database). This architecture scales extremely well as concurrency increases in a cluster or on a single machine. [http://www.hibernate.org/15.html]

LINQ users can achieve optimum performance by leveraging the capabilities of their platform [http://www.singingeels.com/Articles/Improving_Performance_With_LINQ.aspx]. Knowing how to utilize the LINQ data context in conjunction with appropriately crafted queries permits the implementation to avoid unnecessary database activity, such as eliminating write-backs when no data has changed.

For those interested in competitive performance challenges, the [http://www.polepos.org/ PolePosition] benchmark suite provides rigorous comparison of ORM application-implementation pairs, with some test data archived at their site for specific implementations running well-defined test cases.

= Implementations =

Languages and environments as diverse as .Net and PHP support ORM [http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software].

We will focus on specific implementations in Java, Ruby on Rails, Microsoft .NET, PHP, ASP Classic, and JDBC.

== ORM in Java ==

In recent years, Java has experienced a paradigm shift from complex heavy-weight frameworks such as [http://java.sun.com/products/ejb/ Enterprise Java Beans] to more light-weight agile frameworks that rely instead of simple Plain Old Java Objects ([http://en.wikipedia.org/wiki/POJO POJOs]). This in turn, has increased the popularity of ORM for Java developers.

Indeed, Object-relational mapping is especially popular in the Java community, compared, for example to .NET developers. [http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/co/&toc=comp/mags/co/2005/01/r1toc.xml&DOI=10.1109/MC.2005.22] Although a [http://java-source.net/open-source/persistence plethora of ORM frameworks exist] for Java, among the most popular and widespread ORM layers today include Sun's [http://java.sun.com/jdo/ JDO] and the somewhat entrenched open source O/R mapping framework, [http://www.hibernate.org Hibernate].

We begin with Java Data Objects (JDO), which by itself is not a framework, but a specification. The API is a standard interface-based Java model abstraction of persistence, developed under the auspices of the [http://jcp.org/ Java Community Process]. Frameworks like [http://db.apache.org/jdo/ Apache JDO] then implement this specification. JDO aims to provide implementations for not only relational databases, but also object databases, and file systems.

Hibernate is another ORM implementation, and though it is open source, it is often considered "proprietary" because it does not directly implement the JDO specification or Java Community Process specifications. Still, Hibernate's momentum has resulted in it becoming a de facto standard in the Java industry, furthered by frameworks such as [http://www.springframework.org/ Spring] that use it as a building block.

== ORM in Ruby on Rails ==

Ruby on Rails is an interesting example of the use of ORM, which provides the [http://en.wikipedia.org/wiki/Active_record_pattern ActiveRecord] pattern implemented as [http://wiki.rubyonrails.org/rails/pages/ActiveRecord ActiveRecord in Rails]. In addition to mapping objects to table rows, and providing persistence in the traditional ORM sense, Ruby on Rails has language-level support for ORM with ActiveRecord. Rails allows database-oriented web services to be configured and deployed with a minumum of development, featuring the classic ''Model'', ''View'', ''Controller'' (M-V-C) architecture. In this context, ''Rails ActiveRecord'' implements the Model layer of the M-V-C architecture.

== ORM in Microsoft .NET ==
Although ORM has achieved significant penetration of the Java world, there are now a variety of [http://en.wikipedia.org/wiki/Category:.Net_Object-relational_mapping_tools .NET implementations enabling ORM.]

An obvious choice for those already aware of [http://en.wikipedia.org/wiki/Hibernate_(Java) Hibernate for Java], is the .NET port of ''Hibernate'' known as [http://www.hibernate.org/343.html NHibernate]. ''NHibernate'' supports a number of database platforms [http://www.hibernate.org/361.html] and permits developers to work in native .NET [http://www.hibernate.org/343.html], integrating Plain Old CLR Objects ([http://en.wikipedia.org/wiki/POCO POCOs]) data with the underlying database. For a practical getting-started developer guide, read [http://www.developer.com/net/asp/article.php/3709346 Using NHibernate as an ORM Solution for .NET].

== LINQ in Microsoft .NET ==

As described previously, Microsoft's [http://msdn.microsoft.com/en-us/netframework/aa904594.aspx LINQ] provides ''language-integrated query''[http://msdn.microsoft.com/en-us/library/bb308959.aspx#linqoverview_topic1] to the .NET environment. Supporting C# and Visual Basic, ''LINQ'' provides separate, optimized ''providers'' for access from the programming language level to relational data objects [http://msdn.microsoft.com/en-us/library/bb425822.aspx], XML documents[http://msdn.microsoft.com/en-us/library/bb308960.aspx], and SQL databases [http://msdn.microsoft.com/en-us/library/bb425822.aspx].

== Dynamic SQL in PHP, ASP Classic, and JDBC ==

Despite the availability of object-relational libraries, dynamic SQL continues to be a popular development mechanism for interfacing with databases. Dynamic SQL is not an object-oriented methodology, but rather a "bare metal" programming approach where SQL strings are directly constructed through concatenation or other low-level mechanisms and then directly passed to the database. The results of such queries are themselves lower level objects like record sets or hash tables.

= Summary =

This article has introduced ORM from the user's perspective, motivating the discussion with the design patterns relevant to integrating a relational database to an object oriented application. We have learned the basic advantages of ORM and the techniques by which it is employed. In addition, we have seen examples of ORM usage in several implementations, and we have explored the various approaches to ORM in languages and environments as diverse as Java / Hibernate, and Microsoft LINQ. In addition, we have compared the Efficiency and Programming Ease of the different implementations. ORM has become ubiquitous as object technology development marches forward in concert with advances in networks and distributed architectures.

= External Links =

This section summarizes important links from the article for those wishing to quickly access the most practical ''ORM'' resources.

* [http://en.wikipedia.org/wiki/Object-relational_mapping Wikipedia on ORM]
* [http://en.wikipedia.org/wiki/ActiveRecord_(Rails) Wikipedia on Active Record in Rails]
* [http://www.agiledata.org/essays/mappingObjects.html Object Mapping Tutorial]
* [http://www.acmqueue.org/modules.php?name=Content&pa=printer_friendly&pid=538&page=1 The ACM on ORM]
* [http://digitalcommons.macalester.edu/context/mathcs_honors/article/1006/type/native/viewcontent/ Object Relational Mapping Tutorial]
* [http://www.rgoarchitects.com/Files/ormappin.pdf When / Why to use ORM]
* [http://www.sqlteam.com/article/stored-procedures-an-overview Stored Procedures Overview]
* [http://www.hibernate.org Hibernate]
* [http://msdn.microsoft.com/en-us/netframework/aa904594.aspx Microsoft on LINQ]
* [http://en.wikipedia.org/wiki/Language_Integrated_Query Wikipedia on LINQ]
* [http://www.hibernate.org/343.html NHibernate]