DOCSLIB.ORG

Distributed Source Code Version Control Systems: Comparison and Usage Evaluation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Distributed Source Code Version Control Systems: Comparison and Usage Evaluation Masaryk University Faculty of Informatics Distributed Source Code Version Control Systems: Comparison and Usage Evaluation Bachelor Thesis Supervisor: Mgr. Ond°ej Krají£ek Michal M¥rka Brno, spring 2006 Declaration Hereby I declare that this paper is my original author craft, which I elabo- rated independently. All the sources and literature I used or drew from during elaboration are cited thoroughly with the full reference to the relevant source. In Brno, on 16th May 2006 ............................................................ 1 Acknowledgements I would like to express my thanks to my bachelor thesis supervisor Mgr. Ond°ej Krají£ek for his advices, comments, and technical support and to Petr Mikulík for proof-reading. 2 Abstract This thesis describes version control systems that oer possibility to use a decen- tralized repository. It shows advantages, disadvantages and rarities of particular systems, depicts their special features. It also notes implementation and prob- lems which can appear during installation of selected systems. Two version control systems supporting distributed repository were picked for the detailed description, Bazaar-NG and Darcs. Keywords version control system, revision control system, software conguration manage- ment 3 Contents 1 Introduction 5 1.1 What is a Version Control System (VCS)? . 5 1.2 Example of work with a VCS . 6 2 General features 8 2.1 CVS . 9 2.2 Subversion . 9 2.3 GNU Arch . 11 2.4 Darcs . 14 2.5 Bazaar-NG . 15 3 Description of details 17 3.1 Installation notes . 17 3.2 Subversion . 17 3.3 Darcs . 19 3.3.1 Darcs patch theory . 20 3.4 Bazaar-NG . 21 4 Conclusion 24 4 Chapter 1 Introduction Version control systems are tools helping to develop software systematically. When the count of developers increases and the number of lines of source code grows, they become essential. Sometimes it is suitable to split the development process into multiple parts, and develop sections of software project separately, or develop particular portion of software functionality by dierent ways and then after some time pick the nest one. That is where the distributed source code management comes in. This work deals with distributed version control systems with emphasis on the open source solution. 1.1 What is a Version Control System (VCS)? The most frustrating software problems are often caused by poor conguration management. The problems are frustrating because they take time to x, they often happen at the worst time, and they are totally unnecessary. For example, a dicult bug that was xed at great expense suddenly reappears; a developed and tested feature is mysteriously missing; or a fully tested program suddenly doesn't work. Conguration management helps to reduce these problems by coordinating the work products of the many dierent people who work on a common project. Without such control, their work will often conict, resulting in problems such as: Simultaneous Update When two or more programmers work separately on the same program, the last one to make the changes can easily destroy the other's work. Shared Code Often, when a bug is xed in code shared by several program- mers, some of them are not notied. Common Code In large systems, when common program functions are mod- ied, all the users need to know. Without eective code management, there is no way to be sure of nding and alerting every user. Versions Most large programs are developed in evolutionary releases. With one release in customer use, another in test, and a third in development, 5 bug xes must be propagated between them. If found by a customer, for example, a bug should be xed in all later versions. Similarly, if a bug is found in a development release, it should be xed in all those prior ver- sions that contained it. In larger systems with several simultaneous active releases and many programmers working on bug xes and enhancements, conicts and confusion are likely. These problems stem from confusion and lack of control, and they can waste an enormous amount of time. The key is to have a control system that answers the following questions: ² What is my current software conguration? ² What is its status? ² How do I control changes to my conguration? ² How do I inform everyone else of my changes? ² What changes have been made to my software? ² Do anyone else's changes aect my software? 1.2 Example of work with a VCS Here is a classic example of work with a VCS, which demonstrates customary command ussage (I'm using Subversion for this example). First a repository have to be created . It is a location, where your (and probably your fellow-programmer's) data will be stored and downloaded from. To create a local repository, run: $ svnadmin create /home/user/repo To see /home/user/svn directory, type : $ svn ls file:///home/user/repo This command returned nothing, because we haven't put anything into the repository yet. So create a checkout directory $ mkdir chdir; cd chdir Download the repository content to your checkout directory. This is the directory where you work with the source code etc. and as soon as you want to save your work, you send your changes to the repository. $ svn checkout file:///home/user/repo Checked out revision 0. $ cd repo 6 Modify the content $ mkdir test; cat > test/foo.txt A file to be added to the repository. ^D Does svn know we've just added a directory and a le? (Now I mean the local checked out copy of ours) $ svn status ? repo/test No, it doesn't. We have to tell svn you want the new le(s) to be added. $ svn add * A test A test/foo.txt $ svn status A test A test/foo.txt Now it does. Did anyone modify the repository content? It is strongly recommended to do this check before commit. Otherwise you can destroy the work of others. $ svn update At revision 0. Lets send our changes to the repository (don't forget to add the message describing what we've just done) $ svn commit -m "committing the test directory and the foo.txt file" Adding test Adding test/foo.txt Transmitting file data . Committed revision 1. Lets check for modications $ svn update At revision 1. View the the log $ svn log r1 | user | 2006-05-12 16:51:59 +0200 (Fri, 12 May 2006) | 1 line committing the test directory and the foo.txt file And nally list the repository content $ svn ls -vR file:///home/user/repo/ 1 user May 12 16:51 test/ 1 user 38 May 12 16:51 test/foo.txt 7 Chapter 2 General features name status decentralization platforms notes CVS old no unix, w32 Use Subversion in- [3] stead. Subversion mature no unix, w32 same idea as CVS [4] GNU arch 1 mature? lines of development unix, maintained but not tla can be shared among limited developed current [5] independent reposi- support users are supported tories for w32 but new users should probably look else- where; complicated GNU Arch not yet lines of development unix, very new, but it is de- 2.0 revc mature can be shared among w32? signed by Tom Lord [6] independent reposi- the original designer tories of arch drawing on lessons from arch, git, and bzr ArX mature? lines of development unix, genetically related to [7] can be shared among limited arch; simpler independent reposi- support tories for w32 DARCS not yet uniquely exible unix, cherry-picking is the [8] mature branching, merging, limited fundamental opera- and cherry-picking of support tion on which all selected patches for w32 workow is based; very easy to learn and easy to use bazaar mature lines of development unix a fork of arch for [9] can be shared among better user interface; independent reposi- a sister project to tories bazaar-ng bazaar-ng not yet lines of development unix, w32 newer; commercial [10] mature can be shared among background funding independent reposi- tories Table 2.1: Key Features Comparison 8 2.1 CVS CVS is enormously popular, and it does the job. In fact, when CVS was released, CVS was a major new innovation in software conguration management (see gure 2.1). However, CVS is now showing its age through a number of awkward limitations: changes are tracked per-le instead of per-change, commits aren't atomic, renaming les and directories is awkward, and its branching limitations mean that you'd better faithfully tag things or there'll be trouble later. Some of the maintainers of the original CVS have declared that the CVS code has become too crusty to eectively maintain. These problems led the main CVS developers to start over and create Subversion. Figure 2.1: CVS architecture 2.2 Subversion Subversion (SVN) is a new system, intending to be a simple replacement of CVS. Subversion is basically a re-implementation of CVS with its warts xed, and it still works the same basic way supporting a centralized repository (see gure 2.2). Like CVS, subversion by itself is intended to support a centralized repository for developers and doesn't handle decentralized development well; the svk project [19] oers a posibility to extend subversion to support decentralized development. From a technology point-of-view you can denitely argue with some of sub- version's decisions. For example, they don't handle changesets as directly as you'd expect given their centrality to the problem. But technical advancement is not the same as utility; for many people who currently use CVS and just want an incremental improvement, subversion is probably more or less what they were expecting and looking for. But there are weaknesses, for example, Subversion doesn't keep track of which patches have already been applied on a given branch, and trying to reapply a patch more than once causes problems.
Load more

Recommended publications
  • Tortoisemerge a Diff/Merge Tool for Windows Version 1.11
    TortoiseMerge A diff/merge tool for Windows Version 1.11 Stefan Küng Lübbe Onken Simon Large TortoiseMerge: A diff/merge tool for Windows: Version 1.11 by Stefan Küng, Lübbe Onken, and Simon Large Publication date 2018/09/22 18:28:22 (r28377) Table of Contents Preface ........................................................................................................................................ vi 1. TortoiseMerge is free! ....................................................................................................... vi 2. Acknowledgments ............................................................................................................. vi 1. Introduction .............................................................................................................................. 1 1.1. Overview ....................................................................................................................... 1 1.2. TortoiseMerge's History .................................................................................................... 1 2. Basic Concepts .......................................................................................................................... 3 2.1. Viewing and Merging Differences ...................................................................................... 3 2.2. Editing Conflicts ............................................................................................................. 3 2.3. Applying Patches ...........................................................................................................
    [Show full text]
  • Introduction to Version Control with Git
    Warwick Research Software Engineering Introduction to Version Control with Git H. Ratcliffe and C.S. Brady Senior Research Software Engineers \The Angry Penguin", used under creative commons licence from Swantje Hess and Jannis Pohlmann. March 12, 2018 Contents 1 About these Notes1 2 Introduction to Version Control2 3 Basic Version Control with Git4 4 Releases and Versioning 11 Glossary 14 1 About these Notes These notes were written by H Ratcliffe and C S Brady, both Senior Research Software Engineers in the Scientific Computing Research Technology Platform at the University of Warwick for a series of Workshops first run in December 2017 at the University of Warwick. This document contains notes for a half-day session on version control, an essential part of the life of a software developer. This work, except where otherwise noted, is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Li- cense. To view a copy of this license, visit http://creativecommons.org/ licenses/by-nc-nd/4.0/. The notes may redistributed freely with attribution, but may not be used for commercial purposes nor altered or modified. The Angry Penguin and other reproduced material, is clearly marked in the text and is not included in this declaration. The notes were typeset in LATEXby H Ratcliffe. Errors can be reported to [email protected] 1.1 Other Useful Information Throughout these notes, we present snippets of code and pseudocode, in particular snippets of commands for shell, make, or git. These often contain parts which you should substitute with the relevant text you want to use.
    [Show full text]
  • Ethereal Developer's Guide Draft 0.0.2 (15684) for Ethereal 0.10.11
    Ethereal Developer's Guide Draft 0.0.2 (15684) for Ethereal 0.10.11 Ulf Lamping, Ethereal Developer's Guide: Draft 0.0.2 (15684) for Ethere- al 0.10.11 by Ulf Lamping Copyright © 2004-2005 Ulf Lamping Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation. All logos and trademarks in this document are property of their respective owner. Table of Contents Preface .............................................................................................................................. vii 1. Foreword ............................................................................................................... vii 2. Who should read this document? ............................................................................... viii 3. Acknowledgements ................................................................................................... ix 4. About this document .................................................................................................. x 5. Where to get the latest copy of this document? ............................................................... xi 6. Providing feedback about this document ...................................................................... xii I. Ethereal Build Environment ................................................................................................14 1. Introduction .............................................................................................................15
    [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]
  • Steve Burnett Education Employment
    Steve Burnett Raleigh NC [email protected] More details and attached recommendations at http://www.linkedin.com/in/steveburnett Education 1992 M.S. Technical Communication, North Carolina State University 1992 Emergency Medical Technician, Wake Technical Community College 1989 B.A. History, B.A. Economics, NCSU Employment Information Developer III, Hewlett-Packard (formerly Opsware) (November 2007 – present) (HP acquired Opsware effective November 2007.) Creating install, user, and administrator guides for HP SAR (Service Automation Reporter, formerly Opsware OMDB) and HP Live Network (formerly TON) on Linux, Solaris, VMware, and Windows platforms. Sole documentation support for OMDB (1.0, had contributing author for the 1.0.2 release), SAR (7.0, 7.50), and HP Live Network (1.0 to 1.30). Provided Web QA for the HP Live Network Portal. Tools: FrameMaker 7, WebWorks, ClearCase, subversion, RapidSVN, Eclipse, Bugzilla, HP Quality Center, Collabnet, BIRT Report Designer, WebEx, MS SharePoint. Senior Technical Writer, Opsware (January – November 2007) Created install, user, and administrator guides for Opsware OMDB (Operational Management Database) and TON (The Opsware Network) on Linux, Solaris, and Windows platforms. Worked with Technical Support on CMS selection. Tools: FrameMaker 7, WebWorks, ClearCase, subversion, Bugzilla, Quality Center, Collabnet, BIRT Report Designer, WebEx. Technical Writer, SAS Institute (contract, Apex Systems) (November 2005 – January 2007) SAS Technical Support: Internal and external documentation. Tools: SAS, SIRIUS, SOS. SAS R&D: Internal and external documentation. Tools: SAS, WebLogic, Xythos, SQL. Systems Administrator, SAS Institute (contract, Apex Systems) (March – September 2005) SAS Solutions: Provided Linux, Windows, Solaris, and HP-UX server system administration, technical support, and internal training for an ASP (application service provider) team.
    [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]
  • 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]
  • Extreme Programming Unit Testing
    Programming Tools Lecture Plan for Group Projects ● Unit testing ● Version control ● Building Richard Smith ● Debugging [email protected] – Logging ● Documenting – Code – Reports 1 2 Biased General advice ● Use a Unix based operating system – Solaris in the labs – Mac OS X if you are buying a laptop – Install Linux if you have a PC at home Unit testing ● Learn how to do everything using the command line, then use an IDE! – Xemacs – difficult to learn, but integrates well with command line and has modes for everything – Eclipse – easier to learn, specialised for Java ● Use Java or C++ or 'script' (Python, Ruby, Perl) as appropriate 3 4 Background: Extreme Unit Testing Programming ● Pair programming ● Write tests before code. ● Small releases ● Code not done until tests all run. ● Metaphor ● Re-run tests after any major changes ● Simple design ● Can be confident that nothing has ● Testing broken. ● Refactoring ● Hence not afraid to refactor. www.extremeprogramming.org 5 6 Tools for Testing Installing CPPUnit ● Some functional tests can be manual. ● We use GNU compiler on Unix-like OS (Linux, FreeBSD) ● Possible to automate most tests. ● wget http://aleron.dl.sourceforge.net/sourceforge/cppunit/cppuni ● Tools exist to make this easy and t-1.10.2.tar.gz provide GUI. ● tar xvfz cppunit-1.10.2.tar.gz ● cd cppunit-1.10.2 ● Java – JUnit – www.junit.org ● ./configure; make ● C++ – CPPunit – cppunit.sf.net ● su -c 'make install' ● su -c 'ldconfig' ● Installation of GUI library is a bit more complicated :-( 7 8 Or you can use mine! C++ Example ● bash ● Class diagram ● export LD_LIBRARY_PATH=/cs/research/nets/home/marine/ucacrts /g2/local/lib ● export PATH=/cs/research/nets/home/marine/ucacrts/g2/local/b in:$PATH 9 10 C++ Example C++ Example Cat.h Animal.
    [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]
  • Create a Pull Request in Bitbucket
    Create A Pull Request In Bitbucket Waverley is unprofitably bombastic after longsome Joshuah swings his bentwood bounteously. Despiteous Hartwell fathomsbroaches forcibly. his advancements institutionalized growlingly. Barmiest Heywood scandalize some dulocracy after tacit Peyter From an effect is your own pull remote repo bitbucket create the event handler, the bitbucket opens the destination branch for a request, if i am facing is Let your pet see their branches, commit messages, and pull requests in context with their Jira issues. You listen also should the Commits tab at the top gave a skill request please see which commits are included, which provide helpful for reviewing big pull requests. Keep every team account to scramble with things, like tablet that pull then got approved, when the build finished, and negotiate more. Learn the basics of submitting a on request, merging, and more. Now we made ready just send me pull time from our seven branch. Awesome bitbucket cloud servers are some nifty solutions when pull request a pull. However, that story ids will show in the grasp on all specified stories. Workzone can move the trust request automatically when appropriate or a percentage of reviewers have approved andor on successful build results. To cost up the webhook and other integration parameters, you need two set although some options in Collaborator and in Bitbucket. Go ahead but add a quote into your choosing. If you delete your fork do you make a saw, the receiver can still decline your request ask the repository to pull back is gone. Many teams use Jira as the final source to truth of project management.
    [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]