Revision Control OSS Survey

Size: px

Start display at page:

Download "Revision Control OSS Survey"

Dinah Wiggins
6 years ago
Views:

1 POLITECNICO DI TORINO Revision Control OSS Survey Group: Zhang Linchao Tang Xinhua Huang Jie Guo Xiaolu July 2011

2 Introduction Common Vocabulary A Visual Example Centralized Model Distributed Model Best Practices

3 Introduction Freedom! Richard Stallman, founded the Free Software Movement (FSF), in October 1985,he developed a free software definition and the concept of "copyleft", designed to ensure software freedom for all.

History Before 1983: Complex period from free software to

called "sharing" was, in his words, "stealing".

launched the GNU Project to write a complete operating

4 History Before 1983: Complex period from free software to non-free software, from Bill Gates 1976,what hackers called "sharing" was, in his words, "stealing". --> GNU and FSF's early years :In 1983, Richard Stallman launched the GNU Project to write a complete operating system free from constraints on use of its source code fight for freedom!

Linux (1991 ) :The Linux kernel, started by Linus Torvalds, was

the almost-finished GNU operating system and the Linux kernel made the

GNU/Linux The free BSDs (1993 ) :When the USL v.

5 Linux (1991 ) :The Linux kernel, started by Linus Torvalds, was released as freely modifiable source code in 1991, The combination of the almost-finished GNU operating system and the Linux kernel made the first complete freesoftware operating system. GNU/Linux The free BSDs (1993 ) :When the USL v. BSDi lawsuit was settled out of court in1993, FreeBSD and NetBSD (both derived from 386BSD) were released as free software.

The dot-com years (late 1990s):In the mid to late 90s, when many website-based

servers The launch of Open Source :The Open Source Initiative was founded in

principles Desktop: KDE was founded in 1996 by Matthias Ettrich.

6 The dot-com years (late 1990s):In the mid to late 90s, when many website-based companies were starting up, free software became a popular choice for web servers The launch of Open Source :The Open Source Initiative was founded in February 1998 to encourage use of the new term and evangelize open-source principles Desktop: KDE was founded in 1996 by Matthias Ettrich. At the time, he was troubled by the inconsistencies in UNIX applications. He proposed a new desktop environment

7 Today s topic : version problems

Version Problem Software development involves lots of collaborations between the software engineers, resulting hundreds and thousands of swapping files.

8 Version Problem Software development involves lots of collaborations between the software engineers, resulting hundreds and thousands of swapping files. Resource development is usually carried out by teams, either co-located or distributed. Even for a individual project, as the project proceeds, it can generate lots of source versions. Users may wish to compare today's version of some software with yesterday's version or last year's version.

9 Version Problem A typical share point comic:

Revision Control Revision control, also known as version control, is a combination of technologies and practices for tracking and controlling changes to a project's files, in particular to source

10 Revision Control Revision control, also known as version control, is a combination of technologies and practices for tracking and controlling changes to a project's files, in particular to source code, documentation, and web pages. Every change made to the source is tracked, along with who made the change, why they made it and references to problems fixed, or enhancements introduced, by the change.

11 Revision Control Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 23, 2007? No problem. Synchronization. Lets people share files and stay up-to-date with the latest version. Short-term undo. Monkeying with a file and messed it up? (That s just like you, isn t it?). Throw away your changes and go back to the last known good version in the database. Long-term undo. Sometimes we mess up bad. Suppose you made a change a year ago, and it had a bug. Jump back to the old version, and see what change was made that day. Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why. Track Ownership. A VCS tags every change with the name of the person who made it. Helpful for blamestorming giving credit. Sandboxing, or insurance against yourself. Making a big change? You can make temporary changes in an isolated area, test and work out the kinks before checking in your changes. Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you can merge your work back into the common area.

12 Revision control in various aspects Revision control in Book Inventory

13 Revision control in various aspects Applicant in the working under Microsoft Operating Systems

