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
VERSION CONTROL SYSTEM<br />SUBVERSION<br />
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 />
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 />
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
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]
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 />
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 />
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 />
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 />
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.
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 />
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 />
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 />