DOCSLIB.ORG

Fast, Flexible and Fun: Revision Control with Mercurial

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Fast, Flexible and Fun: Revision Control with Mercurial Fast, Flexible and Fun: Revision Control with Mercurial Martin Geisler [email protected] JAOO Geek Night in Aarhus August 25, 2009 Outline Introduction Basic Concepts Historic Context Subversion in Detail Using Mercurial The Underlying Model Workflows Using History Cool Extensions Changing History Talking to Other Systems Third-Party Tools Wrapping Up Alternatives Unsolved Problems Conclusion 2 / 45 Outline Introduction Basic Concepts Historic Context Subversion in Detail Using Mercurial The Underlying Model Workflows Using History Cool Extensions Changing History Talking to Other Systems Third-Party Tools Wrapping Up Alternatives Unsolved Problems Conclusion 3 / 45 Common features: ñ collaboration ñ branches ñ tags Not so common features: ñ speed! ñ much more, as you will see. Features in Version Control Systems Universal features: ñ let you save changes ñ browser the history 4 / 45 Not so common features: ñ speed! ñ much more, as you will see. Features in Version Control Systems Universal features: ñ let you save changes ñ browser the history Common features: ñ collaboration ñ branches ñ tags 4 / 45 Features in Version Control Systems Universal features: ñ let you save changes ñ browser the history Common features: ñ collaboration ñ branches ñ tags Not so common features: ñ speed! ñ much more, as you will see. 4 / 45 The Repository The database that holds your history: ñ series of project-wide snapshots ñ called changesets or revisions in Mercurial ñ changesets encapsulate a delta between two snapshots ñ each changeset has a parent changeset Repository 5 / 45 The Working Directory Holds your files: Alice Bob hello.c hello.c Makefile goodbye.c Makefile ñ you edit files in the working directory ñ reflects a changeset (the parent changeset) ñ also called a working copy 6 / 45 Branches A key concept: ñ parallel lines of development ñ used to track releases ñ used to isolate disruptive changes 7 / 45 Branches A key concept: ñ parallel lines of development ñ used to track releases ñ used to isolate disruptive changes time 7 / 45 Branches A key concept: ñ parallel lines of development ñ used to track releases ñ used to isolate disruptive changes 1.0 time 7 / 45 Branches A key concept: ñ parallel lines of development ñ used to track releases ñ used to isolate disruptive changes 1.0 time 7 / 45 Branches A key concept: ñ parallel lines of development ñ used to track releases ñ used to isolate disruptive changes 1.0.1 1.0 time 7 / 45 Branches A key concept: ñ parallel lines of development ñ used to track releases ñ used to isolate disruptive changes 1.0.1 1.0.2 1.0 time 7 / 45 Merging The opposite of branching: ñ combines two branches ñ used to merge back bugfixes ñ used to integrate feature branches 1.0.1 1.0.2 1.0 time 8 / 45 Merging The opposite of branching: ñ combines two branches ñ used to merge back bugfixes ñ used to integrate feature branches 1.0.1 1.0.2 1.0 time 8 / 45 Merging The opposite of branching: ñ combines two branches ñ used to merge back bugfixes ñ used to integrate feature branches 1.0.1 1.0.2 1.0 time 8 / 45 Centralized Revision Control Subversion use a single server: Repository trunk/ branches/ trunk/ hello.c bob/ hello.c Makefile hello.c Makefile Alice Makefile Carla Bob 9 / 45 Distributed Revision Control Mercurial duplicates the history on many servers: Alice Bob Carla 10 / 45 Distributed Revision Control Mercurial duplicates the history on many servers: Alice’s Alice Laptop Bob Carla 10 / 45 Distributed Revision Control Mercurial duplicates the history on many servers: Alice’s Alice Laptop Server Bob Carla 10 / 45 Distributed Revision Control Mercurial duplicates the history on many servers: Alice’s Alice Laptop Server Bob Carla 10 / 45 Revision Control System (RCS) Version control from the 1980s: ñ store changes (date, commit message) ñ browse history 11 / 45 Revision Control System (RCS) Version control from the 1980s: ñ store changes (date, commit message) ñ browse history hello.c: Makefile: 11 / 45 Revision Control System (RCS) Version control from the 1980s: ñ store changes (date, commit message) ñ browse history hello.c: Makefile: 11 / 45 Revision Control System (RCS) Version control from the 1980s: ñ store changes (date, commit message) ñ browse history hello.c: Makefile: 11 / 45 Revision Control System (RCS) Version control from the 1980s: ñ store changes (date, commit message) ñ browse history hello.c: Makefile: 11 / 45 Revision Control System (RCS) Version control from the 1980s: ñ store changes (date, commit message) ñ browse history hello.c: Makefile: 11 / 45 Revision Control System (RCS) Version control from the 1980s: ñ store changes (date, commit message) ñ browse history hello.c: Makefile: 11 / 45 CVS Server Alice Bob hello.c hello.c: hello.c Makefile Makefile: Makefile Concurrent Versions System (CVS) Version control in the 1990s: ñ collaboration over the network ñ several working copies ñ one central repository 12 / 45 Concurrent Versions System (CVS) Version control in the 1990s: ñ collaboration over the network ñ several working copies ñ one central repository CVS Server Alice Bob hello.c hello.c: hello.c Makefile Makefile: Makefile 12 / 45 Concurrent Versions System (CVS) Version control in the 1990s: ñ collaboration over the network ñ several working copies ñ one central repository CVS Server Alice Bob hello.c commit hello.c: hello.c Makefile Makefile: Makefile 12 / 45 Concurrent Versions System (CVS) Version control in the 1990s: ñ collaboration over the network ñ several working copies ñ one central repository CVS Server Alice Bob hello.c hello.c: update hello.c Makefile Makefile: Makefile 12 / 45 So, everything is good? CVS has many limitations: ñ no atomic commits ñ no rename information ñ branches? I hope you have a CVS guru at hand. 13 / 45 Subversion (SVN) Version control from this millennia — “CVS done right”: ñ atomic commits ñ tracks renames ñ supports some operations without network access ñ clean and simple design compared to CVS 14 / 45 Merging in Subversion SVN is a centralized system: Repository hello.c hello.c Makefile Makefile Alice Eve hello.c hello.c Makefile hello.c Makefile Makefile Bob Dan Carla ñ merging takes place in client ñ merging takes place on server(!) 15 / 45 What if you want to abandon a merge? ñ you can revert files with conflicts to their old state ñ but other files may have been updated ñ beware of mixed revisions. SVN Merge in Client When you do svn update, you merge: ñ this can of course result in conflicts ñ you must resolve the merge before you go on ñ might be difficult to handle everything at once 16 / 45 SVN Merge in Client When you do svn update, you merge: ñ this can of course result in conflicts ñ you must resolve the merge before you go on ñ might be difficult to handle everything at once What if you want to abandon a merge? ñ you can revert files with conflicts to their old state ñ but other files may have been updated ñ beware of mixed revisions. 16 / 45 They both have mixed revisions in their working copies: hello.c (r2) hello.c (r1) Makefile (r1) Makefile (r3) Alice Bob Difficult for Carla to reproduce either working copy. Mixed Revisions?! SVN lets you work with an inconsistent working copy: ñ Alice and Bob have revision 1 ñ Alice changes hello.c ! revision 2 ñ Bob changes Makefile ! revision 3 17 / 45 Mixed Revisions?! SVN lets you work with an inconsistent working copy: ñ Alice and Bob have revision 1 ñ Alice changes hello.c ! revision 2 ñ Bob changes Makefile ! revision 3 They both have mixed revisions in their working copies: hello.c (r2) hello.c (r1) Makefile (r1) Makefile (r3) Alice Bob Difficult for Carla to reproduce either working copy. 17 / 45 Server-Side Merges Mixed revisions are a result of allowing server-side merges ñ can we forbid server-side merges? ñ not really — it would ruin branches in SVN 18 / 45 Branches in SVN Subversion knows nothing about branches! ñ but SVN has a cheap copy mechanism ñ used for tags and branches 19 / 45 Branches in SVN Subversion knows nothing about branches! ñ but SVN has a cheap copy mechanism ñ used for tags and branches r10 trunk/ hello.c Makefile branches/ tags/ 19 / 45 Branches in SVN Subversion knows nothing about branches! ñ but SVN has a cheap copy mechanism ñ used for tags and branches r10 r11 trunk/ trunk/ hello.c hello.c Makefile Makefile branches/ branches/ tags/ goodbye/ hello.c Makefile tags/ 19 / 45 Branches in SVN Subversion knows nothing about branches! ñ but SVN has a cheap copy mechanism ñ used for tags and branches r10 r11 r12 trunk/ trunk/ trunk/ hello.c hello.c hello.c Makefile Makefile Makefile branches/ branches/ branches/ tags/ goodbye/ goodbye/ hello.c hello.c Makefile goodbye.c tags/ Makefile tags/ 19 / 45 The bottom line is that Subversion’s merge-tracking feature has an extremely complex internal implementation, and the svn:mergeinfo property is the only window the user has into the machinery. Because the feature is relatively new, a numbers of edge cases and possible unexpected behaviors may pop up. —Version Control with Subversion (Mercurial has robust built-in support for merging branches.) Merging Branches in SVN Branches are only interesting if you can merge them: ñ before SVN 1.5: no built-in support for merging(!) ñ SVN 1.5 and later: tracks info needed for merging 20 / 45 Merging Branches in SVN Branches are only interesting if you can merge them: ñ before SVN 1.5: no built-in support for merging(!) ñ SVN 1.5 and later: tracks info needed for merging The bottom line is that Subversion’s merge-tracking feature has an extremely complex internal implementation, and the svn:mergeinfo property is the only window the user has into the machinery.
Load more