14 Common Vacabulary Terminology can vary in different version control systems, but some terms in common usage include: Commit: To make a change to the project Log message: A bit of commentary attached to each commit, describing the nature and purpose of the commit Update: To ask that others' changes (commits) be incorporated into your local copy of the project; that is, to bring your copy "up-to-date". Repository: A database in which changes are stored. Some version control systems are centralized: there is a single, master repository, which stores all changes to the project. Others are decentralized: each developer has his own repository, and changes can be swapped back and forth between repositories arbitrarily. Checkout: The process of obtaining a copy of the project from a repository. Working copy: A developer's private directory tree containing the project's source code files, and possibly its web pages or other documents.

15 Common Vacabulary Revision/Change: one specific incarnation of a particular file or directory Diff: A textual representation of a change. A diff shows which lines were changed and how, plus a few lines of surrounding context on either side. Tag: A label for a particular collection of files at specified revisions. Branch: A copy of the project, under version control but isolated, so that changes made to the branch don't affect the rest of the project, and vice versa, except when changes are deliberately "merged" from one side to the other Merge: To move a change from one branch to another. This includes merging from the main trunk to some other branch, or vice versa. Conflict: What happens when two people try to make different changes to the same place in the code. Lock: A way to declare an exclusive intent to change a particular file or directory.

16 Visual Example Checkins: checking in a file (list.txt) and modifying it over time. Each time we check in a new version, we get a new revision (r1, r2, r3, etc.).

17 Visual Example Checkouts and Editing: In reality, you might not keep checking in a file. You may have to check out, edit and check in. If you don t like your changes and want to start over, you can revert to the previous version and start again (or stop). When checking out, you get the latest revision by default. The cycle looks as follows:

Visual Example Diffs: The trunk has a history of changes as a file evolves. Diffs are the changes you made while editing: imagine you can peel them off and apply them to a file.

18 Visual Example Diffs: The trunk has a history of changes as a file evolves. Diffs are the changes you made while editing: imagine you can peel them off and apply them to a file. For example, to go from r1 to r2, we add eggs (+Eggs). Imagine peeling off that red sticker and placing it on r1, to get r2. And to get from r2 to r3, we add Juice (+Juice). To get from r3 to r4, we remove Juice and add Soup (- Juice, +Soup). Most version control systems store diffs rather than full copies of the file.

19 Visual Example Branches: let us copy code into a separate folder so we can monkey with it separately. For example, we can create a branch for new, experimental ideas for our list: crazy things like Rice or Eggo waffles. Depending on the version control system, creating a branch (copy) may change the revision number.

20 Visual Example Merging

21 Visual Example Conflicts: Many times, the VCS can automatically merge changes to different parts of a file.conflicts can arise when changes appear that don t gel: Joe wants to remove eggs and replace it with cheese (-eggs, +cheese), and Sue wants to replace eggs with a hot dog (-eggs, +hot dog).

22 Visual Example Tagging: Who would have thought a version control system would be Web 2.0 compliant? Many systems let you tag (label) any revision for easy reference. This way you can refer to Release 1.0 instead of a particular build number:

23 Revision Control Software There are a lot of notable software for revision control: According to control model, they can be categorized as: Local only Client/Server Model Distributed Model According to the charging property Free/Open Source Proprietary As the course concerns, we will just focus on the free revision control software. Actually, the most popular and valuable revision control software are mostly free and open source.

24 Historical local only Initially, revision control software is firstly developed for an individual project, where developer(s) must use the same computer. These software often manage single files individually and are largely replaced or embedded within new software. Free local only software Revision Control System (RCS, 1982): stores the latest version and backward deltas for fastest access to the trunk tip compared to SCCS and an improved user interface, at the cost of slow branch tip access and missing support for included/excluded deltas. Source Code Control System (SCCS, 1972): part of UNIX; based on interleaved deltas, can construct versions as arbitrary sets of revisions. Extracting an arbitrary version takes essentially the same speed and is thus more useful in environments that rely heavily on branching and merging with multiple "current" and identical versions.

