DOCSLIB.ORG

Understanding Darcs

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Understanding Darcs Understanding Darcs en.wikibooks.org March 15, 2015 On the 28th of April 2012 the contents of the English as well as German Wikibooks and Wikipedia projects were licensed under Creative Commons Attribution-ShareAlike 3.0 Unported license. A URI to this license is given in the list of figures on page 63. If this document is a derived work from the contents of one of these projects and the content was still licensed by the project under this license at the time of derivation this document has to be licensed under the same, a similar or a compatible license, as stated in section 4b of the license. The list of contributors is included in chapter Contributors on page 61. The licenses GPL, LGPL and GFDL are included in chapter Licenses on page 67, since this book and/or parts of it may or may not be licensed under one or more of these licenses, and thus require inclusion of these licenses. The licenses of the figures are given in the list of figures on page 63. This PDF was generated by the LATEX typesetting software. The LATEX source code is included as an attachment (source.7z.txt) in this PDF file. To extract the source from the PDF file, you can use the pdfdetach tool including in the poppler suite, or the http://www. pdflabs.com/tools/pdftk-the-pdf-toolkit/ utility. Some PDF viewers may also let you save the attachment to a file. After extracting it from the PDF file you have to rename it to source.7z. To uncompress the resulting archive we recommend the use of http://www.7-zip.org/. The LATEX source itself was generated by a program written by Dirk Hünniger, which is freely available under an open source license from http://de.wikibooks.org/wiki/Benutzer:Dirk_Huenniger/wb2pdf. Contents 1 Getting Started 3 1.1 Anatomy of a darcs repository ......................... 3 1.2 Essential commands ............................... 4 2 Making Changes 9 2.1 Editing files .................................... 9 2.2 Playing with files ................................. 10 3 Working With Others 13 3.1 The commands .................................. 13 3.2 Dealing with conflicts .............................. 16 4 Reviewing Your Work 17 5 Undoing Mistakes 21 5.1 The big three ................................... 21 5.2 Other ways to get rid of things ......................... 24 5.3 Questions and objections ............................ 25 6 Dealing With Conflicts 27 6.1 Handle your conflicts at home .......................... 27 6.2 Resolving conflicts ................................ 27 7 Introduction to Patch Theory 29 7.1 Math and computer science nerds only ..................... 29 7.2 What is the theory of patches? ......................... 29 7.3 Why all this math? ................................ 29 7.4 Context, patches and changes .......................... 30 7.5 Sequential patches ................................ 32 7.6 Inverses ...................................... 33 7.7 Commutation ................................... 35 7.8 Merging ...................................... 41 7.9 Definitions and properties ............................ 49 8 Intermediary Patch Theory 51 8.1 It’s all patches .................................. 51 8.2 Merging a sequence of patches ......................... 51 8.3 Sequences of patches ............................... 52 8.4 Permutivity .................................... 52 III Contents 9 Patch Theory and Conflicts 53 9.1 Conflicts ...................................... 53 9.2 Forced commutation ............................... 56 9.3 Forced commutation in merging ........................ 56 9.4 Darcs 2 ...................................... 59 9.5 Current research ................................. 59 10 Contributors 61 List of Figures 63 11 Licenses 67 11.1 GNU GENERAL PUBLIC LICENSE ..................... 67 11.2 GNU Free Documentation License ....................... 68 11.3 GNU Lesser General Public License ...................... 69 1 1 Getting Started 1.1 Anatomy of a darcs repository Understanding how to use the darcs commands can be a lot easier if you have a rough idea how things work. We’re not asking you to learn about patch commutation algebra (yet), but one thing you should at least be comfortable with is the anatomy of a darcs repository. Figure 1 Anatomy of a darcs repository The idea of the diagram is as follows: the stuff on the left in yellow is you. That’s what darcs calls the working directory . The stuff in grey, on the other hand, is part of that mysterious _darcs directory if you’ve played around with darcs before. This can be broken down some more. The pristine tree (middle) is exactly like your working directory, except only representing the last saved state. It’s not essential to darcs’s operations, but it makes things run more efficiently, and is perhaps useful for understanding how things work. Finally, the right-most portion is the set of patches . Patches are what makes darcs... well... darcs. Darcs thinks in patches. Almost every darcs operation somehow involves (darcs) juggling some patches around behind the scenes. Enthusiastic darcs users find that this makes life easier in a number of ways. For example, accepting patches to your code 3 Getting Started becomes an extremely natural thing to do - you just let darcs apply them and in they go. But before we get to that, let’s tackle a small set of essential commands. 1.2 Essential commands 1.2.1 init Say you have a directory with some files in it. When you run darcs init to initialise the repository, you get an empty new darcs repository. Your working directory might contain files, but darcs does not know about them yet. Figure 2 After a darcs init - an empty repository 1.2.2 add darcs add tells darcs to keep track of a file or directory that was only in your working directory. It creates or adds to a special temporary patch which we call the pending patch (will be represented in blue). Note that it does not affect your pristine tree whatsover! The 4 Essential commands idea is that we haven’t saved your work (which is what the pristine tree is for). We’ve only told darcs that we might conceivably want to save it later on. Figure 3 during darcs add Note that the pending patch is different from all the other patches. It is really a represen- tation of (some) things you have not yet converted into a real darcs patch. 1.2.3 whatsnew The darcs whatsnew compares the working directory against the pristine tree (theoretically, against the set of patches) and displays what has changed between them. If there is anything in the pending patch, it also displays the contents of that. 5 Getting Started Figure 4 Darcs whatsnew 1.2.4 record The darcs record command is how you save your work. It copies your chosen changes from the working directory to the pristine tree, and more importantly, creates a new patch representing those changes. Changes can also come from the pending patch, and these changes will also be propagated into the pristine tree. 6 Essential commands Figure 5 during darcs record 1 1 http://en.wikibooks.org/wiki/Category%3A 7 2 Making Changes 2.1 Editing files 2.1.1 record makes new stuff old The record command takes the changes which only exist in your working directory (or the pending patch) and updates the pristine tree. The result of a record operation is a new patch. Figure 6 The darcs record command 9 Making Changes 2.1.2 replace for renaming tokens The replace command is useful for explictly telling darcs to replace one word with another (for example, a variable name, if you are a programmer). Note that because of the underlying patch theory, replace only works if the new word doesn’t already exist in the file. Darcs will helpfully let you know if you try to replace something you cannot. Also, there is a switch for forcing the replacement, but the resulting patch is not a clean darcs-replace patch, but a combination of that, and what you would have gotten if you had edited the file in a text editor. In short, forcing darcs to replace when it really doesn’t want to can lead to counter-intuitive results. 2.2 Playing with files We saw add in the last chapter. What about the other file-related commands? 2.2.1 add tells darcs to pay attention add , unsuprisingly, adds a file or directory to the list of files that darcs is paying attention to. 10 Playing with files Figure 7 The darcs add command 2.2.2 mv for moving or renaming mv lets you rename a file or put it in a different directory. This command updates the pending patch with a move command. 2.2.3 you don’t need remove You might think that remove gets rid of a file, but actually all it does is to remove it from the list of files that darcs is paying attention to. You probably just want to delete the file instead (eg: with rm ). Darcs will notice and record the change next time you darcs record that file. So what’s the remove command good for? It might be handy if you want to just remove the file from darcs, without actually getting rid of your physical copy. This is most useful when you’ve accidentally used darcs add on a file you don’t want darcs to pay attention to. 11 Making Changes 1 1 http://en.wikibooks.org/wiki/Category%3A 12 3 Working With Others 3.1 The commands 3.1.1 get darcs get makes a copy of an entire darcs repository. Note that we only get the recorded patches (and pristine tree), not any of the pending stuff. 13 Working With Others Figure 8 during darcs get 3.1.2 pull/push darcs pull copies from some other repository patches that you do not have. The patches are applied to your pristine tree and working directory.
Load more

