Branching, Switching and tagging Francesco Furfari CNR-ISTI Italy.

Slides:

Advertisements

Similar presentations

Week 2 DUE This Week: Safety Form and Model Release DUE Next Week: Project Timelines and Website Notebooks Lab Access SharePoint Usage Subversion Software.

Advertisements

1 IST 410/420 Software Version Control 2 DevelopmentIntegration Test System Test User Acceptance Testing ProductionArchive DEVELOPMENTUSERS - Developers.

Configuration Management

Official; Crown Copyright 2014; Released under OGL XML Schema Maintenance Debbie Wilson, Peter Parslow Geographic Information Architects May 2014.

OSLC PLM Workgroup1 Towards detailed use cases and alignment to OSLC V0.2 Gray Bachelor 19 th July 2011.

Software Configuration Management Donna Albino LIS489, December 3, 2014.

Version Control What it is and why you want it. What is Version Control? A system that manages changes to documents, files, or any other stored information.

Source Control in MATLAB A tool for tracking changes in software development projects. Stuart Nelis & Rachel Sheldon.

VisIt Software Engineering Infrastructure and Release Process LLNL-PRES Lawrence Livermore National Laboratory, P. O. Box 808, Livermore,

Software Configuration Management Slides derived from Dr. Sara Stoecklin’s notes and various web sources.

TrunkBranch V Tracking Inventory POS Tracking Tracking Tracking Inventory Inventory POS V

Chapter 25 – Configuration Management 1Chapter 25 Configuration management.

Source Code Revision Control Software CVS and Subversion (svn)

Version control Using Git 1Version control, using Git.

Version Control with Subversion. What is Version Control Good For? Maintaining project/file history - so you don’t have to worry about it Managing collaboration.

Craig Berntson Chief Software Gardener Mojo Software Worx Branches and Merges are Bears, Oh My!

Subversion. What is Subversion? A Version Control System A successor to CVS and SourceSafe Essentially gives you a tracked, shared file system.

Software Engineering Modern Approaches

Software Configuration Management (SCM)

The Design Workshop Introduction to Version Control 1.

Version Control with Subversion Quick Reference of Subversion.

1 Lecture 19 Configuration Management Software Engineering.

Copyright © Software Carpentry 2012 This work is licensed under the Creative Commons Attribution License See

OpenDayLight – “autorelease” tool and process Jun 2014 Giovanni Meo 1.

Branching. Version Control - Branching A way to write code without affecting the rest of your team Merge branches to integrate your changes.

Configuration Management Geant4 Review 19 June 2001 Gunter Folger.

Page 1 Trilinos Release Improvement Issues Roscoe A. Bartlett Department of Optimization & Uncertainty Estimation Trilinos.

Cloudifying Source Code Repositories: How much does it cost? 1 Hadi Salimi, Distributed Systems Labaratory, School of Computer Engineering, Iran University.

Object-Oriented Analysis & Design Subversion. Contents  Configuration management  The repository  Versioning  Tags  Branches  Subversion 2.

Microsoft ® Business Solutions–Navision ® 4.0 Development II - C/SIDE Solution Development Day 5.

CS5103 Software Engineering Lecture 11 Versioning and Issue Tracking.

Progress with migration to SVN Part3: How to work with g4svn and geant4tags tools. Geant4.

1 Software Configuration Management (SCM) and Software Reuse Presented By: Edmund Leng (HT052446J) Choo Zhi Min (HT052430X)

QUALITY ASSURANCE PRACTICES. Quality Plan Prepared and approved at the beginning of project Soft filing system approach followed. Filing location – –

Version Control with SVN Images from TortoiseSVN documentation

EGEE-III INFSO-RI Enabling Grids for E-sciencE EGEE and gLite are registered trademarks Stephen Childs Trinity College Dublin &

Version Control Reducing risk with version control Jon Austin

Source Control Saves Lives. Lorna Mitchell Source Control Saves Lives BarCamp Leeds What is Source Control? Central filestore Change history Audit trail.

Team Foundation Server 2010 Introductory presentation.

Software Reuse Course: # The Johns-Hopkins University Montgomery County Campus Fall 2000 Lecture # 2 - September 14, 2004.

ASUG SAP Adoption Influence Council The focus is on how to increase awareness, adoption and implementation of SAP enhancements that are delivered as part.

© 2007 by Michal Dobisek; made available under the EPL v1.0 | EclipseCon 2007 Michal Dobisek, Inside Subversive The Subversion.

(1) Introduction to Subversion (SVN) and Google Project Hosting Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences.

(1) Introduction to Subversion (SVN) and Google Project Hosting Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences.

Source Control Repositories for Enabling Team Working Doncho Minkov Telerik Corporation

CS520 Web Programming Version Control with Subversion Chengyu Sun California State University, Los Angeles.

1 Subversion Kate Hedstrom April Version Control Software System for managing source files –For groups of people working on the same code –When.

