DOCSLIB.ORG

Monotone: a Distributed Version Control System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Monotone: a Distributed Version Control System Monotone A distributed version control system Graydon Hoare and others This manual is for the \monotone" distributed version control system. This edition docu- ments version 1.1. Copyright c 2003, 2004, 2011 Graydon Hoare Copyright c 2004, 2005, 2006 Nathaniel Smith Copyright c 2005 - 2010 Derek Scherger Copyright c 2005, 2006 Daniel Carosone Copyright c 2006 Jeronimo Pellegrini Copyright c 2006 Alex Queiroz Copyright c 2006, 2007 William Uther Copyright c 2006 - 2010 Thomas Keller Copyright c 2007 - 2012 Stephen Leake This manual is made available under the GNU GPL version 2.0 or greater. See the accom- panying file COPYING for details. i Table of Contents 1 Concepts :::::::::::::::::::::::::::::::::::::::: 1 1.1 Versions of files :::::::::::::::::::::::::::::::::::::::::::::::: 2 1.2 Versions of trees:::::::::::::::::::::::::::::::::::::::::::::::: 4 1.3 Historical records :::::::::::::::::::::::::::::::::::::::::::::: 6 1.4 Certificates::::::::::::::::::::::::::::::::::::::::::::::::::::: 8 1.5 Storage and workflow ::::::::::::::::::::::::::::::::::::::::: 10 1.6 Forks and merges ::::::::::::::::::::::::::::::::::::::::::::: 13 1.7 Branches:::::::::::::::::::::::::::::::::::::::::::::::::::::: 15 1.7.1 Heads and merging ::::::::::::::::::::::::::::::::::::::: 15 1.7.2 Branch Names ::::::::::::::::::::::::::::::::::::::::::: 17 2 Tutorial :::::::::::::::::::::::::::::::::::::::: 19 2.1 Issues ::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 19 2.1.1 Standard Options :::::::::::::::::::::::::::::::::::::::: 19 2.1.2 Revision Selectors :::::::::::::::::::::::::::::::::::::::: 19 2.2 The Fictional Project ::::::::::::::::::::::::::::::::::::::::: 20 2.3 Creating a Database :::::::::::::::::::::::::::::::::::::::::: 21 2.4 Generating Keys :::::::::::::::::::::::::::::::::::::::::::::: 22 2.5 Starting a New Project:::::::::::::::::::::::::::::::::::::::: 24 2.6 Adding Files :::::::::::::::::::::::::::::::::::::::::::::::::: 25 2.7 Committing Work::::::::::::::::::::::::::::::::::::::::::::: 28 2.8 Basic Network Service::::::::::::::::::::::::::::::::::::::::: 30 2.9 Synchronising Databases :::::::::::::::::::::::::::::::::::::: 31 2.10 Making Changes ::::::::::::::::::::::::::::::::::::::::::::: 32 2.11 Dealing with a Fork :::::::::::::::::::::::::::::::::::::::::: 35 2.12 Branching and Merging :::::::::::::::::::::::::::::::::::::: 38 2.13 Network Service Revisited:::::::::::::::::::::::::::::::::::: 40 3 Advanced Uses :::::::::::::::::::::::::::::::: 45 3.1 Other Transports ::::::::::::::::::::::::::::::::::::::::::::: 46 3.2 Selectors :::::::::::::::::::::::::::::::::::::::::::::::::::::: 47 3.3 Restrictions ::::::::::::::::::::::::::::::::::::::::::::::::::: 52 3.4 Scripting:::::::::::::::::::::::::::::::::::::::::::::::::::::: 54 3.5 Inodeprints ::::::::::::::::::::::::::::::::::::::::::::::::::: 54 3.6 Merge Conflicts ::::::::::::::::::::::::::::::::::::::::::::::: 55 3.6.1 Conflict Types ::::::::::::::::::::::::::::::::::::::::::: 55 3.7 Workspace Collisions :::::::::::::::::::::::::::::::::::::::::: 61 3.8 Quality Assurance :::::::::::::::::::::::::::::::::::::::::::: 63 3.9 Vars :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 64 3.10 Managed Databases :::::::::::::::::::::::::::::::::::::::::: 65 3.11 Reserved Files ::::::::::::::::::::::::::::::::::::::::::::::: 67 3.12 Reserved Certs::::::::::::::::::::::::::::::::::::::::::::::: 69 ii monotone documentation 3.13 Naming Conventions ::::::::::::::::::::::::::::::::::::::::: 71 3.14 File Attributes ::::::::::::::::::::::::::::::::::::::::::::::: 72 3.15 Migrating and Dumping:::::::::::::::::::::::::::::::::::::: 73 3.16 Importing from CVS ::::::::::::::::::::::::::::::::::::::::: 74 3.17 Exporting to GIT :::::::::::::::::::::::::::::::::::::::::::: 75 3.18 Using packets :::::::::::::::::::::::::::::::::::::::::::::::: 77 3.19 Bisecting :::::::::::::::::::::::::::::::::::::::::::::::::::: 80 4 Command Reference :::::::::::::::::::::::::: 81 4.1 Global and Common Options:::::::::::::::::::::::::::::::::: 82 4.1.1 Global Options::::::::::::::::::::::::::::::::::::::::::: 82 4.1.2 Common Options :::::::::::::::::::::::::::::::::::::::: 84 4.2 Tree :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 85 4.2.1 Conflicts ::::::::::::::::::::::::::::::::::::::::::::::::: 89 4.3 Workspace :::::::::::::::::::::::::::::::::::::::::::::::::::: 91 4.4 Network :::::::::::::::::::::::::::::::::::::::::::::::::::::: 97 4.5 Informative :::::::::::::::::::::::::::::::::::::::::::::::::: 100 4.6 Review :::::::::::::::::::::::::::::::::::::::::::::::::::::: 108 4.7 Variables :::::::::::::::::::::::::::::::::::::::::::::::::::: 109 4.8 Key and Cert :::::::::::::::::::::::::::::::::::::::::::::::: 111 4.9 Packet I/O :::::::::::::::::::::::::::::::::::::::::::::::::: 113 4.10 Database ::::::::::::::::::::::::::::::::::::::::::::::::::: 114 4.11 Automation :::::::::::::::::::::::::::::::::::::::::::::::: 119 4.12 VCS :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 180 5 Formats ::::::::::::::::::::::::::::::::::::::: 183 5.1 basic_io Format :::::::::::::::::::::::::::::::::::::::::::: 183 6 Lua Reference :::::::::::::::::::::::::::::::: 185 6.1 Hooks ::::::::::::::::::::::::::::::::::::::::::::::::::::::: 186 6.1.1 Common Data Types ::::::::::::::::::::::::::::::::::: 186 6.1.2 Event Notifications and Triggers::::::::::::::::::::::::: 186 6.1.3 User Defaults ::::::::::::::::::::::::::::::::::::::::::: 189 6.1.4 Netsync Permission Hooks :::::::::::::::::::::::::::::: 193 6.1.5 Netsync Transport Hooks ::::::::::::::::::::::::::::::: 195 6.1.6 Trust Evaluation Hooks ::::::::::::::::::::::::::::::::: 197 6.1.7 External Diff Tools:::::::::::::::::::::::::::::::::::::: 198 6.1.8 External Merge Tools ::::::::::::::::::::::::::::::::::: 199 6.1.9 Selector Expansion :::::::::::::::::::::::::::::::::::::: 200 6.1.10 Attribute Handling::::::::::::::::::::::::::::::::::::: 201 6.1.11 GIT Export Hooks ::::::::::::::::::::::::::::::::::::: 202 6.1.12 Validation Hooks::::::::::::::::::::::::::::::::::::::: 203 6.2 Additional Lua Functions :::::::::::::::::::::::::::::::::::: 204 6.3 Implementation Differences :::::::::::::::::::::::::::::::::: 208 iii 7 Special Topics :::::::::::::::::::::::::::::::: 209 7.1 Internationalization :::::::::::::::::::::::::::::::::::::::::: 210 7.2 Hash Integrity ::::::::::::::::::::::::::::::::::::::::::::::: 213 7.3 Rebuilding ancestry :::::::::::::::::::::::::::::::::::::::::: 216 7.4 Regular Expression Syntax ::::::::::::::::::::::::::::::::::: 218 7.4.1 Regexp Syntax Summary:::::::::::::::::::::::::::::::: 218 7.4.2 Regexp Details :::::::::::::::::::::::::::::::::::::::::: 225 Appendix A Default hooks:::::::::::::::::::: 255 General Index :::::::::::::::::::::::::::::::::::: 289 Chapter 1: Concepts 1 1 Concepts This chapter should familiarize you with the concepts, terminology, and behavior described in the remainder of the user manual. Please take a moment to read it, as later sections will assume familiarity with these terms. 2 monotone documentation 1.1 Versions of files Suppose you wish to modify a file file.txt on your computer. You begin with one version of the file, load it into an editor, make some changes, and save the file again. Doingso produces a new version of the file. We will say that the older version of the file wasa parent, and the new version is a child, and that you have performed an edit between the parent and the child. We may draw the relationship between parent and child using a graph, where the arrow in the graph indicates the direction of the edit, from parent to child. file.txt parent version file.txt child version We may want to identify the parent and the child precisely, for sake of reference. To do so, we will compute a cryptographic hash function, called sha1, of each version. The details of this function are beyond the scope of this document; in summary, the sha1 function takes a version of a file and produces a short string of 20 bytes, which we will use touniquely identify the version1. Now our graph does not refer to some \abstract" parent and child, but rather to the exact edit we performed between a specific parent and a specific child. file.txt SHA1 65f1bde1f38262034e7c3457301e8f736ba6381b parent version file.txt SHA1 a91566316d208dc405795904f8d67ae3a0e765cb child version When dealing with versions of files, we will dispense with writing out “file names", and identify versions purely by their sha1 value, which we will also refer to as their file ID. Using IDs alone will often help us accommodate the fact that people often wish to call files 1 We say sha1 values are \unique" here, when in fact there is a small probability of two different versions having the same sha1 value. This probability is very small, so we discount it. Chapter 1: Concepts 3 by different names. So now our graph of parent and child is just a relationship betweentwo versions, only identified by ID. 65f1bde1f38262034e7c3457301e8f736ba6381b parent version a91566316d208dc405795904f8d67ae3a0e765cb child version Version control systems, such as monotone, are principally concerned with the storage and management of multiple versions of some files. One way to store multiple versions ofa file is, literally, to save a separate complete copy of the file, every time you make a change. When necessary, monotone will save complete copies of your files, compressed with the zlib compression format. Hello there Hello Hello, World! world, how do you do? 1st version 2nd version 3rd version Often we find that successive versions of a file are
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]
  • 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]
  • 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]
  • CSE 391 Lecture 9
    CSE 391 Lecture 9 Version control with Git slides created by Ruth Anderson & Marty Stepp, images from http://git-scm.com/book/en/ http://www.cs.washington.edu/391/ 1 Problems Working Alone • Ever done one of the following? . Had code that worked, made a bunch of changes and saved it, which broke the code, and now you just want the working version back… . Accidentally deleted a critical file, hundreds of lines of code gone… . Somehow messed up the structure/contents of your code base, and want to just “undo” the crazy action you just did . Hard drive crash!!!! Everything’s gone, the day before deadline. • Possible options: . Save as (MyClass-v1.java) • Ugh. Just ugh. And now a single line change results in duplicating the entire file… 2 Problems Working in teams . Whose computer stores the "official" copy of the project? • Can we store the project files in a neutral "official" location? . Will we be able to read/write each other's changes? • Do we have the right file permissions? • Lets just email changed files back and forth! Yay! . What happens if we both try to edit the same file? • Bill just overwrote a file I worked on for 6 hours! . What happens if we make a mistake and corrupt an important file? • Is there a way to keep backups of our project files? . How do I know what code each teammate is working on? 3 Solution: Version Control • version control system: Software that tracks and manages changes to a set of files and resources. • You use version control all the time .
    [Show full text]
  • Software Development a Practical Approach!
    Software Development A Practical Approach! Hans-Petter Halvorsen https://www.halvorsen.blog https://halvorsen.blog Software Development A Practical Approach! Hans-Petter Halvorsen Software Development A Practical Approach! Hans-Petter Halvorsen Copyright © 2020 ISBN: 978-82-691106-0-9 Publisher Identifier: 978-82-691106 https://halvorsen.blog ii Preface The main goal with this document: • To give you an overview of what software engineering is • To take you beyond programming to engineering software What is Software Development? It is a complex process to develop modern and professional software today. This document tries to give a brief overview of Software Development. This document tries to focus on a practical approach regarding Software Development. So why do we need System Engineering? Here are some key factors: • Understand Customer Requirements o What does the customer needs (because they may not know it!) o Transform Customer requirements into working software • Planning o How do we reach our goals? o Will we finish within deadline? o Resources o What can go wrong? • Implementation o What kind of platforms and architecture should be used? o Split your work into manageable pieces iii • Quality and Performance o Make sure the software fulfills the customers’ needs We will learn how to build good (i.e. high quality) software, which includes: • Requirements Specification • Technical Design • Good User Experience (UX) • Improved Code Quality and Implementation • Testing • System Documentation • User Documentation • etc. You will find additional resources on this web page: http://www.halvorsen.blog/documents/programming/software_engineering/ iv Information about the author: Hans-Petter Halvorsen The author currently works at the University of South-Eastern Norway.
    [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]
  • Analysis of SVN Repositories for Remote Access
    Analysis of SVN Repositories for Remote Access Sadaf Solangi and Safeeullah Soomro Suhni Abbasi Department of Computing and Technology Institute of Information Technology Center Faculty of Engineering & Technology, Indus University Faculty of Social Sciences, Sindh Agricultural Karachi, Pakisstan University Tando Jam, Pakistan e-mail:{sadaf.solangi,ssoomro}@indus.edu.pk [email protected] Abstract— Software Evolution is considered to be essential and collections [10].How digital repositories were well used and challenging characteristic in the field of software engineering. for what, by address of recording [7]. Version control system is an incremental versions tracking system, introduced to avoid unnecessary overwriting of files A. SVN Repository such as programming code, web pages and records. It also helps to decrease the confusion affected by duplicate or A repository is information about the database that is shared outdated data. In this proposed research SVN repository is engineered artifacts created and used by enterprise. A common maintained and analyzed for msitone.wikispaces.com to repository allows instruments to share information, not including minimize the efforts as well as resources for the future users. a common Repository, and it will need a particular protocol We have used two semester data for the analysis purpose that Exchange of information between machines [13].Examples of is observed SVN repository. The result shows that, such sample includes, software, documents etc. Repository implementing the SVN repositories are helpful for has three types of sessions such as trunk, branches and maintenance of the Wikispaces as it also reduce the cost, time and efforts for their evolution. Whereas without implementing tags.
    [Show full text]
  • Darcs: Distributed Version Management in Haskell
    Introduction to darcs What worked and what didn’t Second half of talk... Conclusion Darcs: Distributed Version Management in Haskell David Roundy Cornell University September 30, 2005 David Roundy Darcs: Distributed Version Management in Haskell Introduction to darcs What worked and what didn’t Second half of talk... Conclusion Some incomprehensible equations A classical density functional F [ρ] for the free energy of a fluid is given by Z F [ρ] = d~r [f ideal (ρ(~r)) + f exc (¯ρ(~r)) + ρ(~r)ξ(~r)] (1) where the weighted densityρ ¯ is defined by Z ρ¯(~r) = d~r 0ρ(~r 0)W (~r −~r 0) (2) and the correction term ρ(~r)ξ(~r) is determined by Z 0 0 0 0 ξ(~r) = − d~r ρ(~r )(kB TC(~r −~r ) + W (~r −~r )) (3) where C(∆~r) is the direct correlation function. δ2F = −k T ρ(~r)[δ(~r −~r 0) + C(~r −~r 0)] (4) δρ(~r)δρ(~r 0) B David Roundy Darcs: Distributed Version Management in Haskell Introduction to darcs What worked and what didn’t Second half of talk... Conclusion Outline Introduction to darcs Ideas behind darcs What worked and what didn’t A pure functional language for an SCM? Laziness and unsafeInterleaveIO Object-oriented-like data structures QuickCheck Foreign Function Interface Efficient string handling Handles and zlib and threads Error handling and cleanup Optimization experiences David Roundy Darcs: Distributed Version Management in Haskell Introduction to darcs Ideas behind darcs What worked and what didn’t Distributed rather than centralized Second half of talk..
    [Show full text]
  • Open Source Version Control Thomas Keller HTWK Leipzig
    Open Source Version Control Thomas Keller HTWK Leipzig University Of Applied Sciences Department Computer Science, Mathematics & Natural Sciences Bachelor Thesis in Media Computer Science Open Source Version Control Thomas Keller Tutor: Prof. Dr. Michael Frank Co-tutor: Prof. Dr. Klaus Hering Date of Completion: March 20th, 2006 I affirm that I have created this Bachelor Thesis independently and only with the use of the documented references. Leipzig, in March 2006 ........................................................................... This work is licensed under the terms of the GNU Free Documentation License. See chapter Copyright Notices for details. I would like to thank My beloved girl (soon wife) Marlen, who always supported me during the process of writing this work, My tutor, Mr Prof Dr Michael Frank, who always had a sympathetic ear for my concerns, My good friend Chad Connolly from Delaware/USA, who helped me a great deal to find and fix spelling issues in this work, And finally my cousin Martin Fischer, another guy who has helped me a lot with his positive criticism. Thank you all! Table of Contents Preface.....................................................................................................................................................1 Vorwort...................................................................................................................................................2 Document Conventions...........................................................................................................................3
    [Show full text]
  • A Practical Introduction to Version Control Systems
    Version Control Systems Centralised - SVN Decentralised - Git A Practical Introduction to Version Control Systems A random CAKES(less) talk on a topic I hope others find useful! Andrew Brampton [email protected] 4th February 2009 Andrew Brampton A Practical Introduction to Version Control Systems Version Control Systems Centralised - SVN Decentralised - Git Outline 1 Version Control Systems What is Version Control Basic Principles Versioning Models 2 Centralised - SVN Overview Commands 3 Decentralised - Git Overview Commands Andrew Brampton A Practical Introduction to Version Control Systems Version Control Systems What is Version Control Centralised - SVN Basic Principles Decentralised - Git Versioning Models What can version control do for you? Backup your work Rollback changes The original time machine Collaborate with others Multiple users can share and edit documents Access documents online If your repository is online, you can easily access your files anywhere Andrew Brampton A Practical Introduction to Version Control Systems Version Control Systems What is Version Control Centralised - SVN Basic Principles Decentralised - Git Versioning Models The Repository Description Where all the files and directories are stored Stores the histories of all your files and directories Users read and write files to it Andrew Brampton A Practical Introduction to Version Control Systems Version Control Systems What is Version Control Centralised - SVN Basic Principles Decentralised - Git Versioning Models The Working Copy Description A local copy
    [Show full text]
  • Revision Control Systems
    Revision Control Systems ● Definition ● Quick recap of general use ● Terms used often ● History ● Two advanced concepts Definition ● System used to reliably reproduce specific revision of software over time Quick recap of general use ● scm checkout software-1.0 ● Edit and test in your local sandbox ● scm checkin ● “I added a new feature that does X” ● scm branch mainline software-2.1 ● scm merge feature-branch software-1.1 Terms used often ● Repository ● Revision ● Checkout ● Commit Terms used often (continued) ● Mainline or Trunk ● Branch ● Merge ● Tag History ● SCCS ● RCS/CVS ● Subversion ● First Wave DVCS: Arch, Monotone ● Current Wave DVCS: Bazaar, Mercurial, Git SCCS ● First revision control system ● Single file based ● Control records ● Delta table ● Revision information: who, when, changes RCS ● Checkout needs locks ● Single file based, history stored in filename,v ● Tags for groups of files ● Reverse deltas and forward deltas ● Revision information: who, when, changes, branch, tags CVS ● No locks ● Client / server ● Anonymous readonly access ● Previous de-facto open source RCS CVS, continued ● Revision information: who, when, changes, branch, tags ● cvs log boot.c RCS file: /cvs/src/sys/arch/sparc/stand/boot/boot.c,v Working file: boot.c head: 1.6 branch: locks: strict access list: symbolic names: OPENBSD_4_7: 1.6.0.26 [...] keyword substitution: kv total revisions: 12; selected revisions: 1 description: ---------------------------- revision 1.3 date: 2002/03/14 01:26:44; author: millert; state: Exp; lines: +5 -5 First round of
    [Show full text]