Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki1a 3 ve

2009-09-13T19:55:16Z

Wbosborn: /* Architectural Awareness */

'''Strengths and Weaknesses of Distributed Version Control'''

== Introduction ==

A version control system is a software package that allows developers to record and track how the source code for a project changes over time. Typically each change is recorded in some form of database along with who made the change and perhaps a description of what the change was or why it was made.

Because each change is recorded it is easy to compare the current version of a particular source file with any older version. It is also possible to restore any source file to the state it was at a particular time in the past which can be useful if a change in a particular file breaks part of the project and needs to be undone.

=== Centralized Version Control ===

Traditionally version control systems like [http://www.nongnu.org/cvs/ CVS] and [http://subversion.tigris.org/ Subversion] have relied on each developer having access to a central server that holds the source code repository for the project. The repository contains a complete copy of all of the files in the project along with all of the changes that have been made to each file since it was first added to the project.

When a new file needs to be added, the developer connects to the server with the repository and checks in the new file. When a developer wants to make a change to a file, he or she is usually expected to connect to the server and retrieve the current version of the file. The developer then makes the changes and checks in the file to the repository. This records the changes that were made and makes them available to the other developers working on the project.

=== Distributed Version Control ===

A new type of version control system called distributed version control has become popular in recent years. Distributed version control systems do not require a central server to maintain the repository for a project. Instead each developer working on the project has his or her own repository located on their workstation.

Any changes a developer makes to a file are tracked in the developer’s own repository. Each change is given a unique identifier. When the developer A wants to share his or her changes with other developers they can either push the changes directly to the other developer’s repository or they can ask the other developers to retrieve the changes directly from developer A’s repository.

== Advantages of Distributed Version Control Systems ==

=== No network connectivity required ===

One of the more obvious advantages of a distributed system is the fact that developers do not need a network connection and access to a central repository while they are working on a project. Since each developer has his or her own repository they can work on changes without any form of connectivity. All changes are committed to the developer’s local repository and can be shared later whenever the developer has a connection to other developers.

=== Changes can be kept private while preserving change history ===

Developers often want to keep their changes private until they are done working on them and are ready to share them. In a traditional centralized version control system this can result in a developer checking in a large number of changes as a single revision rather than doing incremental check ins for each change. This results in much of the change history being completely lost.

In a distributed system the entire change history is stored in the developer’s local repository. When the developer shares his or her changes with other developers they also have access to the history for those files that are involved in the change. This allows the complete change history to be preserved for each file in the project while still giving the developer control over when they share their changes.

=== Project managers do not need to grant permission to developers ===

In a centralized version control system the project managers often have to grant each developer access to the repository before they can begin to make changes. In a distributed system this is not necessary because a new developer only needs a reasonably current copy of the source code of a project to begin to make changes. Once the developer is ready to share his or her changes they can send them to other developers who can then choose to either accept the changes into their own repositories or reject them.

=== No single point of failure ===

In a centralized version control system if the server with the repository fails or becomes unavailable then developers can not check in new changes or retrieve the change history of anything in the project. In a distributed system if a repository goes down everyone can continue to work without any problems because everything is stored in their local repository. If their local repository becomes corrupted or destroyed, they can simply get a new copy of the repository (perhaps from another developer) and continue working.

== Disadvantages of Distributed Version Control Systems ==

=== Security ===

Sometimes it is desirable to be able to prevent certain developers from accessing certain sections of a project, particularly in a commercial development project. In a centralized system this can be accomplished by having the server only allow access to those parts of the project that the project managers have defined for each developer. In a distributed version control system it is very hard to do this because developers can share changes with each other and there is no easy way to determine what sections of a project a developer may have in his or her repository.

=== Conflict Resolution ===

In any version control system there will be the need for conflict resolution. If more than one developer makes changes to a single file in a project at approximately the same time a conflict can occur. Someone must compare the various versions of the file and merge the changes into a single new version before it can be checked in.

In a distributed version control system each developer is working from their own repository; so conflicts are somewhat more likely to occur than in a centralized system. Fortunately, most distributed version control systems are capable of automatically resolving the conflict when a change is shared. When a conflict must be resolved manually, the resulting merged changes can then be easily shared with the other developers working on the project.

=== Architectural Awareness ===

Distributed version control systems allow for great flexibility when choosing how changes should be shared. A distributed version control system can be completely decentralized and changes shared in a peer-to-peer fashion or it can resemble a centralized system, or a mixture of the two.

Different developers will have different changes in their repositories and it may be necessary to connect to the repositories of multiple developers to retrieve the latest version of each file. This can make retrieving a current copy of the source files for a project a bit more difficult especially if the files are being collected to make a release build for the project.

However, it is possible to set up a central repository that developers can send their changes to when they are ready to share them. This allows developers to take advantage of being able to work “offline” from the central repository and share changes directly with other developers while still maintaining a central location where changes can be checked in once the developer is happy with them.

Yet another possibility is for project leaders to set up a central repository but only allow project leaders to send changes to it. In this architecture the project leaders receive changes from the developers and choose whether or not to send them on to the central repository.

In a centralized system, the developer knows that all changes are checked in to a single repository and the latest files are always in the repository. When using a distributed system, developers must be aware of the overall architecture used by the project to ensure they share their changes in the expected way. A developer must learn whether he or she is expected to send changes to a central repository or if they must be sent to someone else for approval. Some projects may not use a central repository at all and may simply require each developer to send changes to all of the other developers in the project.

== Conclusion ==

Distributed version control systems are becoming very popular among development teams and I believe the primary reason for this is the fact that a distributed system can be set up to resemble virtually any architecture imaginable. Development teams can even set them up to act much like a centralized system while still retaining some of the advantages of a distributed system such as being able to work while disconnected from the repository; and being able to preserve change history even when a large group of changes is checked in all at once to a central repository (as long as the developer checked in each change incrementally to his or her own repository.)

Unless a project needs to have tight control over which developers can access certain areas of the project there is little reason for a development team to use a centralized version control system instead of a distributed version control system. However, cooperation between developers is essential for any project.

Some may see distributed version control systems as encouraging developers to work alone with little contact with other team members and only share their changes when they are finished. This can cause problems if the other team members disagree with the changes or how they were implemented. Proper planning and communication can go a long way to prevent this from happening in a project.

== Common Distributed Version Control Systems ==

* [http://www.gnu.org/software/gnu-arch/ GNU arch]
* [http://monotone.ca/ Monotone]
* [http://darcs.net/ Darcs]
* [http://bazaar-vcs.org/ Bazaar]
* [http://mercurial.selenic.com/wiki/ Mercurial]
* [http://git-scm.com/ Git]

== References ==

* [http://portal.acm.org.www.lib.ncsu.edu:2048/citation.cfm?id=1572211 Why Are Software Projects Moving From Centralized to Decentralized Version Control Systems?]

* [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control]

* [http://blog.red-bean.com/sussman/?p=20 The Risks of Distributed Version Control]

* [http://blog.ianbicking.org/distributed-vs-centralized-scm.html Distributed vs. Centralized Version Control]

* [http://arstechnica.com/staff/cohortes-vigilum/2009/03/distributed-version-control-to-the-rescue.ars Distributed version control to the rescue!]

CSC/ECE 517 Fall 2009/wiki1a 3 ve

2009-09-12T22:02:37Z

Wbosborn: /* References */

'''Strengths and Weaknesses of Distributed Version Control'''

== Introduction ==

A version control system is a software package that allows developers to record and track how the source code for a project changes over time. Typically each change is recorded in some form of database along with who made the change and perhaps a description of what the change was or why it was made.

Because each change is recorded it is easy to compare the current version of a particular source file with any older version. It is also possible to restore any source file to the state it was at a particular time in the past which can be useful if a change in a particular file breaks part of the project and needs to be undone.

=== Centralized Version Control ===

Traditionally version control systems like [http://www.nongnu.org/cvs/ CVS] and [http://subversion.tigris.org/ Subversion] have relied on each developer having access to a central server that holds the source code repository for the project. The repository contains a complete copy of all of the files in the project along with all of the changes that have been made to each file since it was first added to the project.

When a new file needs to be added, the developer connects to the server with the repository and checks in the new file. When a developer wants to make a change to a file, he or she is usually expected to connect to the server and retrieve the current version of the file. The developer then makes the changes and checks in the file to the repository. This records the changes that were made and makes them available to the other developers working on the project.

=== Distributed Version Control ===

A new type of version control system called distributed version control has become popular in recent years. Distributed version control systems do not require a central server to maintain the repository for a project. Instead each developer working on the project has his or her own repository located on their workstation.

Any changes a developer makes to a file are tracked in the developer’s own repository. Each change is given a unique identifier. When the developer A wants to share his or her changes with other developers they can either push the changes directly to the other developer’s repository or they can ask the other developers to retrieve the changes directly from developer A’s repository.

== Advantages of Distributed Version Control Systems ==

=== No network connectivity required ===

One of the more obvious advantages of a distributed system is the fact that developers do not need a network connection and access to a central repository while they are working on a project. Since each developer has his or her own repository they can work on changes without any form of connectivity. All changes are committed to the developer’s local repository and can be shared later whenever the developer has a connection to other developers.

=== Changes can be kept private while preserving change history ===

Developers often want to keep their changes private until they are done working on them and are ready to share them. In a traditional centralized version control system this can result in a developer checking in a large number of changes as a single revision rather than doing incremental check ins for each change. This results in much of the change history being completely lost.

In a distributed system the entire change history is stored in the developer’s local repository. When the developer shares his or her changes with other developers they also have access to the history for those files that are involved in the change. This allows the complete change history to be preserved for each file in the project while still giving the developer control over when they share their changes.

=== Project managers do not need to grant permission to developers ===

In a centralized version control system the project managers often have to grant each developer access to the repository before they can begin to make changes. In a distributed system this is not necessary because a new developer only needs a reasonably current copy of the source code of a project to begin to make changes. Once the developer is ready to share his or her changes they can send them to other developers who can then choose to either accept the changes into their own repositories or reject them.

=== No single point of failure ===

In a centralized version control system if the server with the repository fails or becomes unavailable then developers can not check in new changes or retrieve the change history of anything in the project. In a distributed system if a repository goes down everyone can continue to work without any problems because everything is stored in their local repository. If their local repository becomes corrupted or destroyed, they can simply get a new copy of the repository (perhaps from another developer) and continue working.

== Disadvantages of Distributed Version Control Systems ==

=== Security ===

Sometimes it is desirable to be able to prevent certain developers from accessing certain sections of a project, particularly in a commercial development project. In a centralized system this can be accomplished by having the server only allow access to those parts of the project that the project managers have defined for each developer. In a distributed version control system it is very hard to do this because developers can share changes with each other and there is no easy way to determine what sections of a project a developer may have in his or her repository.

=== Conflict Resolution ===

In any version control system there will be the need for conflict resolution. If more than one developer makes changes to a single file in a project at approximately the same time a conflict can occur. Someone must compare the various versions of the file and merge the changes into a single new version before it can be checked in.

In a distributed version control system each developer is working from their own repository; so conflicts are somewhat more likely to occur than in a centralized system. Fortunately, most distributed version control systems are capable of automatically resolving the conflict when a change is shared. When a conflict must be resolved manually, the resulting merged changes can then be easily shared with the other developers working on the project.

=== Architectural Awareness ===

Distributed version control systems allow for great flexibility when choosing how changes should be shared. A distributed version control system can be completely decentralized and changes shared in a pear-to-pear fashion or it can resemble a centralized system, or a mixture of the two.

Different developers will have different changes in their repositories and it may be necessary to connect to the repositories of multiple developers to retrieve the latest version of each file. This can make retrieving a current copy of the source files for a project a bit more difficult especially if the files are being collected to make a release build for the project.

However, it is possible to set up a central repository that developers can send their changes to when they are ready to share them. This allows developers to take advantage of being able to work “offline” from the central repository and share changes directly with other developers while still maintaining a central location where changes can be checked in once the developer is happy with them.

Yet another possibility is for project leaders to set up a central repository but only allow project leaders to send changes to it. In this architecture the project leaders receive changes from the developers and choose whether or not to send them on to the central repository.

In a centralized system, the developer knows that all changes are checked in to a single repository and the latest files are always in the repository. When using a distributed system, developers must be aware of the overall architecture used by the project to ensure they share their changes in the expected way. A developer must learn whether he or she is expected to send changes to a central repository or if they must be sent to someone else for approval. Some projects may not use a central repository at all and may simply require each developer to send changes to all of the other developers in the project.

== Conclusion ==

Distributed version control systems are becoming very popular among development teams and I believe the primary reason for this is the fact that a distributed system can be set up to resemble virtually any architecture imaginable. Development teams can even set them up to act much like a centralized system while still retaining some of the advantages of a distributed system such as being able to work while disconnected from the repository; and being able to preserve change history even when a large group of changes is checked in all at once to a central repository (as long as the developer checked in each change incrementally to his or her own repository.)

Unless a project needs to have tight control over which developers can access certain areas of the project there is little reason for a development team to use a centralized version control system instead of a distributed version control system. However, cooperation between developers is essential for any project.

Some may see distributed version control systems as encouraging developers to work alone with little contact with other team members and only share their changes when they are finished. This can cause problems if the other team members disagree with the changes or how they were implemented. Proper planning and communication can go a long way to prevent this from happening in a project.

== Common Distributed Version Control Systems ==

* [http://www.gnu.org/software/gnu-arch/ GNU arch]
* [http://monotone.ca/ Monotone]
* [http://darcs.net/ Darcs]
* [http://bazaar-vcs.org/ Bazaar]
* [http://mercurial.selenic.com/wiki/ Mercurial]
* [http://git-scm.com/ Git]

== References ==

* [http://portal.acm.org.www.lib.ncsu.edu:2048/citation.cfm?id=1572211 Why Are Software Projects Moving From Centralized to Decentralized Version Control Systems?]

* [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control]

* [http://blog.red-bean.com/sussman/?p=20 The Risks of Distributed Version Control]

* [http://blog.ianbicking.org/distributed-vs-centralized-scm.html Distributed vs. Centralized Version Control]

* [http://arstechnica.com/staff/cohortes-vigilum/2009/03/distributed-version-control-to-the-rescue.ars Distributed version control to the rescue!]

CSC/ECE 517 Fall 2009/wiki1a 3 ve

2009-09-12T22:02:24Z

Wbosborn:

'''Strengths and Weaknesses of Distributed Version Control'''

== Introduction ==

A version control system is a software package that allows developers to record and track how the source code for a project changes over time. Typically each change is recorded in some form of database along with who made the change and perhaps a description of what the change was or why it was made.

Because each change is recorded it is easy to compare the current version of a particular source file with any older version. It is also possible to restore any source file to the state it was at a particular time in the past which can be useful if a change in a particular file breaks part of the project and needs to be undone.

=== Centralized Version Control ===

Traditionally version control systems like [http://www.nongnu.org/cvs/ CVS] and [http://subversion.tigris.org/ Subversion] have relied on each developer having access to a central server that holds the source code repository for the project. The repository contains a complete copy of all of the files in the project along with all of the changes that have been made to each file since it was first added to the project.

When a new file needs to be added, the developer connects to the server with the repository and checks in the new file. When a developer wants to make a change to a file, he or she is usually expected to connect to the server and retrieve the current version of the file. The developer then makes the changes and checks in the file to the repository. This records the changes that were made and makes them available to the other developers working on the project.

=== Distributed Version Control ===

A new type of version control system called distributed version control has become popular in recent years. Distributed version control systems do not require a central server to maintain the repository for a project. Instead each developer working on the project has his or her own repository located on their workstation.

Any changes a developer makes to a file are tracked in the developer’s own repository. Each change is given a unique identifier. When the developer A wants to share his or her changes with other developers they can either push the changes directly to the other developer’s repository or they can ask the other developers to retrieve the changes directly from developer A’s repository.

== Advantages of Distributed Version Control Systems ==

=== No network connectivity required ===

One of the more obvious advantages of a distributed system is the fact that developers do not need a network connection and access to a central repository while they are working on a project. Since each developer has his or her own repository they can work on changes without any form of connectivity. All changes are committed to the developer’s local repository and can be shared later whenever the developer has a connection to other developers.

=== Changes can be kept private while preserving change history ===

Developers often want to keep their changes private until they are done working on them and are ready to share them. In a traditional centralized version control system this can result in a developer checking in a large number of changes as a single revision rather than doing incremental check ins for each change. This results in much of the change history being completely lost.

In a distributed system the entire change history is stored in the developer’s local repository. When the developer shares his or her changes with other developers they also have access to the history for those files that are involved in the change. This allows the complete change history to be preserved for each file in the project while still giving the developer control over when they share their changes.

=== Project managers do not need to grant permission to developers ===

In a centralized version control system the project managers often have to grant each developer access to the repository before they can begin to make changes. In a distributed system this is not necessary because a new developer only needs a reasonably current copy of the source code of a project to begin to make changes. Once the developer is ready to share his or her changes they can send them to other developers who can then choose to either accept the changes into their own repositories or reject them.

=== No single point of failure ===

In a centralized version control system if the server with the repository fails or becomes unavailable then developers can not check in new changes or retrieve the change history of anything in the project. In a distributed system if a repository goes down everyone can continue to work without any problems because everything is stored in their local repository. If their local repository becomes corrupted or destroyed, they can simply get a new copy of the repository (perhaps from another developer) and continue working.

== Disadvantages of Distributed Version Control Systems ==

=== Security ===

Sometimes it is desirable to be able to prevent certain developers from accessing certain sections of a project, particularly in a commercial development project. In a centralized system this can be accomplished by having the server only allow access to those parts of the project that the project managers have defined for each developer. In a distributed version control system it is very hard to do this because developers can share changes with each other and there is no easy way to determine what sections of a project a developer may have in his or her repository.

=== Conflict Resolution ===

In any version control system there will be the need for conflict resolution. If more than one developer makes changes to a single file in a project at approximately the same time a conflict can occur. Someone must compare the various versions of the file and merge the changes into a single new version before it can be checked in.

In a distributed version control system each developer is working from their own repository; so conflicts are somewhat more likely to occur than in a centralized system. Fortunately, most distributed version control systems are capable of automatically resolving the conflict when a change is shared. When a conflict must be resolved manually, the resulting merged changes can then be easily shared with the other developers working on the project.

=== Architectural Awareness ===

Distributed version control systems allow for great flexibility when choosing how changes should be shared. A distributed version control system can be completely decentralized and changes shared in a pear-to-pear fashion or it can resemble a centralized system, or a mixture of the two.

Different developers will have different changes in their repositories and it may be necessary to connect to the repositories of multiple developers to retrieve the latest version of each file. This can make retrieving a current copy of the source files for a project a bit more difficult especially if the files are being collected to make a release build for the project.

However, it is possible to set up a central repository that developers can send their changes to when they are ready to share them. This allows developers to take advantage of being able to work “offline” from the central repository and share changes directly with other developers while still maintaining a central location where changes can be checked in once the developer is happy with them.

Yet another possibility is for project leaders to set up a central repository but only allow project leaders to send changes to it. In this architecture the project leaders receive changes from the developers and choose whether or not to send them on to the central repository.

In a centralized system, the developer knows that all changes are checked in to a single repository and the latest files are always in the repository. When using a distributed system, developers must be aware of the overall architecture used by the project to ensure they share their changes in the expected way. A developer must learn whether he or she is expected to send changes to a central repository or if they must be sent to someone else for approval. Some projects may not use a central repository at all and may simply require each developer to send changes to all of the other developers in the project.

== Conclusion ==

Distributed version control systems are becoming very popular among development teams and I believe the primary reason for this is the fact that a distributed system can be set up to resemble virtually any architecture imaginable. Development teams can even set them up to act much like a centralized system while still retaining some of the advantages of a distributed system such as being able to work while disconnected from the repository; and being able to preserve change history even when a large group of changes is checked in all at once to a central repository (as long as the developer checked in each change incrementally to his or her own repository.)

Unless a project needs to have tight control over which developers can access certain areas of the project there is little reason for a development team to use a centralized version control system instead of a distributed version control system. However, cooperation between developers is essential for any project.

Some may see distributed version control systems as encouraging developers to work alone with little contact with other team members and only share their changes when they are finished. This can cause problems if the other team members disagree with the changes or how they were implemented. Proper planning and communication can go a long way to prevent this from happening in a project.

== Common Distributed Version Control Systems ==

* [http://www.gnu.org/software/gnu-arch/ GNU arch]
* [http://monotone.ca/ Monotone]
* [http://darcs.net/ Darcs]
* [http://bazaar-vcs.org/ Bazaar]
* [http://mercurial.selenic.com/wiki/ Mercurial]
* [http://git-scm.com/ Git]

== References ==

* [http://portal.acm.org.www.lib.ncsu.edu:2048/citation.cfm?id=1572211 Why Are Software Projects Moving From Centralized to Decentralized Version Control Systems?]

* [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control]

* [http://blog.red-bean.com/sussman/?p=20 The Risks of Distributed Version Control]

* [http://blog.ianbicking.org/distributed-vs-centralized-scm.html Distributed vs. Centralized Version Control]

* [http://arstechnica.com/staff/cohortes-vigilum/2009/03/distributed-version-control-to-the-rescue.ars Distributed version control to the rescue!]

* [http://example.net Example]

CSC/ECE 517 Fall 2009/wiki1a 3 ve

2009-09-11T19:34:47Z

Wbosborn:

'''Strengths and Weaknesses of Distributed Version Control'''

== Introduction ==

A version control system is a software package that allows developers to record and track how the source code for a project changes over time. Typically each change is recorded in some form of database along with who made the change and perhaps a description of what the change was or why it was made.

Because each change is recorded it is easy to compare the current version of a particular source file with any older version. It is also possible to restore any source file to the state it was at a particular time in the past which can be useful if a change in a particular file breaks part of the project and needs to be undone.

=== Centralized Version Control ===

Traditionally version control systems like [http://www.nongnu.org/cvs/ CVS] and [http://subversion.tigris.org/ Subversion] have relied on each developer having access to a central server that holds the source code repository for the project. The repository contains a complete copy of all of the files in the project along with all of the changes that have been made to each file since it was first added to the project.

When a new file needs to be added, the developer connects to the server with the repository and checks in the new file. When a developer wants to make a change to a file, he or she is usually expected to connect to the server and retrieve the current version of the file. The developer then makes the changes and checks in the file to the repository. This records the changes that were made and makes them available to the other developers working on the project.

=== Distributed Version Control ===

A new type of version control system called distributed version control has become popular in recent years. Distributed version control systems do not require a central server to maintain the repository for a project. Instead each developer working on the project has his or her own repository located on their workstation.

Any changes a developer makes to a file are tracked in the developer’s own repository. Each change is given a unique identifier. When the developer A wants to share his or her changes with other developers they can either push the changes directly to the other developer’s repository or they can ask the other developers to retrieve the changes directly from developer A’s repository.

== Advantages of Distributed Version Control Systems ==

=== No network connectivity required ===

One of the more obvious advantages of a distributed system is the fact that developers do not need a network connection and access to a central repository while they are working on a project. Since each developer has his or her own repository they can work on changes without any form of connectivity. All changes are committed to the developer’s local repository and can be shared later whenever the developer has a connection to other developers.

=== Changes can be kept private while preserving change history ===

Developers often want to keep their changes private until they are done working on them and are ready to share them. In a traditional centralized version control system this can result in a developer checking in a large number of changes as a single revision rather than doing incremental check ins for each change. This results in much of the change history being completely lost.

In a distributed system the entire change history is stored in the developer’s local repository. When the developer shares his or her changes with other developers they also have access to the history for those files that are involved in the change. This allows the complete change history to be preserved for each file in the project while still giving the developer control over when they share their changes.

=== Project managers do not need to grant permission to developers ===

In a centralized version control system the project managers often have to grant each developer access to the repository before they can begin to make changes. In a distributed system this is not necessary because a new developer only needs a reasonably current copy of the source code of a project to begin to make changes. Once the developer is ready to share his or her changes they can send them to other developers who can then choose to either accept the changes into their own repositories or reject them.

=== No single point of failure ===

In a centralized version control system if the server with the repository fails or becomes unavailable then developers can not check in new changes or retrieve the change history of anything in the project. In a distributed system if a repository goes down everyone can continue to work without any problems because everything is stored in their local repository. If their local repository becomes corrupted or destroyed, they can simply get a new copy of the repository (perhaps from another developer) and continue working.

== Disadvantages of Distributed Version Control Systems ==

=== Security ===

Sometimes it is desirable to be able to prevent certain developers from accessing certain sections of a project, particularly in a commercial development project. In a centralized system this can be accomplished by having the server only allow access to those parts of the project that the project managers have defined for each developer. In a distributed version control system it is very hard to do this because developers can share changes with each other and there is no easy way to determine what sections of a project a developer may have in his or her repository.

=== Conflict Resolution ===

In any version control system there will be the need for conflict resolution. If more than one developer makes changes to a single file in a project at approximately the same time a conflict can occur. Someone must compare the various versions of the file and merge the changes into a single new version before it can be checked in.

In a distributed version control system each developer is working from their own repository; so conflicts are somewhat more likely to occur than in a centralized system. Fortunately, most distributed version control systems are capable of automatically resolving the conflict when a change is shared. When a conflict must be resolved manually, the resulting merged changes can then be easily shared with the other developers working on the project.

=== Architectural Awareness ===

Distributed version control systems allow for great flexibility when choosing how changes should be shared. A distributed version control system can be completely decentralized and changes shared in a pear-to-pear fashion or it can resemble a centralized system, or a mixture of the two.

Different developers will have different changes in their repositories and it may be necessary to connect to the repositories of multiple developers to retrieve the latest version of each file. This can make retrieving a current copy of the source files for a project a bit more difficult especially if the files are being collected to make a release build for the project.

However, it is possible to set up a central repository that developers can send their changes to when they are ready to share them. This allows developers to take advantage of being able to work “offline” from the central repository and share changes directly with other developers while still maintaining a central location where changes can be checked in once the developer is happy with them.

Yet another possibility is for project leaders to set up a central repository but only allow project leaders to send changes to it. In this architecture the project leaders receive changes from the developers and choose whether or not to send them on to the central repository.

In a centralized system, the developer knows that all changes are checked in to a single repository and the latest files are always in the repository. When using a distributed system, developers must be aware of the overall architecture used by the project to ensure they share their changes in the expected way. A developer must learn whether he or she is expected to send changes to a central repository or if they must be sent to someone else for approval. Some projects may not use a central repository at all and may simply require each developer to send changes to all of the other developers in the project.

== Conclusion ==

Distributed version control systems are becoming very popular among development teams and I believe the primary reason for this is the fact that a distributed system can be set up to resemble virtually any architecture imaginable. Development teams can even set them up to act much like a centralized system while still retaining some of the advantages of a distributed system such as being able to work while disconnected from the repository; and being able to preserve change history even when a large group of changes is checked in all at once to a central repository (as long as the developer checked in each change incrementally to his or her own repository.)

Unless a project needs to have tight control over which developers can access certain areas of the project there is little reason for a development team to use a centralized version control system instead of a distributed version control system. However, cooperation between developers is essential for any project.

Some may see distributed version control systems as encouraging developers to work alone with little contact with other team members and only share their changes when they are finished. This can cause problems if the other team members disagree with the changes or how they were implemented. Proper planning and communication can go a long way to prevent this from happening in a project.

== Common Distributed Version Control Systems ==

* [http://www.gnu.org/software/gnu-arch/ GNU arch]
* [http://monotone.ca/ Monotone]
* [http://darcs.net/ Darcs]
* [http://bazaar-vcs.org/ Bazaar]
* [http://mercurial.selenic.com/wiki/ Mercurial]
* [http://git-scm.com/ Git]

== References ==

* [http://portal.acm.org.www.lib.ncsu.edu:2048/citation.cfm?id=1572211 Why Are Software Projects Moving From Centralized to Decentralized Version Control Systems?]

* [http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ Intro to Distributed Version Control]

* [http://blog.red-bean.com/sussman/?p=20 The Risks of Distributed Version Control]

* [http://blog.ianbicking.org/distributed-vs-centralized-scm.html Distributed vs. Centralized Version Control]

* [http://arstechnica.com/staff/cohortes-vigilum/2009/03/distributed-version-control-to-the-rescue.ars Distributed version control to the rescue!]

CSC/ECE 506 Fall 2007/wiki2 6 cv

2007-09-28T13:25:50Z

Wbosborn: /* Overview of the MSIMD Architecture */

== Overview of the MSIMD Architecture ==
A MSIMD machine is usually designed around a group of processors that act as control units for a larger number of processors that operate on single-instruction multiple-data streams. Each control processor controls it’s assigned group of SIMD processors. Such a machine is capable of operating on multiple single-instruction multiple-data streams simultaneously. Some MSIMD machines can also change the number of processors assigned to each control unit dynamically based on the needs of the application that is currently running on the system. ([http://www.lib.ncsu.edu:2178/iel5/32/35923/01702859.pdf?tp=&arnumber=1702859&isnumber=35923 Performance Modeling of Shared-Resource-Array Processors])

== Applications ==
The unique design properties of a MSIMD machine allow it to achieve a high level of efficiency when solving certain types of problems. Some examples of such problems are described below:

=== Identifying Features in Images ===
In this application, the goal is to determine whether or not an object or a group of objects exists in an image. If the object exists, its position may also be determined. Different algorithms can detect different shapes, so it is quite common to combine use multiple algorithms or filters to process the same image in order to identify all of the target objects.
One way this application can be designed to run on a MSIMD machine is by assigning each control processor a region of the image. Each cluster of SIMD processors then works on the resign of the image that it was assigned. Each control can communicate with adjacent controls in the event that one or more of the target objects spans multiple regions of the image. ([http://www.lib.ncsu.edu:2178/iel3/1599/4340/00168054.pdf?tp=&arnumber=168054&isnumber=4340 An MSIMD Architecture for Feature Tracking])

=== Simulation of 3D vision using 2D images ===
In this application, the goal is to identify 3D objects by combining two or more 2D images of the same location. Each 2D image used is offset from the others to provide a slightly different angle to the scene/environment. This process is modeled after how humans identify 3D objects by combining the 2D images from both eyes.
One technique for solving this problem is by simulating how the neurons in a brain work. A MSIMD machine allows each cluster of SIMD processors to simulate a different neuron which allows multiple neurons to be simulated simultaneously. The equations that are used to simulate each neuron can often be divided into multiple parts and each part assigned to a SIMD processor. This allows the problem to achieve a very high level of parallelism on a MSIMD machine. ([http://www.lib.ncsu.edu:2178/iel2/684/6475/00255272.pdf?tp=&arnumber=255272&isnumber=6475 3-D Wafer Stack Neurocomputing])

== External Links ==
[http://www.lib.ncsu.edu:2178/iel5/32/35923/01702859.pdf?tp=&arnumber=1702859&isnumber=35923 Performance Modeling of Shared-Resource-Array Processors] 
[http://www.lib.ncsu.edu:2178/iel3/1599/4340/00168054.pdf?tp=&arnumber=168054&isnumber=4340 An MSIMD Architecture for Feature Tracking] 
[http://www.lib.ncsu.edu:2178/iel2/684/6475/00255272.pdf?tp=&arnumber=255272&isnumber=6475 3-D Wafer Stack Neurocomputing] 

[[User:Wbosborn|wbosborn]] 14:06, 24 September 2007 (EDT)

CSC/ECE 506 Fall 2007/wiki2 6 cv

2007-09-28T13:24:46Z

Wbosborn: /* Overview of the MSIMD Architecture */

== Overview of the MSIMD Architecture ==
A MSIMD machine is usually designed around a group of processors that act as control units for a larger number of processors that operate on single-instruction multiple-data streams. Each control processor controls it’s assigned group of SIMD processors. Such a machine is capable of operating on multiple single-instruction multiple-data streams simultaneously. Some such machines can also change the number of processors assigned to each control unit dynamically based on the needs of the application that is currently running on the system. ([http://www.lib.ncsu.edu:2178/iel5/32/35923/01702859.pdf?tp=&arnumber=1702859&isnumber=35923 Performance Modeling of Shared-Resource-Array Processors])

== Applications ==
The unique design properties of a MSIMD machine allow it to achieve a high level of efficiency when solving certain types of problems. Some examples of such problems are described below:

=== Identifying Features in Images ===
In this application, the goal is to determine whether or not an object or a group of objects exists in an image. If the object exists, its position may also be determined. Different algorithms can detect different shapes, so it is quite common to combine use multiple algorithms or filters to process the same image in order to identify all of the target objects.
One way this application can be designed to run on a MSIMD machine is by assigning each control processor a region of the image. Each cluster of SIMD processors then works on the resign of the image that it was assigned. Each control can communicate with adjacent controls in the event that one or more of the target objects spans multiple regions of the image. ([http://www.lib.ncsu.edu:2178/iel3/1599/4340/00168054.pdf?tp=&arnumber=168054&isnumber=4340 An MSIMD Architecture for Feature Tracking])

=== Simulation of 3D vision using 2D images ===
In this application, the goal is to identify 3D objects by combining two or more 2D images of the same location. Each 2D image used is offset from the others to provide a slightly different angle to the scene/environment. This process is modeled after how humans identify 3D objects by combining the 2D images from both eyes.
One technique for solving this problem is by simulating how the neurons in a brain work. A MSIMD machine allows each cluster of SIMD processors to simulate a different neuron which allows multiple neurons to be simulated simultaneously. The equations that are used to simulate each neuron can often be divided into multiple parts and each part assigned to a SIMD processor. This allows the problem to achieve a very high level of parallelism on a MSIMD machine. ([http://www.lib.ncsu.edu:2178/iel2/684/6475/00255272.pdf?tp=&arnumber=255272&isnumber=6475 3-D Wafer Stack Neurocomputing])

== External Links ==
[http://www.lib.ncsu.edu:2178/iel5/32/35923/01702859.pdf?tp=&arnumber=1702859&isnumber=35923 Performance Modeling of Shared-Resource-Array Processors] 
[http://www.lib.ncsu.edu:2178/iel3/1599/4340/00168054.pdf?tp=&arnumber=168054&isnumber=4340 An MSIMD Architecture for Feature Tracking] 
[http://www.lib.ncsu.edu:2178/iel2/684/6475/00255272.pdf?tp=&arnumber=255272&isnumber=6475 3-D Wafer Stack Neurocomputing] 

[[User:Wbosborn|wbosborn]] 14:06, 24 September 2007 (EDT)

CSC/ECE 506 Fall 2007/wiki2 6 cv

2007-09-24T18:07:01Z

Wbosborn:

== Overview of the MSIMD Architecture ==
A MSIMD machine is usually designed around a group of processors that act as control units for a larger number of processors that operate on single-instruction multiple-data streams. Each control processor controls its assigned a group of the SIMD processors. Such a machine is capable of operating on multiple single-instruction multiple-data streams simultaneously. Some such machines can also change the number of processors assigned to each control unit dynamically based on the needs of the application that is currently running on the system. ([http://www.lib.ncsu.edu:2178/iel5/32/35923/01702859.pdf?tp=&arnumber=1702859&isnumber=35923 Performance Modeling of Shared-Resource-Array Processors])

== Applications ==
The unique design properties of a MSIMD machine allow it to achieve a high level of efficiency when solving certain types of problems. Some examples of such problems are described below:

=== Identifying Features in Images ===
In this application, the goal is to determine whether or not an object or a group of objects exists in an image. If the object exists, its position may also be determined. Different algorithms can detect different shapes, so it is quite common to combine use multiple algorithms or filters to process the same image in order to identify all of the target objects.
One way this application can be designed to run on a MSIMD machine is by assigning each control processor a region of the image. Each cluster of SIMD processors then works on the resign of the image that it was assigned. Each control can communicate with adjacent controls in the event that one or more of the target objects spans multiple regions of the image. ([http://www.lib.ncsu.edu:2178/iel3/1599/4340/00168054.pdf?tp=&arnumber=168054&isnumber=4340 An MSIMD Architecture for Feature Tracking])

=== Simulation of 3D vision using 2D images ===
In this application, the goal is to identify 3D objects by combining two or more 2D images of the same location. Each 2D image used is offset from the others to provide a slightly different angle to the scene/environment. This process is modeled after how humans identify 3D objects by combining the 2D images from both eyes.
One technique for solving this problem is by simulating how the neurons in a brain work. A MSIMD machine allows each cluster of SIMD processors to simulate a different neuron which allows multiple neurons to be simulated simultaneously. The equations that are used to simulate each neuron can often be divided into multiple parts and each part assigned to a SIMD processor. This allows the problem to achieve a very high level of parallelism on a MSIMD machine. ([http://www.lib.ncsu.edu:2178/iel2/684/6475/00255272.pdf?tp=&arnumber=255272&isnumber=6475 3-D Wafer Stack Neurocomputing])

== External Links ==
[http://www.lib.ncsu.edu:2178/iel5/32/35923/01702859.pdf?tp=&arnumber=1702859&isnumber=35923 Performance Modeling of Shared-Resource-Array Processors] 
[http://www.lib.ncsu.edu:2178/iel3/1599/4340/00168054.pdf?tp=&arnumber=168054&isnumber=4340 An MSIMD Architecture for Feature Tracking] 
[http://www.lib.ncsu.edu:2178/iel2/684/6475/00255272.pdf?tp=&arnumber=255272&isnumber=6475 3-D Wafer Stack Neurocomputing] 

[[User:Wbosborn|wbosborn]] 14:06, 24 September 2007 (EDT)

CSC/ECE 506 Fall 2007/wiki2 6 cv

2007-09-24T18:06:27Z

Wbosborn:

== Overview of the MSIMD Architecture ==
A MSIMD machine is usually designed around a group of processors that act as control units for a larger number of processors that operate on single-instruction multiple-data streams. Each control processor controls its assigned a group of the SIMD processors. Such a machine is capable of operating on multiple single-instruction multiple-data streams simultaneously. Some such machines can also change the number of processors assigned to each control unit dynamically based on the needs of the application that is currently running on the system. ([http://www.lib.ncsu.edu:2178/iel5/32/35923/01702859.pdf?tp=&arnumber=1702859&isnumber=35923 Performance Modeling of Shared-Resource-Array Processors])

== Applications ==
The unique design properties of a MSIMD machine allow it to achieve a high level of efficiency when solving certain types of problems. Some examples of such problems are described below:

=== Identifying Features in Images ===
In this application, the goal is to determine whether or not an object or a group of objects exists in an image. If the object exists, its position may also be determined. Different algorithms can detect different shapes, so it is quite common to combine use multiple algorithms or filters to process the same image in order to identify all of the target objects.
One way this application can be designed to run on a MSIMD machine is by assigning each control processor a region of the image. Each cluster of SIMD processors then works on the resign of the image that it was assigned. Each control can communicate with adjacent controls in the event that one or more of the target objects spans multiple regions of the image. ([http://www.lib.ncsu.edu:2178/iel3/1599/4340/00168054.pdf?tp=&arnumber=168054&isnumber=4340 An MSIMD Architecture for Feature Tracking])

=== Simulation of 3D vision using 2D images ===
In this application, the goal is to identify 3D objects by combining two or more 2D images of the same location. Each 2D image used is offset from the others to provide a slightly different angle to the scene/environment. This process is modeled after how humans identify 3D objects by combining the 2D images from both eyes.
One technique for solving this problem is by simulating how the neurons in a brain work. A MSIMD machine allows each cluster of SIMD processors to simulate a different neuron which allows multiple neurons to be simulated simultaneously. The equations that are used to simulate each neuron can often be divided into multiple parts and each part assigned to a SIMD processor. This allows the problem to achieve a very high level of parallelism on a MSIMD machine. ([http://www.lib.ncsu.edu:2178/iel2/684/6475/00255272.pdf?tp=&arnumber=255272&isnumber=6475 3-D Wafer Stack Neurocomputing])

== External Links ==
[http://www.lib.ncsu.edu:2178/iel5/32/35923/01702859.pdf?tp=&arnumber=1702859&isnumber=35923 Performance Modeling of Shared-Resource-Array Processors] 
[http://www.lib.ncsu.edu:2178/iel3/1599/4340/00168054.pdf?tp=&arnumber=168054&isnumber=4340 An MSIMD Architecture for Feature Tracking] 
[http://www.lib.ncsu.edu:2178/iel2/684/6475/00255272.pdf?tp=&arnumber=255272&isnumber=6475 3-D Wafer Stack Neurocomputing] 

[[User:Wbosborn|wbosborn]] 14:06, 24 September 2007 (EDT)

CSC/ECE 506 Fall 2007/wiki1 2 cv

2007-09-04T17:50:25Z

Wbosborn: /* Hardware used in HPC */

== High Performance Computing Trends in Scientific and Engineering Applications ==
The demand and development of High Performance Computing (HPC) systems has been primarily driven by the need to solve complex problems within a reasonable time period. These problems are found quite frequently in a wide variety of scientific and engineering fields.

The field of High Performance Computing is changing and expanding quite rapidly as new processor designs are developed and as new techniques for writing parallel applications are developed. As High Performance Computing systems become faster and more efficient, the demands placed on them also increase.

== Hardware used in High Performance Computing ==

Numerous architectures have been used throughout the history of High Performance Computing. Most modern HPC systems are based on vector processors or commodity general purpose processors.

=== Vector Processors ===

Vector processors are very efficient for certain types of problems because they are capable of performing an operation on many data elements simultaneously. However, vector systems generally cost more to design and develop because the demand for these types of processors is smaller than other types of processors. For certain types of problems, the extra performance from a system designed around vector processors is worth the extra cost. For other problems, the price difference may make other designs more desirable (http://www.csar.cfs.ac.uk/about/csarfocus/focus12/application_performance.pdf).

=== Commodity Processors ===

Many modern HPC systems are now being designed around using many commodity general purpose processors connected together using a high-speed interconnect. These types of systems typically connect large numbers of commodity computer systems together using a high speed network. The group of systems is treated as a single, high performance system known as a cluster.

Clusters built using these types of designs are generally quite cheap to design and build because they use processors and designs that are already being mass produced for use by the general public. The popularity of these designs has been steadily increasing over the past several years (http://www10.informatik.uni-erlangen.de/~deserno/HLRB2003.pdf).

Many commodity processors are now being designed with two or more processor cores on a single chip. The number of cores per chip is expected to increase with Intel demonstrating an 80 core chip in the spring of 2007 (http://www.intel.com/pressroom/archive/releases/20070204comp.htm). Using these processors in a cluster allows for a system that can have hundreds of processors for very little cost.

== Software Applications ==

High Performance Computing systems are used to solve a wide variety of scientific and engineering problems. One common use is simulating plasma physics in a three-dimensional space. Such applications commonly use the Lattice-Boltzmann method to model the flow of a fluid in a given environment.

Another common application is simulating the physics of black holes and other astronomical bodies. Some of the most demanding problems involve simulations using Einstein’s theory of General Relativity as applied to gravitational forces.

To make developing applications to solve such problems easier a few development toolkits have been designed. One such toolkit is called the Cactus Computational Toolkit (http://www.cactuscode.org/). Cactus can be used to develop applications to solve a wide variety of problems and to perform simulations. It is specifically designed to allow an application to be developed using a standard commodity system and then later run on a HPC system.

== External Links ==
[http://www.csar.cfs.ac.uk/about/csarfocus/focus12/application_performance.pdf Application Performance of Modern Number Crunchers] 
[http://www10.informatik.uni-erlangen.de/~deserno/HLRB2003.pdf Performance of Scientific Applications on Modern Supercomputers] 
[http://crd.lbl.gov/~oliker/papers/LNCS07.pdf Performance Evaluation of Scientific Applications on Modern Parallel Vector Systems] 
[http://www.intel.com/pressroom/archive/releases/20070204comp.htm Intel Research Advances 'Era Of Tera'] 
[http://www.cactuscode.org/ Cactus Computational Toolkit]

[[User:Wbosborn|Wbosborn]] 13:48, 4 September 2007 (EDT)

CSC/ECE 506 Fall 2007/wiki1 2 cv

2007-09-04T17:48:58Z

Wbosborn:

== High Performance Computing Trends in Scientific and Engineering Applications ==
The demand and development of High Performance Computing (HPC) systems has been primarily driven by the need to solve complex problems within a reasonable time period. These problems are found quite frequently in a wide variety of scientific and engineering fields.

The field of High Performance Computing is changing and expanding quite rapidly as new processor designs are developed and as new techniques for writing parallel applications are developed. As High Performance Computing systems become faster and more efficient, the demands placed on them also increase.

== Hardware used in HPC ==

Numerous architectures have been used throughout the history of High Performance Computing. Most modern HPC systems are based on vector processors or commodity general purpose processors.

=== Vector Processors ===

Vector processors are very efficient for certain types of problems because they are capable of performing an operation on many data elements simultaneously. However, vector systems generally cost more to design and develop because the demand for these types of processors is smaller than other types of processors. For certain types of problems, the extra performance from a system designed around vector processors is worth the extra cost. For other problems, the price difference may make other designs more desirable (http://www.csar.cfs.ac.uk/about/csarfocus/focus12/application_performance.pdf).

=== Commodity Processors ===

Many modern HPC systems are now being designed around using many commodity general purpose processors connected together using a high-speed interconnect. These types of systems typically connect large numbers of commodity computer systems together using a high speed network. The group of systems is treated as a single, high performance system known as a cluster.

Clusters built using these types of designs are generally quite cheap to design and build because they use processors and designs that are already being mass produced for use by the general public. The popularity of these designs has been steadily increasing over the past several years (http://www10.informatik.uni-erlangen.de/~deserno/HLRB2003.pdf).

Many commodity processors are now being designed with two or more processor cores on a single chip. The number of cores per chip is expected to increase with Intel demonstrating an 80 core chip in the spring of 2007 (http://www.intel.com/pressroom/archive/releases/20070204comp.htm). Using these processors in a cluster allows for a system that can have hundreds of processors for very little cost.

== Software Applications ==

High Performance Computing systems are used to solve a wide variety of scientific and engineering problems. One common use is simulating plasma physics in a three-dimensional space. Such applications commonly use the Lattice-Boltzmann method to model the flow of a fluid in a given environment.

Another common application is simulating the physics of black holes and other astronomical bodies. Some of the most demanding problems involve simulations using Einstein’s theory of General Relativity as applied to gravitational forces.

To make developing applications to solve such problems easier a few development toolkits have been designed. One such toolkit is called the Cactus Computational Toolkit (http://www.cactuscode.org/). Cactus can be used to develop applications to solve a wide variety of problems and to perform simulations. It is specifically designed to allow an application to be developed using a standard commodity system and then later run on a HPC system.

== External Links ==
[http://www.csar.cfs.ac.uk/about/csarfocus/focus12/application_performance.pdf Application Performance of Modern Number Crunchers] 
[http://www10.informatik.uni-erlangen.de/~deserno/HLRB2003.pdf Performance of Scientific Applications on Modern Supercomputers] 
[http://crd.lbl.gov/~oliker/papers/LNCS07.pdf Performance Evaluation of Scientific Applications on Modern Parallel Vector Systems] 
[http://www.intel.com/pressroom/archive/releases/20070204comp.htm Intel Research Advances 'Era Of Tera'] 
[http://www.cactuscode.org/ Cactus Computational Toolkit]

[[User:Wbosborn|Wbosborn]] 13:48, 4 September 2007 (EDT)