Introduction VCS
Whatever model developers follow to create softwares, there is going to be lot of code that developers write or integrate in their softwares. All this code from different developers in the team has to be merged at a centralised place, which can keep track of all the versions of their code, maintain the code and even revert back in time if anything breaks.Version control System(or revision control, or source control) is all about managing multiple versions of documents, programs, web sites, etc. A version control system (VCS) allows you to track the history of a collection of files.
Version control systems are a category of software tools that help a software team manage changes to source code over time. Version control software keeps track of every modification to the code in a special kind of database. If a mistake is made, developers can turn back the clock and compare earlier versions of the code to help fix the mistake while minimizing disruption to all team members.
Version control protects source code from both catastrophe and the casual degradation of human error and unintended consequences.
Software developers working in teams are continually writing new source code and changing existing source code. The code for a project, app or software component is typically organized in a folder structure or "file tree". One developer on the team may be working on a new feature while another developer fixes an unrelated bug by changing code, each developer may make their changes in several parts of the file tree.
When to use VCS
Have you ever:
1. Made a change to code, realised it was a mistake and wanted to revert back?
2. Lost code or had a backup that was too old?
3. Had to maintain multiple versions of a product?
4. Wanted to see the difference between two (or more) versions of your code?
5. Wanted to prove that a particular change broke or fixed a piece of code?
6. Wanted to review the history of some code?
7. Wanted to submit a change to someone else's code?
8. Wanted to share your code, or let other people work on your code?
9. Wanted to see how much work is being done, and where, when and by whom?
10. Wanted to experiment with a new feature without interfering with working code?
In these cases, and no doubt others, a version control system should make your life easier.
VCS Terminologies
Basic Setup
1. Repository (repo): The database storing the files.
2. Server: The computer storing the repo.
3. Client: The computer connecting to the repo.
4. Working Set/Working Copy: Your local directory of files, where you make changes.
5. Trunk/Main: The primary location for code in the repo. Think of code as a family tree — the trunk is the main line.
Basic Actions
1. Add/Push: Put a file into the repo for the first time, i.e. begin tracking it with Version Control.
2. Revision: What version a file is on (v1, v2, v3, etc.).
3. Head: The latest revision in the repo.
4. Check out/Pull/Fetch: Download a file from the repo.
5. Check in/Push: Upload a file to the repository (if it has changed). The file gets a new revision number, and people can “check out” the latest one.
6. Check In Message: A short message describing what was changed.
7. Changelog/History: A list of changes made to a file since it was created.
8. Update/Sync: Synchronize your files with the latest from the repository. This lets you grab the latest revisions of all files.
9. Revert: Throw away your local changes and reload the latest version from the repository
Advanced Actions
1. Branch: Create a separate copy of a file/folder for private use (bug fixing, testing, etc). Branch is both a verb (“branch the code”) and a noun (“Which branch is it in?”).
2. Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions.
3. Merge (or patch): Apply the changes from one file to another, to bring it up-to-date. For example, you can merge features from one branch into another. (At Microsoft, this was called Reverse Integrate and Forward Integrate)
4. Conflict: When pending changes to a file contradict each other (both changes cannot be applied).
5. Resolve: Fixing the changes that contradict each other and checking in the correct version.
6. Locking: Taking control of a file so nobody else can edit it until you unlock it. Some version control systems use this to avoid conflicts.
Types of version control
Localized version control systems
A localized version control system keeps local copies of the files. This approach can be as simple as creating a manual copy of the relevant files.
Centralized version control systems
A centralized version control system provides a server software component which stores and manages the different versions of the files. A developer can copy (checkout) a certain version from the central sever onto their individual computer. Eg: CVS,SVN etc.
• In Subversion, CVS, Perforce, etc.A central server repository (repo) holds the "official copy" of the code.
– the server maintains the sole
version history of the repo
• You make "checkouts" of it
to your local copy
– you make local modifications
– your changes are not versioned
• When you're done, you
"check in" back to the server
– your checkin increments the repo's version
Distributed version control systems
In a distributed version control system each user has a complete local copy of a repository on his individual computer.
Both approaches have the drawback that they have one single point of failure. In a localized version control systems it is the individual computer and in a centralized version control systems it is the server machine. Both system makes it also harder to work in parallel on different features. Eg:Git,mercurial etc
Comments
Post a Comment