25 Client/Server Model Traditional revision control systems use a centralized model where all the revision control functions take place on a shared server. Free CVS (1986) CVSNT (1998) Subversion (2004) Proprietary Perforce (1995) StarTeam (1995) Vault (2003)

26 Concurrent Versions Systems (CVS) CVS is the grandfather of revision control systems. It was first released in It is the de facto standard and is installed virtually everywhere. The learning curve isn t too steep for CVS, and it s a very simple system for making sure files and revisions are kept up to date. While CVS may be an older technology, it s still quite useful for any designer or developer for backing up and sharing files. Tortoise CVS is a great client for CVS on Windows, and there are many different IDEs, such as Xcode(Mac), Eclipse, NetBeans and Emacs, that use CVS. Originally built on RCS, licensed under the GPL. CVSNT: cross-platform port of CVS that allows case insensitive file names among other changes OpenCVS: CVS clone under the BSD license, with emphasis put on security and source code correctness

27 Concurrent Versions Systems (CVS)

28 Subversion (SVN) SVN is a free software founded and sponsored in 2000 by CollabNet Inc. Its goal is to be a mostly-compatible successor to the widely used CVS. Subversion is currently the version control system with the widest adoption. Most open-source projects use Subversion as a repository because other larger projects, such as SourceForge, Apache, Python, Ruby and many others, use it as well. Google Code uses Subversion exclusively to distribute code. Subversion uses the Apache License, making it free software and open source.

29 Subversion (SVN) Features Commits as true atomic operations Renamed/copied/moved/removed files retain full revision history. The system maintains versioning for directories, renames, and file metadata (but not for timestamps). Versioning of symbolic links. Native support for binary files, with space-efficient binary-diff storage. Apache HTTP Server as network server, WebDAV/Delta-V for protocol Branching as a cheap operation, independent of file size Costs proportional to change size, not to data size. Internationalized program messages. Path-based authorization. Language bindings for C#, PHP, Python, Perl, Ruby, and Java. Full MIME support - users can view or change the MIME type of each file

30 Distributed Model Distributed revision control (DRCS) takes a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository on which clients synchronize, each peer's working copy of the codebase is a bona-fide repository. Free Monotone (2003) Git (2005) Mercurial (2005) Bazaar (2005) Proprietary BitKeeper (1998) Plastic SCM (2006)

31 Distributed vs. Client/Server Compared with Client/Server model, distributed revision control software has the following features: No canonical, reference copy of the codebase exists by default; only working copies. Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server. Rather, communication is only necessary when pushing or pulling changes to or from other peers. Each working copy effectively functions as a remote backup of the codebase and of its change-history, providing natural protection against data loss.

32 Distributed vs. Client/Server Advantages of Distributed Model: Allows users to work productively even when not connected to a network Makes most operations much faster since no network is involved Allows participation in projects without requiring permissions from project authorities, and thus arguably better fosters culture ofmeritocracy[citation needed] instead of requiring "committer" status Allows private work, so users can use their revision control system even for early drafts they do not want to publish Avoids relying on a single physical machine as a single point of failure. Still permits centralized control of the "release version" of the project For FLOSS software projects, it becomes much easier to create a project fork from a project that is stalled because of leadership conflicts or design disagreements. Disadvantage: initial cloning of a repository is slower compared to centralized checkout, because all branches and revision history are copied.

33 Distributed vs. Client/Server Advantages of Distributed Model: Allows users to work productively even when not connected to a network Makes most operations much faster since no network is involved Allows participation in projects without requiring permissions from project authorities, and thus arguably better fosters culture ofmeritocracy[citation needed] instead of requiring "committer" status Allows private work, so users can use their revision control system even for early drafts they do not want to publish Avoids relying on a single physical machine as a single point of failure. Still permits centralized control of the "release version" of the project For FLOSS software projects, it becomes much easier to create a project fork from a project that is stalled because of leadership conflicts or design disagreements. Disadvantage: initial cloning of a repository is slower compared to centralized checkout, because all branches and revision history are copied.

