Source Control Software Engineering 67528 Fall 2012 Source

Source Control Software Engineering 67528 Fall 2012

Source Control • Why do we need this – Problem change a “soft” file or item there is no evidence of what was there earlier – Crude implementation in MS Word the “Track Changes” features that highlights changes according to a predetermined highlighting sequence – Same idea as above be done for SW per single file

Source Control • Is that good? – NO! only keeps one iteration of the changes – Does not address intermediate versions for which one would need intermediate versions saved separately in files. – Does not address sw systems with multiple files and file types(multi programming language) – There are other very useful features of these systems in addition to the above

Source Control • How did it start – First you named files proj 1, proj 1. 1. 1 etc – Mid 80 s first system RCS – Next Large system PVCS, CC, CVS, VSS(Source Safe) • Largely graphical and windows based. CC most successful economically – Next Gen GIT(LINUX) (what we will focus on in this course). For open source projects this is the tool of choice. Especially Kernel Hackers

Source Control Net OP Concurrency e. g. 1 None One file at time Locks RCS 2 Centralized Multifile 3 distributed changesets Merge/Commit VSS, CVS, , PVCS Commit/Merge GIT

Source Control • Today’s version control can do parallel versioning for multiple files. Versioning of files in different stages of dev to generate customer specific versions. Look at this example

Source Control • Interesting URL’s – Numerous VCS explained(caveat this is wikipedia!!) • http: //en. wikipedia. org/wiki/Comparison_of_revision_ control_software – Gource creates videos that visualize a VCS e. g python development history since 1990 • http: //www. youtube. com/watch? v=a. Pk 1 Bq. K 8 zz. I – TRY GIT http: //try. github. com/levels/1/challenges/1 – A good ebook is Version Control by Example by Eric Sink © 2011

Source Control • Why Source Control – Efficient version control at the file level – Backup and Restore for specific dates version etc – Enables to go back to good version – Track Changes, Ownership, sharing (“blamestorming”) – Sandboxing – Branch and Merge

Source Control • Source Control “Lingo” – Repository – DB with files – Client – You the programmer – Server – where the repository is stored – Trunk – main location of files – Working set – local copy on which you make changes

Source Control • Actions – Add file to repository – Revision – Head – Checkout – Checkin – Log – Sync – Revert

Source Control • Actions(Cont’d) – Branch – Diff – Merge – Conflict/Resolve – Lock/Unlock

Source Control • Distributed System Pros – Private Workspace – A developer can pretend that he is “it” – All actions described earlier are used – Faster less interaction with distant repository – Merging based on DAG(direct action graph) – Implicit backup – More modest H/W in Server

Source Control • Distributed System Cons – Support for locking lacking – Size of repository limitation(imagine a repository of 1 TB on your laptop) – Tools that are often integrated are still centralized – Difficulty of use for large number of users usually no GUI – Access Control