DOCSLIB.ORG

The Old Good Time Backups

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Abstract This presentation is an introduction to Version Control Systems, and in particular, modern and decentralized ones. We start with a presentation of the problems to solve, and the historical solutions, presenting briefly CVS and its successor Sub- Distributed Version Control Systems version, and give an idea of the requirements not meet by these systems with the example of the Linux kernel. The talk presents then the notion of Decentralized (or “distributed”) Version Con- Matthieu Moy trol System, with the example of Bazaar (also known as bzr). Without going into details, we present the way branching and merging is managed in such systems. Computer Science and Automation The conclusion gives pointers to learn more about Bazaar and its competitors. Indian Institute of Science Bangalore About the Author: Matthieu Moy, has been contributing to Baz, the ancestor of Bazaar. He is one of the main contributor of Emacs-DVC, the Emacs interface to October 2006 several version control systems (GNU Arch, Bazaar, Mercurial, cogito. ). Matthieu Moy (CSA/IISc) DVC October 2006 < 1 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 2 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Outline Backups: The Old Good Time Basic problems: 1 Motivations, Prehistory I “Oh, my disk crashed.” / “Someone has stolen my laptop!” I “@#%!!, I’ve just deleted this important file!” 2 History and Categories of Version Control Systems I “Oops, I introduced a bug a long time ago in my code, how can I see how it was before?” Historical solutions: 3 Version Control for the Linux Kernel I Replicate: $ cp -r ~/project/ ~/backup/ 4 Bazaar (bzr): One Decentralized Revision Control System I Keep history: $ cp -r ~/project/ ~/backup/project-2006-10-4 5 Conclusion I Keep a description of history: $ echo "Description of current state" > \ ~/backup/project-2006-10-4/README.txt Matthieu Moy (CSA/IISc) DVC October 2006 < 2 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 4 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Backups: Improved Solutions Collaborative Development: The Old Good Time Basic problems: Several persons working on the same set of files 1 “Hey, you’ve modified the same file as me, how do we merge?”, 2 “Your modifications are broken, your code doesn’t even compile. Fix Replicate over multiple machines your changes before sending it to me!”, Incremental backups: Store only the changes compared to previous 3 “Your bug fix here seems interesting, but I don’t want your other revision changes”. I With file granularity Historical solutions: I With finer-grained (diff) I Never two person work at the same time. When one person stops Many tools available: working, (s)he sends his/her work to the others. I Standalone tools: rsync, rdiff-backup,... ⇒ Doesn’t scale up! Unsafe. I Versionned filesystems: VMS, Windows 2003+, cvsfs, . I People work on the same directory (same machine, NFS, . ) ⇒ Painful because of (2) above. I People lock the file when working on it. ⇒ Doesn’t scale up! I People work trying to avoid conflicts, and merge later. Matthieu Moy (CSA/IISc) DVC October 2006 < 5 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 6 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Merging: Problem and Solution Merging My version Your version Common ancestor Space of possible revisions #include <stdio.h> #include <stdio.h> #include <stdio.h> (arbitrarily represented in 2D) Merged revision int main () { int main () { int main () { Mine printf("Hello"); printf("Hello!\n"); printf("Hello"); return EXIT_SUCCESS; return 0; return 0; } } } Tools like diff3 can solve this Yours Ancestor Merging relies on history! Collaborative development linked to backups Matthieu Moy (CSA/IISc) DVC October 2006 < 7 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 8 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Revision Control System: Basic Idea CVS: The Centralized Approach Keep track of history: I User makes modification and use commit to keep a snapshot of the current state, Configuration: I Meta-data (user’s name, date, descriptive message,. ) recorded together with the state of the project. I 1 repository (contains all about the history of the project) 1 working copy per user (contains only the files of the project) Use it for merging/collaborative development. I Basic operations: I Each user works on its own copy, I : get a new working copy I User explicitly “takes” modifications from others when (s)he wants. checkout I update: update the working copy to include new revisions in the Efficient storage (“delta-compression” ≈ incremental backups): repository I At least at file level (git) I commit: record a new revision in the repository I Usually store a concatenation of diffs (Optional) notion of branch: I Set of revisions recorded, but not visible in mainline, I Can be merged into mainline when ready. Matthieu Moy (CSA/IISc) DVC October 2006 < 9 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 11 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion CVS: Example Commit/Update Approach Start working on a project: Space of possible revisions $ cvs checkout project "commit" creates new revision $ cd project Work on it: New $ vi foo.c # or whatever upstream User runs "update" See if other users did something, and if so, get their modifications: revisions $ cvs update And so on ... ! Review local changes: $ cvs diff Record local changes in the repository (make it visible to others): $ cvs commit -m "Fixed incorrect Hello message" Existing revision Matthieu Moy (CSA/IISc) DVC October 2006 < 12 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 13 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Conflicts Conflicts: an Example Someone added \n, someone else added !: #include <stdio.h> When several users change the same line of code concurrently, int main () { Impossible for the tool to guess which version to take, <<<<<<< hello.c ⇒ CVS leaves both versions with explicit markers, user resolves printf("Hello\n"); manually. ======= Merge tools (Emacs’s smerge-mode, . ) can help. printf("Hello!"); >>>>>>> 1.6 return EXIT_SUCCESS; } Matthieu Moy (CSA/IISc) DVC October 2006 < 14 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 15 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion CVS: Obvious Limitations Subversion: A Replacement for CVS Idea of subversion: drop-in replacement for CVS (could have been File-based system. No easy way to get back to a consistant old “CVS, version 2”, fix the obvious limitation, but no major revision. change/innovation: No management of rename (remove + add) I Atomic, tree-wide commits (commit is either successful or unsuccessful, but not half), Bad performances I Rename management, I Optimized performances, some operations available offline. Matthieu Moy (CSA/IISc) DVC October 2006 < 16 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 17 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Remaining Limitations Decentralized Revision Control Systems Weak support for branching, Most operations can not be performed offline, Idea: not just 1 central repository. Each user has his own repository. Permission management: By default, operations (including commit are done on the user’s I Allowing anyone on earth to commit compromises the security, private branch) I Denying someone permission to commit means this user can not use most of the features Users publish their repository, and request a merge. I Constraint acceptable for private project, but painful for Free Software in particular. Matthieu Moy (CSA/IISc) DVC October 2006 < 18 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 19 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History Linux Bazaar Conclusion Linux: A Project With Huge Needs in Version Control A bit of history 1991: Linus Torvalds starts writing Linux, using CVS, 2002: Linux adopts BitKeeper, a proprietary decentralized version Not the biggest Open-Source project, but probably the most active, control system (available free of cost for Linux), ≈ 10Mb of patch per month, 2002-2005: Flamewars against BitKeeper, some Free Software ≈ 20,000 files, 280Mb of sources. alternatives appear (GNU Arch, Darcs, Monotone). None are Many branches: good enough technically. I Short life: work on a feature in a branch, request merge when ready. 2005: BitKeeper’s free of cost license revoked. Linux has to I Long life: things that are unlikely to get into the official kernel before some time (grsecurity, reiserfs4, SELinux in the past, . ) migrate. I Test, debug: a modification goes through several branches, is tested 2005: Unsatisfied by the alternatives, Linus decides to start his own there, before getting into mainline project, git. Distributor: Most distributions maintain a modified version of Linux I 2006: Many young, but good projects for decentralized revision ⇒ Centralized revision control is not manageable. control: Darcs, git, Monotone, Mercurial, Bazaar, . 200?: Most likely, several projects will continue to compete, but I guess only 2 or 3 of the best will be widely adopted. Matthieu Moy (CSA/IISc) DVC October 2006 < 21 / 43 > Matthieu Moy (CSA/IISc) DVC October 2006 < 22 / 43 > Prehistory History Linux Bazaar Conclusion Prehistory History
Recommended publications
  • Efficient Algorithms for Comparing, Storing, and Sharing

    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.
  • Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management

    Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management

    Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management Configuration Management (CM) systems are used to store code and other artifacts in Software Engineering projects. Since the early 70’s, there has been a progression of CM systems used for Software CM, starting with SCCS, and continuing through RCS, CVS, and Subversion. All of these systems used a single, centralized repository structure. Distributed Configuration Management As opposed to traditional CM systems, Distributed Configuration Management Systems are ones where there does not have to be a central repository. Each developer has a copy of the entire repository and history. A central repository may be optionally used, but it is equal to all of the other developer repositories. Advantages of Distributed Configuration Management Distributed tools are faster than centralized ones since metadata is stored locally. Can use tool to manage changes locally while not connected to the network where server resides. Scales more easily, since all of the load is not on a central server. Allows private work that is controlled, but not released to the larger community. Distributed systems are normally designed to make merges easy, since they are done more often. Mercurial Introduction Mercurial is a cross-platform, distributed configuration management application. In runs on most modern OS platforms, including Windows, Linux, Solaris, FreeBSD, and Mac OSX. Mercurial is written 95% in Python, with the remainder written in C for speed. Mercurial is available as a command line tool on all of the platforms, and with GUI support programs on many of the platforms. Mercurial is customizable with extensions, hooks, and output templates.
  • Higher Inductive Types (Hits) Are a New Type Former!

    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
  • Analysis of Devops Tools to Predict an Optimized Pipeline by Adding Weightage for Parameters

    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].
  • Version Control – Agile Workflow with Git/Github

    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,
  • Revision Control

    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 .
  • FAKULTÄT FÜR INFORMATIK Leveraging Traceability Between Code and Tasks for Code Reviews and Release Management

    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.
  • Distributed Revision Control with Mercurial

    Distributed Revision Control with Mercurial

    Distributed revision control with Mercurial Bryan O’Sullivan Copyright c 2006, 2007 Bryan O’Sullivan. This material may be distributed only subject to the terms and conditions set forth in version 1.0 of the Open Publication License. Please refer to Appendix D for the license text. This book was prepared from rev 028543f67bea, dated 2008-08-20 15:27 -0700, using rev a58a611c320f of Mercurial. Contents Contents i Preface 2 0.1 This book is a work in progress ...................................... 2 0.2 About the examples in this book ..................................... 2 0.3 Colophon—this book is Free ....................................... 2 1 Introduction 3 1.1 About revision control .......................................... 3 1.1.1 Why use revision control? .................................... 3 1.1.2 The many names of revision control ............................... 4 1.2 A short history of revision control .................................... 4 1.3 Trends in revision control ......................................... 5 1.4 A few of the advantages of distributed revision control ......................... 5 1.4.1 Advantages for open source projects ............................... 6 1.4.2 Advantages for commercial projects ............................... 6 1.5 Why choose Mercurial? .......................................... 7 1.6 Mercurial compared with other tools ................................... 7 1.6.1 Subversion ............................................ 7 1.6.2 Git ................................................ 8 1.6.3
  • DVCS Or a New Way to Use Version Control Systems for Freebsd

    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..
  • New York Software Symposium New York Information Technology Center June 24 - 25, 2011

    New York Software Symposium New York Information Technology Center June 24 - 25, 2011

    New York Software Symposium New York Information Technology Center June 24 - 25, 2011 Fri, Jun. 24, 2011 Room 2 Room 3 Room 4 Room 5 Room 6 8:00 - 9:00 AM REGISTRATION/BREAKFAST/WELCOME 9:00 - 10:30 AM Slimmed Down Software: Busy Java Developer&apos;s Sonar: Code Quality Programming HTML5 Concurrency without A Lean Approach Guide to Java 7 Metrics Made Easy Tim Berglund pain in pure Java Hamlet D`Arcy Ted Neward Matthew McCullough Venkat Subramaniam 10:30 - 11:00 AM BREAK 11:00 - 12:30 PM New Ideas for Old Code Busy Java Developer&apos;s Open Source Debugging NoSQL Smackdown! Collections for Concurrency Hamlet D`Arcy Guide to Games Tools for Java Tim Berglund Venkat Subramaniam Ted Neward Matthew McCullough 12:30 - 2:30 PM LUNCH & KEYNOTE 2:30 - 4:00 PM Pragmatic Architecture Java Boilerplate Busters Cascading through Hadoop: A Getting Started with Grails Programming in Functional Style Ted Neward Hamlet D`Arcy DSL for Simpler MapReduce Tim Berglund Venkat Subramaniam Matthew McCullough 4:00 - 4:30 PM BREAK 4:30 - 6:00 PM How to Select and Architectural Kata Workshop Resource-Oriented Cassandra: Radical Scala for the Intrigued Adopt a Technology Ted Neward Architectures : REST I NoSQL Scalability Venkat Subramaniam Peter Bell Brian Sletten Tim Berglund New York Software Symposium New York Information Technology Center June 24 - 25, 2011 Sat, Jun. 25, 2011 Room 2 Room 3 Room 4 Room 5 Room 6 8:00 - 9:00 AM BREAKFAST 9:00 - 10:30 AM Cryptography on the Resource-Oriented Integrating JVM Languages Complexity Theory and Busy Java Developer&apos;s
  • Git Basics Git Expertise

    Git Basics Git Expertise

    Overview Git basics Git expertise Git A GNU Alternative to Bitkeeper Mohamed Barakat University of Kaiserslautern ITWM Kaiserslautern, January 2010 Mohamed Barakat Git Overview Git basics Git expertise 1 Git basics The Git configuration file Create a Git-repository Using a Git-repository 2 Git expertise Branching Pulling Merging and Cherry-Picking Mohamed Barakat Git Overview The Git configuration file Git basics Create a Git-repository Git expertise Using a Git-repository Overview 1 Git basics The Git configuration file Create a Git-repository Using a Git-repository 2 Git expertise Branching Pulling Merging and Cherry-Picking Mohamed Barakat Git Overview The Git configuration file Git basics Create a Git-repository Git expertise Using a Git-repository Git working copy and Git-repsoitory Git is a distributed SCM Git is a distributed Source Code Management system (SCM), i.e. each Git working copy sits on top of its own local Git repository located in a single top-level subdirectory .git. SVN is in contrast to Git a centralized SCM system, i.e. the SVN-repository is on exactly one server. Git allows you to commit, checkout, reset, etc. without contacting a server! Mohamed Barakat Git Overview The Git configuration file Git basics Create a Git-repository Git expertise Using a Git-repository The configuration file ˜/.gitconfig Create a Git configuration file vi ˜/.gitconfig [svn] authorsfile = .git/info/svn-authors [color] diff = auto status = auto branch = auto [user] name = Firstname Lastname email = [email protected] Mohamed Barakat Git Overview The Git configuration file Git basics Create a Git-repository Git expertise Using a Git-repository Create a Git-repository (quick version) init, add, commit Create a Git-repository in the directory XY: 1 cd XY 2 git init 3 git add .
  • GIT—A Stupid Content Tracker

    GIT—A Stupid Content Tracker

    GIT—A Stupid Content Tracker Junio C. Hamano Twin Sun, Inc. [email protected] Abstract The paper gives an overview of how git evolved and discusses the strengths and weaknesses of its design. Git was hurriedly hacked together by Linus Torvalds, after the Linux kernel project lost its license to use BitKeeper as its source code management system (SCM). It has since 1 Low level design quickly grown to become capable of managing the Linux kernel project source code. Other projects have started to replace their existing Git is a “stupid content tracker.” It is designed SCMs with it. to record and compare the whole tree states ef- ficiently. Unlike traditional source code control Among interesting things that it does are: systems, its data structures are not geared to- ward recording changes between revisions, but for making it efficient to retrieve the state of in- 1. giving a quick whole-tree diff, dividual revisions. 2. quick, simple, stupid-but-safe merge, The unit in git storage is an object. It records: 3. facilitating e-mail based patch exchange workflow, and • blob – the contents of a file (either the 4. helping to pin-point the change that caused contents of a regular file, or the path a particular bug by a bisection search in pointed at by a symbolic link). the development history. • tree – the contents of a directory, by recording the mapping from names to ob- The core git functionality is implemented as a jects (either a blob object or a tree object set of programs to allow higher-layer systems that represents a subdirectory).