Version Control System

1,915 views

Published on

Version Control System, Code Management, project management, code repository, code version control

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,915
On SlideShare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 3rd point file operation vs file set operations In early VCSes, some of which are still in use today, checkins and other operations are file-based; each file has its own master file with its own comment- and revision history separate from that of all other files in the system. Later systems do fileset operations; most importantly, a checkin may include changes to several files and that change set is treated as a unit by the system. Any comment associated with the change doesn't belong to any one file, but is attached to the combination of that fileset and its revision number.
  • Everyone syncs and checks into the main trunk: Sue adds soup, Joe adds juice, and Eve adds eggs.Sue’s change must go into main before it can be seen by others. Yes, theoretically Sue could make a new branch for other people to try out her changes, but this is a pain in a regular VCS.
  • Ina distributed model, every developer has their own repo. Sue’s changes live in her local repo, which she can share with Joe or Eve.But will it be a circus with no ringleader? Nope. If desired, everyone can push changes into a common repo, suspiciously like the centralized model above. This franken-repo contains the changes of Sue, Joe and Eve.
  • On one end is a Subversion repository that holds all of your versioned data.On the other end is your Subversion client program, which manages local reflections of portions of that versioned data. Between these extremes are multiple routes through a Repository Access (RA) layer, some of which go across computer networks and through network servers which then access the repository, others of which bypass the network altogether and access the repository directly.DAV - DAV or to be specific webDAV. It stands for Distributed Authoring Version. mod_dav_svn - It’s a plug-in module for the Apache HTTP Server, used to make your repository available to others over a network.SVN - The command-line client program.svnserve - A custom standalone server program, runnable as a daemon process or invokable by SSH; another way to make your repository available to others over a network.
  • CHEAP COPY  Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard-link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard-link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects.[Hard-Link . . http://kb.iu.edu/data/aibc.html]
  • Version Control System

    1. 1. VERSION CONTROL SYSTEM<br />SUBVERSION<br />
    2. 2. WHAT IS VCS ?<br />A version control system (VCS) is a tool for managing a collection of program code that provides you with three important capabilities: <br />Reversibility<br />Concurrency<br />Annotation<br />
    3. 3. WHAT VCS DO ?<br />There are three basic things you can do with a VCS<br />CHECK OUTa work file copy from a repository<br />CHECK INor COMMIT a change in a work file to its master in a repository<br />VIEW HISTORY of files. Everything else VCS’s do is an elaboration or support for those three operations.<br />
    4. 4. EVOLUTION OF VCS<br />You’ve all used at least one of the Sub Version Control Management (SCM) on the following list, but are you aware of how long the system you’re using has been around? Do you know the big names? Here is a short compilation of VCS.<br />PRE HISTORY<br /><ul><li>RCS [Released in 1982]</li></ul>THE CLASSIC ERA<br /><ul><li>CVS [Released in 1990]</li></li></ul><li>Contd. . .<br /><ul><li>PVCS
    5. 5. ClearCase
    6. 6. VSS
    7. 7. PerForce</li></ul>ENTER THE MIDDLE AGES<br /><ul><li>Subversion [Released in 2000]</li></li></ul><li>Contd. . .<br /><ul><li>AccuRev</li></ul>ENTER THE RENAISSANCE <br /><ul><li>BitKeeper [Released in 2002]
    8. 8. Mercurial [Released in 2005]
    9. 9. Plastic SCM [Released in 2006]
    10. 10. GitReleased [Released in 2007]</li></li></ul><li>Contd. . .<br /><ul><li>Bazzar [Released in 2008]
    11. 11. Darcs [Released in 2010]
    12. 12. Team Foundation Server.</li></li></ul><li>CATEGORIZING VCS<br />There are three fundamental ways in which VCS’s can differ from each other:<br /><ul><li>They can be centralized or decentralized.
    13. 13. They can be locking, merge-before-commit, or commit-before-merge.
    14. 14. They can do file operations or file set operations.</li></li></ul><li>CVS Diagram<br />
    15. 15. DVCS Diagram<br />
    16. 16. VERSION MANAGEMENT USING XCODE<br />Xcode provides several ways to save versions of your project:<br />Take a Snapshot of Your Project. Project Archiving<br />Keep Track of Changes with Source Control. [Using SVN or GIT]<br />An archive packages your products for distribution, either through your own distribution mechanism or for submission to the App Store.<br />
    17. 17. SVN<br /> Subversion is probably the version control system with the widest adoption. Most open-source projects use Subversion as a repository because other larger projects, such as Source Forge, Apache, Python, Ruby and many others, use it as well.<br />Google Code uses Subversion exclusively to distribute code.<br /> In Subversion (often abbreviated SVN), code is stored in a repository, which is located somewhere on the network. (To use Subversion for your personal projects you can create your own repository as well.) <br />
    18. 18. SVN WORKING MODEL<br />
    19. 19. SVN ARCHITECTURE<br />SVN Client Program<br />Repository Access Layer<br />-DAV<br />-SVN<br />-Local<br />SVN Repository<br />
    20. 20. Lets get started !!<br />ANALOGY<br />Working with SVN is somewhat like growing a tree:<br />Atree has a trunk and some branches.<br />Branches grow from the trunk, and thinner branches grow from thicker branches.<br />Atree can grow with a trunk and no branch (but not for long).<br />
    21. 21. Contd . .<br />A tree with branches but no trunk looks more like a bundle of twigs fallen on the floor.<br />If the trunk is sick, so are the branches and eventually, the whole tree can die.<br />If a branch is sick, you can cut it, and another one may grow.<br />If a branch grows too much, it may become too heavy for the trunk, and the tree will fall down.<br />When you feel your tree, your trunk, or a branch is nice looking, you can take a picture of it to remember how nice it was that day.<br />
    22. 22. SVN TRUNK<br /> The trunk is the main place were stable code can be found. This is like the assembly line of a car factory, putting finished car parts together. Dealing with SVN trunk, you should keep following things in mind:<br /><ul><li>NEVER work directly on the trunk.
    23. 23. Do not commit changes (from a branch merge) to the trunk which may break it.</li></li></ul><li>SVN BRANCHES<br /> A branch is a “cheap copy” of a subtree (ie, the trunk or a branch) of a SVN repository. Dealing with SVN branches:<br />If you need to alter your application or develop a new feature for it, create a new branch.<br />New branches must be created from the trunk, except for new sub-branches (if needed) which must be created from a branch.<br />When you create a new branch, you should switch to it immediately.<br />When a branch is completed and considered stable, it must be merged back to its original copy, that is: back to the trunk if it was copied from the trunk, or back to its parent branch if it was copied from a branch.<br />
    24. 24. SVN TAGS<br /> It is a snapshot with a name of a specific revision of the trunk, or of a branch. Dealing with TAGS:<br />Do never switch to/checkout from/commit to a SVN tag: a tag is some sort of “picture”, not the real thing; tags are to be read, never written<br />On specific/critical environments (production, staging, testing, etc), checkout and update from a fixed tag, but do never commit to a tag.<br />When the trunk is stable and ready to be released publicly, re-create tags accordingly, then update the concerned environments (production, staging, etc)<br />Do not tag a tag<br />
    25. 25. SVN COMMANDS<br />The underneath link is a download link to a text file enlisting the basic commands used in SVN:http://dl.dropbox.com/u/35724246/TA_MONDAY_SESSIONS/Session_6.3_28-9-2011.txt<br />
    26. 26. Credits<br />http://svnbook.red-bean.com/en/1.5/index.html<br />http://www.clear.rice.edu/comp314/svn.html<br />http://www.smashingmagazine.com/2008/09/18/the-top-7-open-source-version-control-systems/<br />http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/SCM/SCM.html<br />http://www.infoq.com/articles/dvcs-guide<br />http://codex.wordpress.org/Using_Subversion<br />
    27. 27. THANK YOU.<br />

    ×