CS491A Software Design Lab Version Control with CVS and Subversion Chengyu Sun California State University, Los Angeles.

Version Control How and why to control changes in a software artifact.

Software Configuration Management -Subversion- RTLAB YuJin Park.

Managing Software in Higher Education

Configuration Management

Configuration Management

SVN intro (review).

Version Control with Subversion (SVN)

Version control, using Git

Configuration Management

Branching Strategy.

Methodical Accelerator Design

DDEC Reports 8.02 New Features and Improvements

Francesco Giacomini – INFN JRA1 All-Hands Nikhef, February 2008

Version Control System

Software Quality Assurance

Concurrent Version System (CVS)

Dynamic Process for Source Control

Version Control CS169 Lecture 7 Prof. Aiken CS 169 Lecture 7 1.

Users Developers Committers Bug & Feature List CVS Checkout Latest

Overview Activities from additional UP disciplines are needed to bring a system into being Implementation Testing Deployment Configuration and change management.

Branches And Releases Branch for Urgent Bug Branch for Feature A

Presentation transcript:

Branching, Switching and tagging Francesco Furfari CNR-ISTI Italy

Trunk/c1 Trunk/c2 Sandbox/D1 V1.0.0 Tag/c1-V1.0.0 V1.0.1V1.0.2 C1-V1.0.2C1-V1.2.0 V1.2.0 C1-V1.2.0 Validation C1-V1.2.0 validated Branch Merge Tag/c1-V1.2.0 Released &Tagged V1.2.1 Tagged Sandbox Usage 1 for major and minor changes

Svn:Trunk/c1 Svn:Trunk/c2 V1.0.1V1.0.2V1.2.0 validated Update Artifact version to validated Update Artifact version to Branch V1.2.1 Merge Developers Local View D1 & D2 (Validator) D1 -- local:trunk/c1 Artefact version unchanged, always aligned to the trunk V1.0.2 Artefact version unchanged, always aligned to the trunk V1.0.2 V1.0.1V1.0.2 V1.2.0 C1-V1.2.0 Validation Switch and test C1-V1.2.0 Validation Switch and test D2 -- local:trunk/c1 V1.0.2 V1.2.0 Svn:Sandbox/D1 C1-V1.0.2C1-V1.2.0 commits Switchcommit Switch

Svn: Trunk/c1 Svn:Trunk/c2 Svn:Sandbox/D1 V1.0.0V1.0.1V1.0.2 C1-V1.0.2C1-V1.2.0 V1.2.0 C1-V1.2.0 Validation C1-V1.2.0 validated Branch Merge Tag/c1-V1.2.0 V1.2.1 Tagged Sandbox usage 1.a Artefact development shared among several developers D2 -- local:trunk/c1 V1.0.3V1.0.4 V1.0.3V1.0.4 Merge Commit

Trunk/c1 Trunk/c2 Svn: Sandbox/D1 V1.0.0 Tag/c1-V1.0.0 V1.0.1V1.0.2 C1-V1.0.0-bug-123 V1.2.0 Released &Tagged V1.2.1 Commit Sandbox Usage 2 for bug fixing of released software D1 -- local:trunk/c1 V1.2.1 Switch V1.2.1 C1-V1.0.0 bug fixed C1-V1.0.0 validated C1-V1.0.0-bug-123 Tag/c1-V1.0.0-patch-123 Release Patch &Tag C1-V1.2.0 evaluate & apply Merge or Porting Switch Branch

Trunk/c1 Svn: Sandbox/D1 V1.0.2 C1-V1.2.1-patch-456 V1.2.0V1.2.1 Commit Sandbox Usage 3 applying external patches D1 -- local:trunk/c1 Branch V1.2.1 Apply patch-456 validate C1-V1.2.1-patch-456 MergeSwitch V1.2.1 Switch V1.2.2 V1.2.1

Validate Multi-component changes Svn:Trunk/c1 Svn:Trunk/c2 V1.0.1 V3.0.2 Svn:Branches/NewFeature/c1 Svn:Branches/NewFeature/c2 V1.0.1 V3.0.2 V2.0.0 V3.3.0V3.4.0 Branch V2.0.0 V3.4.0 V1.1.0V1.2.1V1.2.2V2.0.0 Replace V3.4.0 Merge

Development options Each artefact (bundle) should have one developer – Changes to artefact are accepted and delegated from the main developer (responsible) Complex artefacts may have several developers who appoint a coordinator (leader) – Changes must be coordinated in the group and notified (automatically) Changes/bug fixes provided by a developers external to the bundle development should be tracked and applied as patches from the developers coordinating the bundle development. Changes and release of multiple artefacts should be coordinated and developed in new branches that are merged when the code is ready and validated. Sandboxes should be intensively used for each activity that requires testing of the code from third developers Alternative implementation of the same artefact should be developed in the sandbox, validated and moved to the trunk with a different name.