1 / 16

Version Control, Revision Control

Version Control, Revision Control. Software Configuration Management. Version Control. During software development it is inevitable To be able to recreate any earlier internally or externally released version of the software product

cassano
Télécharger la présentation

Version Control, Revision Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Version Control, Revision Control Software Configuration Management

  2. Version Control During software development it is inevitable To be able to recreate any earlier internally or externally released version of the software product Giving the possibility to turn back in case of development dead-end Control changes of software source code continuously Identify faults and problematic code parts more easily

  3. SCM • Version Control is part of Software Configuration Management (SCM), which activity keeps coherent software versions together. • Internal release: coherent software build for verification (testing) • External release: coherent software build for external, customer use • SCM usually refers more than VC, also means product component registration, 3PP related activities, may be supply activities as well. It depends on the actual project (company) setup.

  4. Traditional vs. Distributed Traditional • server oriented • clients works online or make snapshots locally Distributed • Peer to peer approach • All local machines have the whole (complete) repository • Local repos sync amongst each other • Only working copies exist (every cloned repo is a working copy) • No canonical, reference copy of the codebase exists by default; only working copies. = No special authority for any repository • Common operations (such as commits, viewing history, and reverting changes) are fast, because there is no need to communicate with a central server. • Communication is only necessary when sharing changes among other peers. • Each working copy effectively functions as a remote backup of the codebase and of its change-history, protecting against data loss. • Disadvantages • initial cloning can be terribly long • missing reserved checkout is a problem in case non-mergable binary files

  5. Traditional vs. Modern • Traditional • items (files) are version controlled and every file can be checked in separately • it does not guarantee that system is continuously coherent • Consider changes together • all modified files are checked in as one step and one identifier (generally a hash) identifies the whole system actual state • cherry-picking is possible but not a proposed way • Traditional • prevent parallel development by file locking (reserved checkout) • or by parallel development tracks and integrate at the end • Modern ones • reserved checkout is not usual • frequent merges are common and forced by the tool

  6. Version Control Implementations • (IBM Rational) Clearcase • Git • CVS, Subversion • Mercurial • Fossil • Internal • Wiki pages • Google Docs • Microsoft Office

  7. Clearcase Naming Conventions and Branching • This is a visual representation of versions of one item, “above” this, there is a file and folder view as in any normal file structure • The root is “main” branch • Versions are numbered and • Branches are named • Labels indicating releases (see next slide) • Red arrows are merges • “Config spec” tells what you see from the system

  8. Clearcase Complex Branching

  9. Branching in general (DVCS) • This is a visual representation of versions of items or the whole repo (in case of distributed systems), “under” this, there is a file and folder view as in any normal file structure • The root is usually called “trunk” • Red arrows are merges

  10. Fossil and branching • Hashes vs. incremental numbers • Fig. 1: an ideal world • Directed acyclic graphs (DAGs) but everyday usage tree is enough • “directed acyclic graph (DAG), is a directed graph with no directed cycles.” Link • Forks (fossil tries to prevent forks) • Warns to do fossil update to fetch the other already committed version • Git supports forks quite much • Fig. 2-3 • Branches • Deliberate forking for example because of two teams using different version of the SW • Fig. 4 • Merge back to “main” – dashed arrows

  11. Fossil and branching • A tag is a name that is attached to a check-in. • A property is a name/value pair. • The branch tag tells (by its value) what branch the check-in is a member of. • The default branch is called "trunk.“ • Link to read in details.

  12. Fossil and branching • Branch • A branch is a set of check-ins with the same value for their "branch" property. • Leaf • A leaf is a check-in with no children in the same branch. • Closed Leaf • A closed leaf is any leaf with the closed tag. These leaves are intended to never be extended with descendants and hence are omitted from lists of leaves in the command-line and web interface. • Open Leaf • A open leaf is a leaf that is not closed. • Fork • A fork is when a check-in has two or more direct (non-merge) children in the same branch. • Branch Point (branching out) • A branch point occurs when a check-in has two or more direct (non-merge) children in different branches. A branch point is similar to a fork, except that the children are in different branches.

  13. Concepts Concepts • Atomic operations • File locking • Version merging • Baselines, labels and tags

  14. Concepts and Branching Strategies Concepts • Store everything under version control which you want to keep • Not only source code files, but • configuration files • install scripts • documentation • released packages • Nothing to delete, add a new version • if an item is not needed remove from version control but it means you have all earlier version in repository Branching strategies in a SW Development Project • one track • one main, one development • feature branches • private branches • fossil branching Terms need to know and understand • repository • check out • reserved • unreserved • check in • merge

  15. CEA 2/EEA 15 Planned RELEASE BRANCHING New productnumber created for EEA 15 Faulty product’s R-State on this specific branch Corrected product’s R-State > < < P1A : R1A CXP 902 …/3 CXP 902 …/3 P1B : R1B . . . 2.0 ICP1 Preship 2.0 ICP1 R1B 2.0 EP1 R1A/1 2.0 PRA Final build R1A 2.0 ICP2 R1C R1A : R1B R1B : R1A CXP 902 …/2 CXP 902 …/3 < > > < . . . 15.0 Preship#1 / #2 15.0 ICP2 R2C 15.0 ICP1 R2B 15.1 ICP1 R3B 15.1 ICP2 R3C 15.0 PRA Final build R2A 15.1 PRA Final build R3A

  16. Fossil commands • new/init • clone • open • add • rm • checkout (quite different than usual, do not use at first) • changes • revert • diff • gdiff • commit/checkin • pull/push/sync • update (your local tree) • merge • undo • server • ui • close • extras • Autosync • http://www.fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki • http://fossil-scm.org/xfer/help

More Related