Recommended publications
  • Common Tools for Team Collaboration Problem: Working with a Team (Especially Remotely) Can Be Difficult
    Common Tools for Team Collaboration Problem: Working with a team (especially remotely) can be difficult. ▹ Team members might have a different idea for the project ▹ Two or more team members could end up doing the same work ▹ Or a few team members have nothing to do Solutions: A combination of few tools. ▹ Communication channels ▹ Wikis ▹ Task manager ▹ Version Control ￭ We’ll be going in depth with this one! Important! The tools are only as good as your team uses them. Make sure all of your team members agree on what tools to use, and train them thoroughly! Communication Channels Purpose: Communication channels provide a way to have team members remotely communicate with one another. Ideally, the channel will attempt to emulate, as closely as possible, what communication would be like if all of your team members were in the same office. Wait, why not email? ▹ No voice support ￭ Text alone is not a sufficient form of communication ▹ Too slow, no obvious support for notifications ▹ Lack of flexibility in grouping people Tools: ▹ Discord ￭ discordapp.com ▹ Slack ￭ slack.com ▹ Riot.im ￭ about.riot.im Discord: Originally used for voice-chat for gaming, Discord provides: ▹ Voice & video conferencing ▹ Text communication, separated by channels ▹ File-sharing ▹ Private communications ▹ A mobile, web, and desktop app Slack: A business-oriented text communication that also supports: ▹ Everything Discord does, plus... ▹ Threaded conversations Riot.im: A self-hosted, open-source alternative to Slack Wikis Purpose: Professionally used as a collaborative game design document, a wiki is a synchronized documentation tool that retains a thorough history of changes that occured on each page.
    [Show full text]
  • Buildbot: a Continuous Integration System
    Buildbot: A continuous integration system Krzysztof Voss January, 2013 Outline • Testing and Continuous Integration • Introduction to Buildbot • BuildMaster • BuildMaster components • BuildSlave • Installation and Usage 1 Testing and continuous integration Tests: • the best specification • safety-net for refactoring • bug identification Tests are the most effective if we: • run them often • run them on different machines/environments • can easily see their results 2 The most straightforward approach would entail: • logging in to different machines • fetching the newest source code • running tests • analyzing their output In case we want to test a few environments, repeating the above steps is tedious. Developers do not focus on the code, instead they run tests. A continuous integration system performs all of these steps for us, so developers can focus on their code. 3 Introduction to Buildbot: Features • run builds on a variety of BuildSlave platforms • arbitrary build process: handles projects using C, Python, . • minimal host requirements: python and Twisted • BuildSlave can be behind a firewall if they can still do checkout • status delivery through web page, email, IRC, other protocols • track builds in progress, provide estimated completion time • flexible configuration by subclassing generic build process classes 4 • debug tools to force a new build, submit fake Changes, query BuildSlave status • released under the GPL source: http://buildbot.net/buildbot/docs/current/manual/introduction.html 5 Introduction to Buildbot: Overview system overview source: http://buildbot.net/buildbot/docs/0.8.1/full.html 6 BuildMaster BuildMaster components source: http://buildbot.net/buildbot/docs/0.8.1/full.html 7 BuildMaster BuildMaster: • holds the configuration of the entire system.
    [Show full text]
  • Efficient Algorithms for Comparing, Storing, and Sharing
    EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY May 2012 Major Subject: Computer Science EFFICIENT ALGORITHMS FOR COMPARING, STORING, AND SHARING LARGE COLLECTIONS OF EVOLUTIONARY TREES A Dissertation by SUZANNE JUDE MATTHEWS Submitted to the Office of Graduate Studies of Texas A&M University in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Approved by: Chair of Committee, Tiffani L. Williams Committee Members, Nancy M. Amato Jennifer L. Welch James B. Woolley Head of Department, Hank W. Walker May 2012 Major Subject: Computer Science iii ABSTRACT Efficient Algorithms for Comparing, Storing, and Sharing Large Collections of Evolutionary Trees. (May 2012) Suzanne Jude Matthews, B.S.; M.S., Rensselaer Polytechnic Institute Chair of Advisory Committee: Dr. Tiffani L. Williams Evolutionary relationships between a group of organisms are commonly summarized in a phylogenetic (or evolutionary) tree. The goal of phylogenetic inference is to infer the best tree structure that represents the relationships between a group of organisms, given a set of observations (e.g. molecular sequences). However, popular heuristics for inferring phylogenies output tens to hundreds of thousands of equally weighted candidate trees. Biologists summarize these trees into a single structure called the consensus tree. The central assumption is that the information discarded has less value than the information retained. But, what if this assumption is not true? In this dissertation, we demonstrate the value of retaining and studying tree collections.
    [Show full text]
  • Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management
    Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management Configuration Management (CM) systems are used to store code and other artifacts in Software Engineering projects. Since the early 70’s, there has been a progression of CM systems used for Software CM, starting with SCCS, and continuing through RCS, CVS, and Subversion. All of these systems used a single, centralized repository structure. Distributed Configuration Management As opposed to traditional CM systems, Distributed Configuration Management Systems are ones where there does not have to be a central repository. Each developer has a copy of the entire repository and history. A central repository may be optionally used, but it is equal to all of the other developer repositories. Advantages of Distributed Configuration Management Distributed tools are faster than centralized ones since metadata is stored locally. Can use tool to manage changes locally while not connected to the network where server resides. Scales more easily, since all of the load is not on a central server. Allows private work that is controlled, but not released to the larger community. Distributed systems are normally designed to make merges easy, since they are done more often. Mercurial Introduction Mercurial is a cross-platform, distributed configuration management application. In runs on most modern OS platforms, including Windows, Linux, Solaris, FreeBSD, and Mac OSX. Mercurial is written 95% in Python, with the remainder written in C for speed. Mercurial is available as a command line tool on all of the platforms, and with GUI support programs on many of the platforms. Mercurial is customizable with extensions, hooks, and output templates.
    [Show full text]
  • Sistemas De Control De Versiones De Última Generación (DCA)
    Tema 10 - Sistemas de Control de Versiones de última generación (DCA) Antonio-M. Corbí Bellot Tema 10 - Sistemas de Control de Versiones de última generación (DCA) II HISTORIAL DE REVISIONES NÚMERO FECHA MODIFICACIONES NOMBRE Tema 10 - Sistemas de Control de Versiones de última generación (DCA) III Índice 1. ¿Qué es un Sistema de Control de Versiones (SCV)?1 2. ¿En qué consiste el control de versiones?1 3. Conceptos generales de los SCV (I) 1 4. Conceptos generales de los SCV (II) 2 5. Tipos de SCV. 2 6. Centralizados vs. Distribuidos en 90sg 2 7. ¿Qué opciones tenemos disponibles? 2 8. ¿Qué podemos hacer con un SCV? 3 9. Tipos de ramas 3 10. Formas de integrar una rama en otra (I)3 11. Formas de integrar una rama en otra (II)4 12. SCV’s con los que trabajaremos 4 13. Git (I) 5 14. Git (II) 5 15. Git (III) 5 16. Git (IV) 6 17. Git (V) 6 18. Git (VI) 7 19. Git (VII) 7 20. Git (VIII) 7 21. Git (IX) 8 22. Git (X) 8 23. Git (XI) 9 Tema 10 - Sistemas de Control de Versiones de última generación (DCA) IV 24. Git (XII) 9 25. Git (XIII) 9 26. Git (XIV) 10 27. Git (XV) 10 28. Git (XVI) 11 29. Git (XVII) 11 30. Git (XVIII) 12 31. Git (XIX) 12 32. Git. Vídeos relacionados 12 33. Mercurial (I) 12 34. Mercurial (II) 12 35. Mercurial (III) 13 36. Mercurial (IV) 13 37. Mercurial (V) 13 38. Mercurial (VI) 14 39.
    [Show full text]
  • Higher Inductive Types (Hits) Are a New Type Former!
    Git as a HIT Dan Licata Wesleyan University 1 1 Darcs Git as a HIT Dan Licata Wesleyan University 1 1 HITs 2 Generator for 2 equality of equality HITs Homotopy Type Theory is an extension of Agda/Coq based on connections with homotopy theory [Hofmann&Streicher,Awodey&Warren,Voevodsky,Lumsdaine,Garner&van den Berg] 2 Generator for 2 equality of equality HITs Homotopy Type Theory is an extension of Agda/Coq based on connections with homotopy theory [Hofmann&Streicher,Awodey&Warren,Voevodsky,Lumsdaine,Garner&van den Berg] Higher inductive types (HITs) are a new type former! 2 Generator for 2 equality of equality HITs Homotopy Type Theory is an extension of Agda/Coq based on connections with homotopy theory [Hofmann&Streicher,Awodey&Warren,Voevodsky,Lumsdaine,Garner&van den Berg] Higher inductive types (HITs) are a new type former! They were originally invented[Lumsdaine,Shulman,…] to model basic spaces (circle, spheres, the torus, …) and constructions in homotopy theory 2 Generator for 2 equality of equality HITs Homotopy Type Theory is an extension of Agda/Coq based on connections with homotopy theory [Hofmann&Streicher,Awodey&Warren,Voevodsky,Lumsdaine,Garner&van den Berg] Higher inductive types (HITs) are a new type former! They were originally invented[Lumsdaine,Shulman,…] to model basic spaces (circle, spheres, the torus, …) and constructions in homotopy theory But they have many other applications, including some programming ones! 2 Generator for 2 equality of equality Patches Patch a a 2c2 diff b d = < b c c --- > d 3 3 id a a b b
    [Show full text]
  • Analysis of Devops Tools to Predict an Optimized Pipeline by Adding Weightage for Parameters
    International Journal of Computer Applications (0975 – 8887) Volume 181 – No. 33, December 2018 Analysis of DevOps Tools to Predict an Optimized Pipeline by Adding Weightage for Parameters R. Vaasanthi V. Prasanna Kumari, PhD S. Philip Kingston Research Scholar, HOD, MCA Project Manager SCSVMV University Rajalakshmi Engineering Infosys, Mahindra City, Kanchipuram College, Chennai Chennai ABSTRACT cloud. Now-a-days more than ever, DevOps [Development + Operations] has gained a tremendous amount of attention in 2. SCM software industry. Selecting the tools for building the DevOps Source code management (SCM) is a software tool used for pipeline is not a trivial exercise as there are plethora’s of tools development, versioning and enables team working in available in market. It requires thought, planning, and multiple locations to work together more effectively. This preferably enough time to investigate and consult other plays a vital role in increasing team’s productivity. Some of people. Unfortunately, there isn’t enough time in the day to the SCM tools, considered for this study are GIT, SVN, CVS, dig for top-rated DevOps tools and its compatibility with ClearCase, Mercurial, TFS, Monotone, Bitkeeper, Code co- other tools. Each tool has its own pros/cons and compatibility op, Darcs, Endevor, Fossil, Perforce, Rational Synergy, of integrating with other tools. The objective of this paper is Source Safe, and GNU Bazaar. Table1 consists of SCM tools to propose an approach by adding weightage to each with weightage. parameter for the curated list of the DevOps tools. 3. BUILD Keywords Build is a process that enables source code to be automatically DevOps, SCM, dependencies, compatibility and pipeline compiled into binaries including code level unit testing to ensure individual pieces of code behave as expected [4].
    [Show full text]
  • Version Control – Agile Workflow with Git/Github
    Version Control – Agile Workflow with Git/GitHub 19/20 November 2019 | Guido Trensch (JSC, SimLab Neuroscience) Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich, JSC:SimLab Neuroscience 2 Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich, JSC:SimLab Neuroscience 3 Motivation • Version control is one aspect of configuration management (CM). The main CM processes are concerned with: • System building • Preparing software for releases and keeping track of system versions. • Change management • Keeping track of requests for changes, working out the costs and impact. • Release management • Preparing software for releases and keeping track of system versions. • Version control • Keep track of different versions of software components and allow independent development. [Ian Sommerville,“Software Engineering”] Forschungszentrum Jülich, JSC:SimLab Neuroscience 4 Motivation • Keep track of different versions of software components • Identify, store, organize and control revisions and access to it • Essential for the organization of multi-developer projects is independent development • Ensure that changes made by different developers do not interfere with each other • Provide strategies to solve conflicts CONFLICT Alice Bob Forschungszentrum Jülich, JSC:SimLab Neuroscience 5 Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich,
    [Show full text]
  • Revision Control
    Revision Control Tomáš Kalibera, (Peter Libič) Department of Distributed and Dependable Systems http://d3s.mff.cuni.cz CHARLES UNIVERSITY PRAGUE Faculty of Mathematics and Physics Problems solved by revision control What is it good for? Keeping history of system evolution • What a “system” can be . Source code (single file, source tree) . Textual document . In general anything what can evolve – can have versions • Why ? . Safer experimentation – easy reverting to an older version • Additional benefits . Tracking progress (how many lines have I added yesterday) . Incremental processing (distributing patches, …) Allowing concurrent work on a system • Why concurrent work ? . Size and complexity of current systems (source code) require team work • How can concurrent work be organized ? 1. Independent modifications of (distinct) system parts 2. Resolving conflicting modifications 3. Checking that the whole system works . Additional benefits . Evaluating productivity of team members Additional benefits of code revision control • How revision control helps . Code is isolated at one place (no generated files) . Notifications when a new code version is available • Potential applications that benefit . Automated testing • Compile errors, functional errors, performance regressions . Automated building . Backup • Being at one place, the source is isolated from unneeded generated files . Code browsing • Web interface with hyperlinked code Typical architecture Working copy Source code repository (versioned sources) synchronization Basic operations • Check-out . Create a working copy of repository content • Update . Update working copy using repository (both to latest and historical version) • Check-in (Commit) . Propagate working copy back to repository • Diff . Show differences between two versions of source code Simplified usage scenario Source code Check-out or update repository Working 1 copy 2 Modify & Test Check-in 3 Exporting/importing source trees • Import .
    [Show full text]
  • Useful Tools for Game Making
    CMS.611J/6.073 Fall 2014 Useful Tools List This list is by no means complete, but should get you started. Talk to other folks in the class about their recommendations. Revision Control Version control software, provides backups and easy reversion. Perforce Mac/Win GUI (p4v): Heavily used in game http://www.perforce.com/dow industry. Commercial nloads/Perforce-Software-Ver software; you can use the sion-Management/complete_l Game Lab server. ist/Customer Subversion Command line: Open source, server-based http://subversion.apache.org/ Windows GUI: http://tortoisesvn.net/ Git Command line: Open source, distributed http://git-scm.com/ Mercurial Command line: Open source, distributed http://mercurial.selenic.com/ Windows GUI: http://tortoisehg.bitbucket.org/ SourceTree Mac/Win GUI: Not a source control system, http://www.sourcetreeapp.co just a GUI for Git and m/ Mercurial clients Revision Control Hosting SourceForge http://sourceforge.net/ git, mercurial, or subversion BitBucket https://bitbucket.org/ git or mercurial GitHub https://github.com/ git, has own (painful) GUI for Git 1 Image Editing MSPaint Windows, pre-installed Surprisingly useful quick pixel art editor (esp for prototypes) Paint.NET Windows, About as easy as MSPaint, but http://www.getpaint.net/download much more powerful .html Photoshop Mac, Windows New Media Center, 26-139 GIMP Many platforms, Easier than photoshop, at http://www.gimp.org/downloads/ least. Sound GarageBand Mac New Media Center, 26-139 Audacity Many platforms, Free, open source. http://audacity.sourceforge.ne
    [Show full text]
  • FAKULTÄT FÜR INFORMATIK Leveraging Traceability Between Code and Tasks for Code Reviews and Release Management
    FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master’s Thesis in Informatics Leveraging Traceability between Code and Tasks for Code Reviews and Release Management Jan Finis FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master’s Thesis in Informatics Leveraging Traceability between Code and Tasks for Code Reviews and Release Management Einsatz von Nachvollziehbarkeit zwischen Quellcode und Aufgaben für Code Reviews und Freigabemanagement Author: Jan Finis Supervisor: Prof. Bernd Brügge, Ph.D. Advisors: Maximilian Kögel, Nitesh Narayan Submission Date: May 18, 2011 I assure the single-handed composition of this master’s thesis only supported by declared resources. Sydney, May 10th, 2011 Jan Finis Acknowledgments First, I would like to thank my adviser Maximilian Kögel for actively supporting me with my thesis and being reachable for my frequent issues even at unusual times and even after he left the chair. Furthermore, I would like to thank him for his patience, as the surrounding conditions of my thesis, like me having an industrial internship and finishing my thesis abroad, were sometimes quite impedimental. Second, I want to thank my other adviser Nitesh Narayan for helping out after Max- imilian has left the chair. Since he did not advise me from the start, he had more effort working himself into my topic than any usual adviser being in charge of a thesis from the beginning on. Third, I want to thank the National ICT Australia for providing a workspace, Internet, and library access for me while I was finishing my thesis in Sydney. Finally, my thanks go to my supervisor Professor Bernd Brügge, Ph.D.
    [Show full text]
  • Distributed Revision Control with Mercurial
    Distributed revision control with Mercurial Bryan O’Sullivan Copyright c 2006, 2007 Bryan O’Sullivan. This material may be distributed only subject to the terms and conditions set forth in version 1.0 of the Open Publication License. Please refer to Appendix D for the license text. This book was prepared from rev 028543f67bea, dated 2008-08-20 15:27 -0700, using rev a58a611c320f of Mercurial. Contents Contents i Preface 2 0.1 This book is a work in progress ...................................... 2 0.2 About the examples in this book ..................................... 2 0.3 Colophon—this book is Free ....................................... 2 1 Introduction 3 1.1 About revision control .......................................... 3 1.1.1 Why use revision control? .................................... 3 1.1.2 The many names of revision control ............................... 4 1.2 A short history of revision control .................................... 4 1.3 Trends in revision control ......................................... 5 1.4 A few of the advantages of distributed revision control ......................... 5 1.4.1 Advantages for open source projects ............................... 6 1.4.2 Advantages for commercial projects ............................... 6 1.5 Why choose Mercurial? .......................................... 7 1.6 Mercurial compared with other tools ................................... 7 1.6.1 Subversion ............................................ 7 1.6.2 Git ................................................ 8 1.6.3
    [Show full text]