Recommended publications
  • 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]
  • 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]
  • DVCS Or a New Way to Use Version Control Systems for Freebsd
    Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions DVCS or a new way to use Version Control Systems for FreeBSD Ollivier ROBERT <[email protected]> BSDCan 2006 Ottawa, Canada May, 12-13th, 2006 Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions Agenda 1 Brief history of VCS 2 FreeBSD context & gures 3 Is Arch/baz suited for FreeBSD? 4 Mercurial to the rescue 5 New processes & policies needed 6 Conclusions Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions The ancestors: SCCS, RCS File-oriented Use a subdirectory to store deltas and metadata Use lock-based architecture Support shared developments through NFS (fragile) SCCS is proprietary (System V), RCS is Open Source a SCCS clone exists: CSSC You can have a central repository with symlinks (RCS) Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions CVS, the de facto VCS for the free world Initially written as shell wrappers over RCS then rewritten in C Centralised server Easy UI Use sandboxes to avoid locking Simple 3-way merges Can be replicated through CVSup or even rsync Extensive documentation (papers, websites, books) Free software and used everywhere (SourceForge for example) Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions CVS annoyances and aws BUT..
    [Show full text]
  • Darcs 2.0.0 (2.0.0 (+ 75 Patches)) Darcs
    Darcs 2.0.0 (2.0.0 (+ 75 patches)) Darcs David Roundy April 23, 2008 2 Contents 1 Introduction 7 1.1 Features . 9 1.2 Switching from CVS . 11 1.3 Switching from arch . 12 2 Building darcs 15 2.1 Prerequisites . 15 2.2 Building on Mac OS X . 16 2.3 Building on Microsoft Windows . 16 2.4 Building from tarball . 16 2.5 Building darcs from the repository . 17 2.6 Building darcs with git . 18 2.7 Submitting patches to darcs . 18 3 Getting started 19 3.1 Creating your repository . 19 3.2 Making changes . 20 3.3 Making your repository visible to others . 20 3.4 Getting changes made to another repository . 21 3.5 Moving patches from one repository to another . 21 3.5.1 All pulls . 21 3.5.2 Send and apply manually . 21 3.5.3 Push . 22 3.5.4 Push —apply-as . 22 3.5.5 Sending signed patches by email . 23 3.6 Reducing disk space usage . 26 3.6.1 Linking between repositories . 26 3.6.2 Alternate formats for the pristine tree . 26 4 Configuring darcs 29 4.1 prefs . 29 4.2 Environment variables . 32 4.3 General-purpose variables . 33 4.4 Remote repositories . 34 3 4 CONTENTS 4.5 Highlighted output . 36 4.6 Character escaping and non-ASCII character encodings . 36 5 Best practices 39 5.1 Introduction . 39 5.2 Creating patches . 39 5.2.1 Changes . 40 5.2.2 Keeping or discarding changes . 40 5.2.3 Unrecording changes .
    [Show full text]
  • Distributed Versioning for Everyone
    Distributed versioning for everyone Distributed versioning for everyone Nicolas Pouillard [email protected] March 20, 2008 Nicolas Pouillard Distributed versioning for everyoneMarch 20, 2008 1 / 48 Distributed versioning for everyone Introduction Outline 1 Introduction 2 Principles of Distributed Versioning 3 Darcs is one of them 4 Conclusion Nicolas Pouillard Distributed versioning for everyoneMarch 20, 2008 2 / 48 Distributed versioning for everyone Introduction SCM: “Source Code Manager” Keeps track of changes to source code so you can track down bugs and work collaboratively. Most famous example: CVS Numerous acronyms: RCS, SCM, VCS DSCM: Distributed Source Code Manager Nicolas Pouillard Distributed versioning for everyoneMarch 20, 2008 3 / 48 Distributed versioning for everyone Introduction Purpose What’s the purpose of this presentation Show the importance of the distributed feature Enrich your toolbox with a DSCM Exorcize rumors about darcs Show how DSCM are adapted for personal use What’s not the purpose of it A flame against other DSCMs A precise darcs tutorial A real explanation of the Theory of patches Nicolas Pouillard Distributed versioning for everyoneMarch 20, 2008 4 / 48 Distributed versioning for everyone Principles of Distributed Versioning Outline 1 Introduction 2 Principles of Distributed Versioning 3 Darcs is one of them 4 Conclusion Nicolas Pouillard Distributed versioning for everyoneMarch 20, 2008 5 / 48 Distributed versioning for everyone Principles of Distributed Versioning Distributed rather than centralized
    [Show full text]
  • Version Control
    Génie Logiciel Avancé Cours 7 — Version Control Stefano Zacchiroli [email protected] Laboratoire PPS, Université Paris Diderot - Paris 7 5 mai 2011 URL http://upsilon.cc/zack/teaching/1011/gla/ Copyright © 2011 Stefano Zacchiroli License Creative Commons Attribution-ShareAlike 3.0 Unported License http://creativecommons.org/licenses/by-sa/3.0/ Stefano Zacchiroli (Paris 7) Version Control 5 mai 2011 1 / 58 Disclaimer slides in English interactive demos Stefano Zacchiroli (Paris 7) Version Control 5 mai 2011 2 / 58 Sommaire 1 Version control Configuration management diff & patch Version control concepts Brief history of version control systems 2 Revision Control System (RCS) 3 Concurrent Versions System (CVS) 4 Subversion 5 Git 6 References Stefano Zacchiroli (Paris 7) Version Control 5 mai 2011 3 / 58 Sommaire 1 Version control Configuration management diff & patch Version control concepts Brief history of version control systems 2 Revision Control System (RCS) 3 Concurrent Versions System (CVS) 4 Subversion 5 Git 6 References Stefano Zacchiroli (Paris 7) Version Control 5 mai 2011 4 / 58 Sommaire 1 Version control Configuration management diff & patch Version control concepts Brief history of version control systems 2 Revision Control System (RCS) 3 Concurrent Versions System (CVS) 4 Subversion 5 Git 6 References Stefano Zacchiroli (Paris 7) Version Control 5 mai 2011 5 / 58 Change During the life time of a software project, everything changes : bugs are discovered and have to be fixed (code) system requirements change and need to be implemented external dependencies (e.g. new version of hardware and software you depend upon) change competitors might catch up most software systems can be thought of as a set of evolving versions potentially, each of them has to be maintained concurrently with the others Stefano Zacchiroli (Paris 7) Version Control 5 mai 2011 6 / 58 Configuration management Definition (Configuration Management) Configuration Management (CM) is concerned with the policies, processes, and tools for managing changing software systems.
    [Show full text]
  • Continuous Integration for Decentralised Development of Service-Based Software Systems
    Continuous Integration for Decentralised Development of Service-Based Software Systems by Jameel Almalki Thesis Submitted to Flinders University for the degree of Doctor of Philosophy College of Science and Engineering 9th August 2018 Declaration I certify that this thesis does not include any prior material submitted for a degree or diploma in any university without acknowledgment; and to the best of my knowledge and belief it does not include any prior material published or written by another individual with the exception of where due reference is used in the text. Jameel Almalki July 30th, 2018 2 Acknowledgements Firstly and most importantly, I want to thank Allah Almighty for giving me blessings, opportunities, strength and guidance to endure this challenging task to the end. My unreserved appreciation and gratitude go to my parents and my brothers and sisters for their continuous support, prayers and encouragement, which gave me the strength to succeed in my PhD research journey. May Allah bless you all. My greatest indebtedness is to my wife, Hamdah, for her endless love, support, patience and sacrifice while I have been consumed with this research in recent years. My thanks and love are also extended to my two precious daughters, Diala and Ladan, and my son, Elias, for all the joy and love in my life. Thank you very much, you are indeed my treasures. I also would like to express my deepest gratitude and appreciation to my supervisor, Dr. Haifeng Shen, for his enthusiastic support, insightful suggestions and valuable guidance throughout this research. Certainly, without his encouragement, invaluable knowledge and support this work would never have been completed.
    [Show full text]
  • David's Advanced Revision Control System
    Hazırlık Darcs Hakkında Pratik Okuma Odevi¨ David’s Advanced Revision Control System Can Burak C¸ilingir1 1Istanbul˙ Bilgi Universitesi¨ Bilgisayar Bilimleri B¨ol¨um¨u [email protected] 5 S¸ubat 2007 Can Burak C¸ilingir Darcs Hazırlık Darcs Hakkında Versiyon Y¨onetimi Pratik Ge¸cmi¸s Okuma Odevi¨ Ne zaman bitecek? 1 Hazırlık Versiyon Y¨onetimi Ge¸cmi¸s 2 Darcs Hakkında 3 Pratik 4 Okuma Odevi¨ Can Burak C¸ilingir Darcs Hazırlık Darcs Hakkında Versiyon Y¨onetimi Pratik Ge¸cmi¸s Okuma Odevi¨ neye yarar? Can Burak C¸ilingir Darcs Hazırlık Darcs Hakkında Versiyon Y¨onetimi Pratik Ge¸cmi¸s Okuma Odevi¨ Aegis, ArX, Arch, BitKeeper, CM Synergy, CVS, Code Co-Op, Codeville, IBM Rational ClearCase, Mercurial, Monotone, OpenCM Perforce, PureCM, RCS, Subversion, Superversion, Vesta, Visual SourceSafe, bazaar-ng, git, monotone, svk http://better-scm.berlios.de/comparison/ http://zooko.com/revision control quick ref.html Can Burak C¸ilingir Darcs Hazırlık Darcs Hakkında Versiyon Y¨onetimi Pratik Ge¸cmi¸s Okuma Odevi¨ Aegis, ArX, Arch, BitKeeper, CM Synergy, CVS, Code Co-Op, Codeville, IBM Rational ClearCase, Mercurial, Monotone, OpenCM Perforce, PureCM, RCS, Subversion, Superversion, Vesta, Visual SourceSafe, bazaar-ng, git, monotone, svk http://better-scm.berlios.de/comparison/ http://zooko.com/revision control quick ref.html Can Burak C¸ilingir Darcs Hazırlık Darcs Hakkında Versiyon Y¨onetimi Pratik Ge¸cmi¸s Okuma Odevi¨ rcs Revision Control System, tek ki¸si cvs Concurrent Versioning System, birden fazla ki¸si svn Subversion, daha d¨uzg¨un
    [Show full text]
  • Esa Study Contract Report
    ESA STUDY CONTRACT REPORT ESA Contract No: Subject: Contractor: ESA ITT Number Current and Future Tech- Distributed Systems Group, AO/3-12280/07/NL/CB nologies for Collaborative Vienna University of Tech- Working Environments nology ESA CR() No: No of volumes: 1 Contractor’s Reference: This Volume No: 1 TEUN Abstract: This document reports the final, detailed result of the study on current and future technologies for collaborative working environments (CWEs). The goal of this study is to analyze current CWEs and whether they and their future trends are suitable for large- scale multinational organizations. To this end, we have analyzed the structure of large-scale organizations in general, and of ESA in particular, with respect to organization, geographical distribution, and IT environments. Requirements for CWEs used in collaborative work are presented. Based on an initial list of criteria given by ESA, we have revised and extended the list to introduce a comprehensive set of criteria for evaluating CWEs. The state-of-the- art CWEs are discussed and classified. We have selected 15 representative CWE products and evaluated and compared them in detail. From the evaluation and comparison of CWE products, we have presented our findings of current issues and future trends of CWEs. In particular, existing products provide many features required by large-scale and multinational organizations but those features are not well-integrated into a single system. Due to the complexity of collaborative work within those organizations, often many CWEs are used in parallel and it is not easy to integrate those CWEs together. The work described in this report was done under ESA Contract.
    [Show full text]
  • Version Control with Git Why Using Version Control?
    Version control with Git Why using version control? • Backup • Easy experimentation with parallel branches • Collaboration across teams • e.g. All of Google’s code lies in one repository • Formal software development process • Tagging of releases • Continuous integration • Pull requests, code reviews Duckietown 2 History of (non-proprietary) version control systems • 1970s: Print everything out. Duckietown 3 History of (non-proprietary) version control systems • 1990s: CVS • Independent history for each single ile. • 2000: Subversion • Client-server architecture. • Repository snapshots, introductions of branches. • 2005: Distributed Version Control (Git, Mercurial, Darcs, Bazaar, …) • Peer-to-peer network of replicated copies. • 2010s: Services on top (Github, Gitlab, …) • Issue tracking, pull requests, continuous integration, … Duckietown 4 Git • Created by Linus Torvalds (1969-, Finnish), author of Linux • Created for Linux kernel development Duckietown 5 Git • Created by Linus Torvalds (1969-, Finnish), author of Linux • Created for Linux kernel development When asked why [Linus Torvalds] called the new software, "git," British slang meaning "a rotten person," he said: “I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git." source Duckietown 6 Jedi knights build their own lightsabers Duckietown 7 A roboticist’s output is typically limited by tools • Learn to use the tools that you have. • Modify the tools to it your needs. • Create new tools. • Learn enough to be able to create the tools that you need. Duckietown 8 Commit graph Duckietown 9 Commit graph master Duckietown 10 Duckietown 11 Git explained with dynamical systems Dynamical system Version control / “patch theory” state Commit graph command transition Patches function hash function (pretend injective) Duckietown 12 “Git Flow” branching model • Git does not impose any semantics on the branches.
    [Show full text]
  • Bill Laboon Friendly Introduction Version Control: a Brief History
    Git and GitHub: A Bill Laboon Friendly Introduction Version Control: A Brief History ❖ In the old days, you could make a copy of your code at a certain point, and release it ❖ You could then continue working on your code, adding features, fixing bugs, etc. ❖ But this had several problems! VERSION 1 VERSION 2 Version Control: A Brief History ❖ Working with others was difficult - if you both modified the same file, it could be very difficult to fix! ❖ Reviewing changes from “Release n” to “Release n + 1” could be very time-consuming, if not impossible ❖ Modifying code locally meant that a crash could take out much of your work Version Control: A Brief History ❖ So now we have version control - a way to manage our source code in a regular way. ❖ We can tag releases without making a copy ❖ We can have numerous “save points” in case our modifications need to be unwound ❖ We can easily distribute our code across multiple machines ❖ We can easily merge work from different people to the same codebase Version Control ❖ There are many kinds of version control out there: ❖ BitKeeper, Perforce, Subversion, Visual SourceSafe, Mercurial, IBM ClearCase, AccuRev, AutoDesk Vault, Team Concert, Vesta, CVSNT, OpenCVS, Aegis, ArX, Darcs, Fossil, GNU Arch, BitKeeper, Code Co-Op, Plastic, StarTeam, MKS Integrity, Team Foundation Server, PVCS, DCVS, StarTeam, Veracity, Razor, Sun TeamWare, Code Co-Op, SVK, Fossil, Codeville, Bazaar…. ❖ But we will discuss git and its most popular repository hosting service, GitHub What is git? ❖ Developed by Linus Torvalds ❖ Strong support for distributed development ❖ Very fast ❖ Very efficient ❖ Very resistant against data corruption ❖ Makes branching and merging easy ❖ Can run over various protocols Git and GitHub ❖ git != GitHub ❖ git is the software itself - GitHub is just a place to store it, and some web-based tools to help with development.
    [Show full text]
  • Anatomy of the Deployment Pipeline
    Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382–3419 [email protected] For sales outside the United States please contact: International Sales [email protected] Visit us on the Web: informit.com/aw Library of Congress Cataloging-in-Publication Data: Humble, Jez. Continuous delivery : reliable software releases through build, test, and deployment automation / Jez Humble, David Farley. p. cm. Includes bibliographical references and index. ISBN 978-0-321-60191-9 (hardback : alk. paper) 1. Computer software--Development. 2. Computer software--Reliability. 3. Computer software--Testing. I. Farley, David, 1959- II. Title. QA76.76.D47H843 2010 005.1--dc22 2010022186 Copyright © 2011 Pearson Education, Inc. All rights reserved. Printed in the United States of America.
    [Show full text]