Software Best Practices

Total Page:16

File Type:pdf, Size:1020Kb

Software Best Practices Software Best Practices Marco Mambelli – [email protected] Engineering Week 17 February 2020 Software • Set of instructions and its associated documentations that tells a computer what to do or how to perform a task • Any manuscript/artifact/product written by you with the scope to be used by machine and humans 2 2/17/20 Marco Mambelli | Software best practices 3 2/17/20 Marco Mambelli | Software best practices Outline • General applicability, more in detail – Version control and Git – Documentation • More specific to coding – Requirements – Design • Technology selection • OS Requirements • Software inputs • Software logs, metrics and accounting – Code development – Validation and testing – Releases – Deployment – Bug tracking – Change management – Critical services operation 4 2/17/20 Marco Mambelli | Software best practices “Piled Higher and Deeper” by Jorge Cham, http://www.phdcomics.com 5 2/17/20 Marco Mambelli | Software best practices Version Control System • Preserves different version of a document • Helps merging different contributions • Answers important questions on the documents – What changed? – Who changed it? – Why? 6 2/17/20 Marco Mambelli | Software best practices Centralized vs distributed VCS 7 2/17/20 Marco Mambelli | Software best practices Common RCS • SVN (Apache Subversion) – Newer system based on CVS – Includes atomic operations – Cheaper branch operations, slower comparative speed – Does not use peer-to-peer model – Still contains bugs relating to renaming files and directories – Insufficient repository management commands • Mercurial – Easier to learn than Git (also more similar to CVS/SVN) – Distributed model – No merging of two parents – Less out of the box power, in Python, extension-based rather than scriptability • Git – Very different from CVS/SVN – Cheap branch operations, dramatic increase in operation speed – Full history tree available offline – Distributed, peer-to-peer model – Not optimal for single developers 8 2/17/20 Marco Mambelli | Software best practices Git concepts – Local repository • Snapshot with GUID (SHA1 hash) • Repository – init • Staging – add • Commit – commit (checkout) • Tag – tag 9 2/17/20 Marco Mambelli | Software best practices Git remotes – Remote repositories • Remote – clone – remote add – push – fetch (pull) Working copy Server • Define a main repository! 10 2/17/20 Marco Mambelli | Software best practices Git resources • Clients for the major platforms – Command line – GUI (Fork, GitHub desktop, GitKraken, Tower,…) • Online hosting – Bitbucket – GitLab – GitHub • Hosting at Fermilab – Git integrated with Redmine – GitLab instance 11 2/17/20 Marco Mambelli | Software best practices Do I need to put everything in GitHub? • Word processors have frequently an integrated VC – Track changes in MS Word – Version history in Google Docs – Recording and Displaying Changes in Libre Office • Not ideal for large binary files – File sharing have versioning systems • Version history in Dropbox • Versions in Box • Version History in OneDrive – Dedicated versioning apps, e.g. ForeverSave – OS X time machine and other backup solutions 12 2/17/20 Marco Mambelli | Software best practices Use Git for … • Code or text like documents* • When you need to know – What changed? – Who changed it? – Why? * Git provides LFS (Large File Storage) https://git-lfs.github.com/ 13 2/17/20 Marco Mambelli | Software best practices Centralized workflow • Single (remote) repo • Single ordered flow • Conflicts solved one at the time by the developer 14 2/17/20 Marco Mambelli | Software best practices Feature branching workflow • Single (remote) repo • Leverage branches: • master (releases) • Development • Features • Hotfixes • Easier to enforce https://nvie.com/posts/a-successful-git-branching-model/ policies 15 2/17/20 Marco Mambelli | Software best practices Fork and branch workflow R1 R2 • Multiple forked repos • Leverage branches • Feature branches in forked repos • Squash R1 • Rebase • Pull requests R2 • Even easier to enforce policies • Restricted access 16 2/17/20 Marco Mambelli | Software best practices Final Git recommendations • Write meaningful commit messages – First line is the summary – Enough detail to understand the changes • Access to the repository based on software purpose – Least Privilege approach – Consider signing commits https://help.github.com/en/articles/signing-commits • Public software should have a license – LICENSE (text file in the root of the repository) – BSD 3-clause, Apache 2.0 – At Fermilab you can get help in picking and reviewing a license • Contact Aaron Sauers • https://cdcvs.fnal.gov/redmine/projects/scd-cst/wiki/Software_licensing • A DOI, Digital Object Identifier, can facilitate citations – https://about.zenodo.org/ 17 2/17/20 Marco Mambelli | Software best practices What should never go in Git? • PASSWORDS! • Any credential: SSH keys, certificates, … • Privale or PII – IP addresses – Names, birth dates, SSN … 18 2/17/20 Marco Mambelli | Software best practices Documentation • Target audience – Developers (including your future self) – Users (operators/end users) • Just a README (README.md) • Common documents in a complex project – Requirement documentation – Design documentation – SQA/Test documentation – Installation and operation documentation – User manual – API specs 19 2/17/20 Marco Mambelli | Software best practices Documentation resources • For software or to share information • Fermilab supports – Microsoft SharePoint – WordPress – Custom website on Apache (HTML, CSS, includes) – DocDb • GitHub Pages – https://pages.github.com/ – Markdown 20 2/17/20 Marco Mambelli | Software best practices Outline • Version control and Git • Documentation • Requirements • Design – Technology selection – OS Requirements – Software inputs – Software logs, metrics and accounting • Code development • Validation and testing • Releases • Deployment • Bug tracking • Change management • Critical services operation 21 2/17/20 Marco Mambelli | Software best practices Planning and Requirements • Introduction – Purpose – Scope – Rationale – Terminology • Overview • Plan in advance • Requirements – Actors • Write requirements – The Major Inputs and Output – Behavioral requirements (use cases) – Constraints – Actors • Architectural Overview – Roles – The Major Inputs and Output – Functional unit or Component block diagram – Physical unit block diagram – Behavioral requirements (use – Deployment scenario • Component Interfaces cases) • Protocols • Discussion – Decisions and Choices – Constraints – Rationale – Implications resulting from Choices • Example document – Resulting rules – Constraints imposed on other systems – Outline • Testing considerations – Link: https://drive.google.com/file/d/1Lk7ku0GcqZ5IJFO3pTEIM_R0DmG0aHvG/view?usp=sharing 22 2/17/20 Marco Mambelli | Software best practices Technology selection • Is it there a product providing a similar functionality? • Or a component needed? • If yes – How well is adopted? – Open Source? – With active community support? – Accepts feature requests/contributions? 23 2/17/20 Marco Mambelli | Software best practices Technology selection: more questions • Performance and scalability requirements • Current and future platform requirements • Long term costs – Licensing and support fees – In-house support • Industry trends (be aware but independent) • Strength and weaknesses of the developers in the project • Team consensus on the technology 24 2/17/20 Marco Mambelli | Software best practices OS requirements • These are good practices in general and requirements at Fermilab • Recent and supported versions of Operating System – Lab configurations management practices https://cd-docdb.fnal.gov/cgi-bin/sso/RetrieveFile?docid=4264&filename=ConfigMgmt.pdf&version=3 – Listed baseline configurations https://fermipoint.fnal.gov/org/cs/pages/computer-security-documents---general-computing-environment.aspx • Rare and well documented exceptions – ServiceNow request https://cd-docdb.fnal.gov/cgi-bin/sso/RetrieveFile?docid=4141&filename=Variance-Request-process-rc.docx&version=2 https://fermi.service-now.com/navpage.do 25 2/17/20 Marco Mambelli | Software best practices Software inputs (configuration) • Avoid hardcoded inputs! • Evaluate all inputs – How frequently does it change (install, all invocations, …)? – Who is providing it (expert, trusted, person…)? • Possible input mechanisms – Configuration files – Command line (options and arguments) – Environment variables – Interactive inputs (GUI, prompt, …) 26 2/17/20 Marco Mambelli | Software best practices Software logs and metrics Monitoring, accounting, troubleshooting and debugging • Have a consistent structure • Readable for humans • Structured for machine parsing • Configurable severity levels • Distinguish between debug/info/warning/error/fatal messages • Use an existing library (log4j, python logging, …) • Well structured tags • Independent control for logging of different components 27 2/17/20 Marco Mambelli | Software best practices Log levels TRACE • finer-grained informational events than the DEBUG • fine-grained informational events that are most useful to debug an application • informational messages that highlight the progress of the application at coarse-grained level • potentially harmful situations • error events that might still allow the application to continue running • very severe error events that will presumably lead the application to abort. 28 2/17/20 Marco Mambelli | Software best practices Software development (coding) • Provide clear coding guidelines – PEP8,
Recommended publications
  • Pragmatic Version Control Using Subversion
    What readers are saying about Pragmatic Version Control using Subversion I expected a lot, but you surprised me with even more. Hav- ing used CVS for years I hesitated to try Subversion until now, although I knew it would solve many of the shortcom- ings of CVS. After reading your book, my excuses to stay with CVS disappeared. Oh, and coming from the Pragmatic Bookshelf this book is fun to read too. Thanks Mike. Steffen Gemkow Managing Director, ObjectFab GmbH I’m a long-time user of CVS and I’ve been skeptical of Sub- version, wondering if it would ever be “ready for prime time.” Until now. Thanks to Mike Mason for writing a clear, con- cise, gentle introduction to this new tool. After reading this book, I’m actually excited about the possibilities for version control that Subversion brings to the table. David Rupp Senior Software Engineer, Great-West Life & Annuity This was exactly the Subversion book I was waiting for. As a long-time Perforce and CVS user and administrator, and in my role as an agile tools coach, I wanted a compact book that told me just what I needed to know. This is it. Within a couple of hours I was up and running against remote Subversion servers, and setting up my own local servers too. Mike uses a lot of command-line examples to guide the reader, and as a Windows user I was worried at first. My fears were unfounded though—Mike’s examples were so clear that I think I’ll stick to using the command line from now on! I thoroughly recommend this book to anyone getting started using or administering Subversion.
    [Show full text]
  • IPS Signature Release Note V9.17.79
    SOPHOS IPS Signature Update Release Notes Version : 9.17.79 Release Date : 19th January 2020 IPS Signature Update Release Information Upgrade Applicable on IPS Signature Release Version 9.17.78 CR250i, CR300i, CR500i-4P, CR500i-6P, CR500i-8P, CR500ia, CR500ia-RP, CR500ia1F, CR500ia10F, CR750ia, CR750ia1F, CR750ia10F, CR1000i-11P, CR1000i-12P, CR1000ia, CR1000ia10F, CR1500i-11P, CR1500i-12P, CR1500ia, CR1500ia10F Sophos Appliance Models CR25iNG, CR25iNG-6P, CR35iNG, CR50iNG, CR100iNG, CR200iNG/XP, CR300iNG/XP, CR500iNG- XP, CR750iNG-XP, CR2500iNG, CR25wiNG, CR25wiNG-6P, CR35wiNG, CRiV1C, CRiV2C, CRiV4C, CRiV8C, CRiV12C, XG85 to XG450, SG105 to SG650 Upgrade Information Upgrade type: Automatic Compatibility Annotations: None Introduction The Release Note document for IPS Signature Database Version 9.17.79 includes support for the new signatures. The following sections describe the release in detail. New IPS Signatures The Sophos Intrusion Prevention System shields the network from known attacks by matching the network traffic against the signatures in the IPS Signature Database. These signatures are developed to significantly increase detection performance and reduce the false alarms. Report false positives at [email protected], along with the application details. January 2020 Page 2 of 245 IPS Signature Update This IPS Release includes Two Thousand, Seven Hundred and Sixty Two(2762) signatures to address One Thousand, Nine Hundred and Thirty Eight(1938) vulnerabilities. New signatures are added for the following vulnerabilities: Name CVE–ID
    [Show full text]
  • Trabajo De Fin De Carrera
    TRABAJO DE FIN DE CARRERA TÍTULO DEL TFC: VirtualEPSC, el mundo virtual 2.0 del Campus del Baix Llobregat TITULACIÓN: Ingeniería Técnica de Telecomunicación, especialidad en Telemática AUTORES: Luis Miguel Amorós Martínez Noemí Arbós Linio DIRECTOR: Toni Oller Arcas FECHA: 14 de julio de 2010 Título: VirtualEPSC, el mundo virtual 2.0 del Campus del Baix Llobregat Autores: Luis Miguel Amorós Martínez Noemí Arbós Linio Director: Toni Oller Arcas Fecha: 14 de julio de 2010 Resumen En las últimas décadas, se han producido cambios tecnológicos de gran envergadura que han provocado una ruptura brusca con las tecnologías existentes hasta el momento. Una de las más importantes es Internet, que se ha convertido en el entorno de comunicación más importante de la historia, con más de mil millones de usuarios en todo el mundo. Internet ha sufrido una serie de cambios en los últimos años y uno de los últimos conceptos que han surgido es el de web 2.0. Esta filosofía se basa en dar un rol más activo a los usuarios, por ejemplo, utilizando la colaboración de los usuarios en Internet, también llamado inteligencia colectiva; y en el diseño centrado en el usuario. Este trabajo describe los pasos seguidos para desarrollar una web 2.0 que aloja un mundo virtual que emula el Campus del Baix Llobregat. Se describe cómo son el diseño y la arquitectura del proyecto, y cómo se ha hecho la implementación de las diferentes partes. El resultado se denomina VirtualEPSC, una web 2.0 que aloja una aplicación multimedia en 2D que emula el Campus del Baix Llobregat, donde los usuarios podrán interactuar entre ellos.
    [Show full text]
  • Inequalities in Open Source Software Development: Analysis of Contributor’S Commits in Apache Software Foundation Projects
    RESEARCH ARTICLE Inequalities in Open Source Software Development: Analysis of Contributor’s Commits in Apache Software Foundation Projects Tadeusz Chełkowski1☯, Peter Gloor2☯*, Dariusz Jemielniak3☯ 1 Kozminski University, Warsaw, Poland, 2 Massachusetts Institute of Technology, Center for Cognitive Intelligence, Cambridge, Massachusetts, United States of America, 3 Kozminski University, New Research on Digital Societies (NeRDS) group, Warsaw, Poland ☯ These authors contributed equally to this work. * [email protected] a11111 Abstract While researchers are becoming increasingly interested in studying OSS phenomenon, there is still a small number of studies analyzing larger samples of projects investigating the structure of activities among OSS developers. The significant amount of information that OPEN ACCESS has been gathered in the publicly available open-source software repositories and mailing- list archives offers an opportunity to analyze projects structures and participant involve- Citation: Chełkowski T, Gloor P, Jemielniak D (2016) Inequalities in Open Source Software Development: ment. In this article, using on commits data from 263 Apache projects repositories (nearly Analysis of Contributor’s Commits in Apache all), we show that although OSS development is often described as collaborative, but it in Software Foundation Projects. PLoS ONE 11(4): fact predominantly relies on radically solitary input and individual, non-collaborative contri- e0152976. doi:10.1371/journal.pone.0152976 butions. We also show, in the first published study of this magnitude, that the engagement Editor: Christophe Antoniewski, CNRS UMR7622 & of contributors is based on a power-law distribution. University Paris 6 Pierre-et-Marie-Curie, FRANCE Received: December 15, 2015 Accepted: March 22, 2016 Published: April 20, 2016 Copyright: © 2016 Chełkowski et al.
    [Show full text]
  • Collaboration Tools in Software Engineering Stepan Bolotnikov Me
    Collaboration Tools in Software Engineering Stepan Bolotnikov Me ● Stepan Bolotnikov ● Software Engineer at Guardtime ● MSc in Software Engineering from UT, 2018 ● [email protected] You Mostly BSc students in Computer Science ● Software developers / QA engineers ● CS researchers ● Project managers / team leads In any case connected to software projects, sharing knowledge and resources Course ● History and working principles of version control systems (VCS) ● Git distributed VCS ● Issue tracking ● Theoretical knowledge + practical hands-on exercises ● 8 sessions ● Every 2nd Friday ● Lecture + practice ● Non-differentiated (pass/fail) Schedule ● 22. Feb - Introduction, history of VCS ● 08. Mar - Introduction to Git, setting up the first repository, basic Git usage ● 22. Mar - Common Git commands ● 05. Apr - Branching in Git, common branching models ● 19. Apr - Troubleshooting common Git issues ● 03. May - Github; Issue tracking ● 17. May - Advanced Git usage; git hooks and CI ● 31. May - Guest lecture, preparation for exam ● 07. June - Exam 1 ● 14. June - Exam 2 Sessions ● 4h ● Lecture part ● Practical part Final exam ● 7th or 17th June ● Individual practical tasks ● “Poor”, “Satisfactory” or “Good” ● “Satisfactory” and “Good” - passing In order to pass the course ● Active participation in at least 6 out of 8 sessions ○ Complete the practical tasks ● “Satisfactory” or “Good” on the final exam Communication Course website http://courses.cs.ut.ee/2019/cse Course Slack Click Lecture 1: Introduction to course, History of Version
    [Show full text]
  • CPS Release Notes
    Release Notes for Cisco Policy Suite for Release 7.0 First Published: September 26, 2014 Last Updated: July 10, 2015 Release: 7.0 Contents This document describes the new features, feature versions and limitations for the Cisco Policy Suite software. Use this document in combination with documents listed in the “Related Documentation” section on page 33. This document includes the following sections: • Introduction, page 1 • New and Changed Information, page 2 • Installation Notes, page 9 • Limitations and Restrictions, page 15 • Caveats, page 23 • Related Documentation, page 33 Introduction The Cisco Policy Suite is a comprehensive policy, charging, and subscriber data management solution that allows service providers to control and monetize their networks and to profit from personalized services. The Cisco Policy Suite has the following components: • Policy Server (PS) • Charging Server (CS) • Application Gateway (AGW) Cisco Systems, Inc. www.cisco.com New and Changed Information • Unified Subscriber Manager (USuM) • Subscriber Analytics The Cisco Policy Suite provides an intelligent control plane solution, including southbound interfaces to various policy control enforcement functions (PCEFs) in the network, and northbound interfaces to OSS/BSS and subscriber applications, IMSs, and web applications. The Cisco Policy Suite modules are enabled individually or deployed as an integrated end-to-end policy, charging, and service creation solution. Competitive Benefits The new Cisco Policy Suite solution provides these benefits over competitive solutions. • Cisco Policy Suite architecture allows simultaneous sessions and transactions per second (TPS) capacity to be independently scaled. This allows Cisco Policy Suite to be efficiently sized for both high simultaneous sessions with low TPS or low sessions with high TPS, resulting in lower total cost of ownership when compared to traditional PCRF models.
    [Show full text]
  • Design Options of Store-Oriented Software Ecosystems: an Investigation of Business Decisions ∗
    Design Options of Store-Oriented Software Ecosystems: An Investigation of Business Decisions ∗ Bahar Jazayeri1, Olaf Zimmermann2, Gregor Engels1, Jochen K¨uster3, Dennis Kundisch1, Daniel Szopinski1 1 Paderborn University, Germany fbahar.jazayeri,gregor.engels,dennis.kundisch,[email protected] 2 University of Applied Sciences of Eastern Switzerland, Switzerland [email protected] 3 Bielefeld University of Applied Sciences, Germany [email protected] Abstract. Nowadays companies like Apple create ecosystems of third- party providers and users around their software platforms. Often online stores like Apple App Store are created to directly market third-party solutions. We call such ecosystems store-oriented software ecosystems. While the architecture of these ecosystems is mainly derived from busi- ness decisions of their owners, ecosystems with greatly different archi- tectural designs have been created. This diversity makes it challenging for future ecosystem providers to understand which architectural design is suitable to fulfill certain business decisions. In turn, opening a plat- form becomes risky while endangering intellectual property or scarifying quality of services. In this paper, we identify three main design options of store-oriented software ecosystems by classifying existing ecosystems based on similarities in their business decisions. We elaborate on the design options, discuss their main contributions, and provide exemplary ecosystems. Our work provides aspiring ecosystem providers with the reusable knowledge of existing ecosystems and helps them to take more informed architectural decisions and reduce risks in future. Keywords: Software ecosystems, Reusable designs, Variabilities 1 Introduction Software ecosystems have become an emerging architectural approach for many companies to grow. The term software ecosystem is inspired from ecological ecosystems that are the result of an interplay between organisms as well as interactions with a physical environment [1].
    [Show full text]
  • Syncro SVN Client 8.1
    Syncro SVN Client 8.1 Notice Copyright All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the written permission of the publisher. While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused directly or indirectly by this document. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and SyncRO Soft SRL, was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. Syncro SVN Client | Contents | 5 Contents Chapter 1: Introduction..........................................................................................11 Chapter 2: Installation............................................................................................13 Installation
    [Show full text]
  • Welcome-To-Reqtify-2016-FD01.Pdf
    Welcome to Reqtify 2016 FD01 Reqtify 2016 FD01 is a new major release of Reqtify product line containing new features, new interfaces and minor enhancements, interface updates, and fixes. Reqtify is an interactive requirement traceability and impact analysis tool which can trace requirements from system, program and project levels to the entire levels of your software or hardware component development lifecycle. Reqtify can interface with requirement-related information in a wide variety of data formats, document types and file formats. These can include corporate requirement repositories such as IBM-Rational DOORS™ and RequisitePro™, Borland CaliberRM™, 3SL Cradle™, office type documents such as Microsoft Word, Excel, Adobe FrameMaker and PDF, UML Design tools such as ARTiSAN Studio, Enterprise Architect, CAD tools such as Simulink, Code files such as C, Ada, C++, Java or VHDL as well as information in standard text format, HTML, XML, or ReqIF. This document is for information and instruction purposes and is reserving the right to make changes in specifications and other information contained in this publication without prior notice, and the reader should, in all cases, consult Dassault Systèmes to determine whether any changes have been made. The terms and conditions governing the sale and licensing of products are set forth in a separate written agreements. No representation or other affirmation of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Dassault Systèmes and its affiliates whatsoever. DASSAULT SYSTÈMES AND ITS AFFILIATES MAKE NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
    [Show full text]
  • Version Control) Installation and Configuration Guide Version 8.0 and Higher
    Source Management (Version Control) Installation and Configuration Guide Version 8.0 and Higher July 05, 2018 Active Technologies, EDA, EDA/SQL, FIDEL, FOCUS, Information Builders, the Information Builders logo, iWay, iWay Software, Parlay, PC/FOCUS, RStat, Table Talk, Web390, WebFOCUS, WebFOCUS Active Technologies, and WebFOCUS Magnify are registered trademarks, and DataMigrator and Hyperstage are trademarks of Information Builders, Inc. Adobe, the Adobe logo, Acrobat, Adobe Reader, Flash, Adobe Flash Builder, Flex, and PostScript are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. Due to the nature of this material, this document refers to numerous hardware and software products by their trademarks. In most, if not all cases, these designations are claimed as trademarks or registered trademarks by their respective companies. It is not this publisher's intent to use any of these names generically. The reader is therefore cautioned to investigate all claimed trademark rights before using any of these names other than to refer to the product described. Copyright © 2018, by Information Builders, Inc. and iWay Software. All rights reserved. Patent Pending. This manual, or parts thereof, may not be reproduced in any form without the written permission of Information Builders, Inc. Contents Preface ......................................................................... 5 Documentation Conventions ............................................................5 Related Publications
    [Show full text]
  • Flare Source Control Guide: Apache Subversion
    USER GUIDE MADCAP FLARE 2021 Source Control: Subversion Copyright 2021 MadCap Software. All rights reserved. Information in this document is subject to change without notice. The software described in this document is furnished under a license agreement or nondisclosure agreement. The software may be used or copied only in accordance with the terms of those agreements. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or any means electronic or mechanical, including photocopying and recording for any purpose other than the purchaser's personal use without the written permission of MadCap Software. MadCap Software 9191 Towne Center Drive, Suite 150 San Diego, California 92122 858-320-0387 www.madcapsoftware.com THIS PDF WAS CREATED USING MADCAP FLARE. CONTENTS CHAPTER 1 Introduction 5 CHAPTER 2 General Information for Subversion 6 Common Source Control Terms 7 Source Control Icons 8 CHAPTER 3 Process for Subversion 10 Binding a Project to Subversion 11 Importing From Source Control 15 Updating Source Control Files 16 Committing Source Control Files 19 Adding Files to Source Control 23 Merging Source Control Files 26 CHAPTER 4 Other Activities for Subversion 35 Deleting Source Control Files 36 Disabling the Get Latest Prompt for Source Control 37 Disconnecting From Source Control 38 CONTENTS iii Enabling Source Control Status Checks 40 Locking a File 41 Modifying Network Settings 43 Publishing to Source Control 46 Reverting Modified Source Control Files 47 Rolling Back to an Earlier Version of a File 48 Setting Color Options for Project File Differences 54 Unbinding a Project From Subversion 56 Unlocking a File 57 Viewing Differences in Source Control Files 58 Viewing the History of Source Control Files 63 Viewing Modified Files 65 APPENDIX PDFs 71 Tutorials 71 Cheat Sheets 71 User Guides 72 CONTENTS iv CHAPTER 1 Introduction You can use the Flare interface to perform various source control tasks for a project that is bound to Subversion.
    [Show full text]
  • Collabnet Subversion Edge User Guide 2 | Subversion Edge | TOC
    CollabNet Subversion Edge User Guide 2 | Subversion Edge | TOC Contents Welcome to CollabNet Subversion Edge.............................................................................7 Set up Subversion Edge .......................................................................................................8 Install Subversion Edge ...........................................................................................................................8 Install Subversion Edge on Windows...........................................................................................8 Install Subversion Edge on Linux................................................................................................9 Install Subversion Edge on Solaris.............................................................................................10 Configure the server...............................................................................................................................12 Configure general server settings...............................................................................................12 Configure advanced server settings............................................................................................13 Configure authentication settings...............................................................................................13 Configure a proxy server............................................................................................................14 Configure the mail server...........................................................................................................14
    [Show full text]