34 Git Git is the new fast-rising version control systems based on distributed model. Initially developed by Linux kernel creator Linus Torvalds, Git has recently taken the Web development community by storm. Git prides itself on being a fast and efficient system, and many major open-source projects use Git to power their repositories; projects like: Linux Kernel, WINE, Fedora, and many others.

35 Git GitHub has recently helped establish Git as a great version control system, providing a beautiful front end for many large projects, such as Rails and Prototype. However, Git isn t as easy to pick up as CVS or SVN, so it s much harder to use for a beginner.

36 Mercurial Mercurial is another open-source distributed version control system, like Git. Mercurial was designed for larger projects, most likely outside the scope of designers and independent Web developers. That doesn t mean that small development teams can t or shouldn t use it. Mercurial is extremely fast, and the creators built the software with performance as the most important feature. The name mercurial is an adjective that means Relating to or having characteristics (eloquence, swiftness, cleverness) attributed to the god Mercury. Aside from being very fast and scalable, Mercurial is a much simpler system than Git, which is why it appeals to some developers. There aren t as many functions to learn, and the functions are similar to those in other CVS systems. It also comes equipped with a stand-alone Web interface and extensive documentation on understanding Mercurial if you have been using another system.

Mercurial Bazaar is yet another distributed version control system, like Mercurial and Git, that offers a very friendly user experience. It calls itself Version control for human beings.

37 Mercurial Bazaar is yet another distributed version control system, like Mercurial and Git, that offers a very friendly user experience. It calls itself Version control for human beings. It supports many different types ofworkflows, from solo to centralized to decentralized, with many variations in between. Bazaar also has a strong community that maintains things like plug-ins and lots of third-party tools, such as GUI software to add a graphical interface to the system. One of the main features of Bazaar is the fine-grained control you ll have over the setup. As shown with the workflows, you can use it to fit almost any scenario of users and setups. This is a great revision control system for nearly any project because it s so easy to modify. It s also embeddable, so you can add it to existing projects.

38 Current State Figure.1 Top Ten Version Control Systems in 2008 Figure.2 Eclipse Community Survey 2011 on Version Control Systems

39 Best Practices Coordinate all Designer upgrades with your entire team When you upgrade to a new version of Designer, many of the files in your project are changed by the project converter, so you need to coordinate with the rest of your team. In the ideal upgrade process, everyone checks in all of their changes, one team member runs the project converter and checks in the converted project, then everyone installs the new version of Designer and reimports the project. Coordinate deployment When you are using version control and the same edirectory server with multiple people, it is possible to overwrite changes. You should coordinate deployment with your team members to make sure that you do not overwrite other team members changes. Best practice is to assign one person to deploy a project to a production environment.

40 Best Practices Assign policies Assign one team member to a policy rather than having multiple team members work on one policy. Multiple team members writing and modifying shared policies in a driver is a recipe for disaster. Define an acceptable modeler layout for the team Personal Modeler layouts in a team environment are only maintained if there is a version control conflict on the Modeler layout between your Modeler view layout and another s Modeler view layout. If there is no conflict and you perform an Update from the version control server, you get the last Modeler layout that was checked into version control. Choose a Modeler layout that the team can live with and leave it alone.

41 Reference 7 Version Control Systems Reviewed, Glen Stansberry, September 18th, Version-Control-Systems.aspx Eclipse Community Survey 2011 Results bestpractice.html Producing Open Source Software, Karl Fogel, Chapter 3, 2010

Version control. Michael Tsai 2012/4/10

Version control. Michael Tsai 2012/4/10 Version control Michael Tsai 2012/4/10 2 Reference http://betterexplained.com/articles/a-visualguide-to-version-control/ http://www.ericsink.com/scm/source_control.ht ml http://betterexplained.com/articles/intro-todistributed-version-control-illustrated/