Distributed Version Control

Total Page:16

File Type:pdf, Size:1020Kb

Distributed Version Control Distributed version control (Specifically, Mercurial) Overview ● Explain some of the basics of Mercurial ● Describe the ways in which Mercurial is an improvement to SVN ● Not saying SVN can’t do any of these ● Just that they are easier in a DVCS ● Most of this will also apply to git Basics (1) ● A simple model bpc4/ bindings/ ● Command-line: hg build/ demos/ .hg/ ● documentation/ Concepts engine/ qa/ ● Repository – .hg directory in root ● Working copy ~/testproject$ hg init ● ~/testproject$ ls -a Init . .. .hg ● Clone ~/testproject2$ hg clone ../testproject Basics (2) ● Concepts ● Changesets ● Directed acyclic graph ● Tip ● Branch ● Head ● Update ● Ids – SHA-1 – numbers (local) Distribution ● Concepts + ● Push = ● Pull ● Through these, repositories are combined ● When this causes a branch, a merge is needed ● Merges are also distributed Sharing changes ● Built-in hg serve (HTTP) ● File system share ● Export / import ● Bundle / unbundle ● Email ● SSH ● Shared repository space on webserver ● Hosted services like Bitbucket, Google Code ● Easily upload a copy with hg push Typical project setup ● Central repository on HTTP projects server ● Typical workflows: ● Give everyone push access ● Have a tree ‘master’ who pulls changes from everyone if approved ● These can be mixed, e.g.: ● Give senior devs push access ● Pull from new/junior developers after review Additional possible workflows ● Separated repositories for different teams ● Documentation, localisation ● Code review ● Easy to get quick feedback through hg serve ● Share changes among each other to test before pushing to central repo Easier merging — updates ● No need to update before you check in ● Can checkpoint your code before merging ● Solve conflicts separately, not mixed with changes ● SVN: adds markers for conflicting changes ● You’re blocked until you fix it ● No way to revert to previous state ● Result: users will not update until they’re done ● If a merge fails in Mercurial, you can ignore it ● Will not disrupt your workflow ● You can integrate early without risk Easier merging — branches ● Less merge conflicts on long-lived branches ● Mercurial does better tracking ● More solid underlying model and merge strategy ● Better supports intermediate merging – See updates – More up-to-date branch means less conflicts ● Better supports small commits ● SVN: blob merge, not smart ● It has repository and merge info, but doesn’t use Better repository consistency ● You can not update part of the source tree ● Merging is always required ● SVN: If you are not up-to-date, committing changes will still go through when there are no conflicts. ● This means that at that point the repository is in a state that has never even been tested or reviewed by a human. Easier branching ● SVN: discourages branching ● Technically no real obstacles, however – Slow, complicated, public, and the merging is broken – People don’t tend to do it. The ‘human factor’. ● Mercurial branching is quick and simple ● In fact, your local repository is already a branch – Which you can put aside if you want to work on something else ● Easily make local testing branches ● Still able to benefit from version control Better support for your workflow ● Small, incremental commits are good! ● ‘Checkpoints’ for your code ● Easy to review ● SVN: discourages them ● Incremental commits need to be quick ● But not thoroughly testing may break the tree ● Mercurial commits are local ● Incremental commits are easily made ● If it did not work properly, you block no-one Local repository benefits (1) ● Complete repository is stored locally ● Only need to be connected to push to central repo ● This mean you are not blocked, nor filing high- priority tickets to IT, in the following cases: ● Internet downtime ● SVN downtime – Malconfigured permissions, hard drive failure, etc. ● The above are all actual cases that have occurred with relative frequency the past years. Often blocking tens of developers. Local repository benefits (2) ● Additionally, a local repo is convenient for: ● Ziggo intranet / extranet situations ● Usage of the Amsterdam infrastructure by the US – Because it does not perform badly ● Changes that accidentally break the tree – As long as you didn’t push yet, you can go home without blocking your fellow developers ● Accepting changes from developers (e.g. from different teams, or PS) that don’t have push access ● Observing the effects of changes (e.g. merges) before sharing them. Local repository benefits (3) ● Redundancy ● As all developers have a local copy of the complete repository, there is no single point of failure in the infrastructure, and backups aplenty ● After a catastrophic failure, quickly getting back to a working setup is simple and not blocking the developers Correcting mistakes ● Rollback ● Rolls back last transaction ● Safe, convenient! – Correcting commit message, missing files, etc. ● Revert ● History editing ● Not recommended for non-local changes – Can be used on shared repositories in emergency cases ● Rebase ● Mercurial queues (‘mq’) / histedit / convert Cherry-picking ● Transplant ● Better: Daggy fixes ● Fix immediately after the change that introduced it ● Then merge forward on any branch you want it Repository sizes ● Converted BPC4 ● 4691 files, ~25000 changesets ● Repository size: 77,9 MB ● Working copy size: 74,6 MB (33,6 MB zipped) ● Converted cobrowse ● 1703 files, ~1600 changesets ● Repository size: 79,6 MB ● Working copy size: 39,3 MB (24,0 MB zipped) – (was 87,2 MB 400 revisions ago!) Tool support ● TortoiseHg ● Commit hunk selection ● HgEclipse ● Maven ● JIRA plugin, FishEye integration coming ● Fogcreek Kiln ● Mercurial repo manager + code review tool ● ReviewBoard ● Trac plugin Weaknesses ● Large binary files (>10 MB) ● Don’t do it! – Repository size increases equally – No delta compression possible ● Solutions: – Maven artifactories – Bfiles – SVN subrepository (!) Migration from SVN ● Convert extension ● Built-in ● Hgsubversion ● Designed for working with Mercurial on top of SVN ● Has ability to push changes back to SVN – Offers a path back to SVN if desired – Will not preserve usernames or timestamps though For the SVN addicts ● If you really can’t let go of SVN… ● SVN style workflow ● hg pull -u ● hg commit;hg push – can make alias for that :) ● (Don’t, though…) Links ● http://mercurial.selenic.com/ ● http://hgbook.red-bean.com/ ● http://hginit.com/ ● http://hgtip.com/ ● http://bitbucket.org/ Mindshare ● Mozilla ● Python ● OpenJDK (Java 7) ● OpenOffice.org ● NetBeans .
Recommended publications
  • Jetbrains Upsource Comparison Upsource Is a Powerful Tool for Teams Wish- Key Benefits Ing to Improve Their Code, Projects and Pro- Cesses
    JetBrains Upsource Comparison Upsource is a powerful tool for teams wish- Key benefits ing to improve their code, projects and pro- cesses. It serves as a polyglot code review How Upsource Compares to Other Code Review Tools tool, a source of data-driven project ana- lytics, an intelligent repository browser and Accuracy of Comparison a team collaboration center. Upsource boasts in-depth knowledge of Java, PHP, JavaScript, Integration with JetBrains Tools Python, and Kotlin to increase the efcien- cy of code reviews. It continuously analyzes Sales Contacts the repository activity providing a valuable insight into potential design problems and project risks. On top of that Upsource makes team collaboration easy and enjoyable. Key benefits IDE-level code insight to help developers Automated workflow, to minimize manual tasks. Powerful search engine. understand and review code changes more efectively. Smart suggestion of suitable reviewers, revi- IDE plugins that allow developers to partici- sions, etc. based on historical data and intel- pate in code reviews right from their IDEs. Data-driven project analytics highlighting ligent progress tracking. potential design flaws such as hotspots, abandoned files and more. Unified access to all your Git, Mercurial, Secure, and scalable. Perforce or Subversion projects. To learn more about Upsource, please visit our website at jetbrains.com/upsource. How Upsource Compares to Other Code Review Tools JetBrains has extensively researched various As all the products mentioned in the docu- tools to come up with a useful comparison ment are being actively developed and their table. We tried to make it as comprehensive functionality changes on a regular basis, this and neutral as we possibly could.
    [Show full text]
  • Documentation for Fisheye 2.8 Documentation for Fisheye 2.8 2
    Documentation for FishEye 2.8 Documentation for FishEye 2.8 2 Contents Getting started . 8 Supported platforms . 8 End of Support Announcements for FishEye . 12 End of Support Announcement for IBM ClearCase . 14 End of Support Announcement for Internally Managed Repositories . 14 Installing FishEye on Windows . 16 Running FishEye as a Windows service . 19 Installing FishEye on Linux and Mac . 23 Starting to use FishEye . 26 Configuring JIRA Integration in the Setup Wizard . 31 Using FishEye . 38 Using the FishEye Screens . 39 Browsing through a repository . 41 Searching FishEye . 44 Viewing a File . 49 Viewing File Content . 50 Using Side by Side Diff View . 51 Viewing a File History . 53 Viewing the Changelog . 54 FishEye Charts . 56 Using Favourites in FishEye . 61 Changeset Discussions . 64 Viewing the commit graph for a repository . 64 Viewing People's Statistics . 68 Using smart commits . 70 Changing your User Profile . 75 Re-setting your password . 79 Antglob Reference Guide . 80 Date Expressions Reference Guide . 81 EyeQL Reference Guide . 82 Administering FishEye . 88 Managing your repositories . 89 Adding an External Repository . 91 CVS . 92 Git . 93 Mercurial . 96 Perforce . 98 Subversion . 101 SVN fisheye.access . 105 SVN tag and branch structure . 106 Adding an Internal Repository . 114 Enabling Repository Management in FishEye . 115 Creating Git Repositories . 117 Forking Git Repositories . 119 Deleting a Git Repository . 122 Setting up a Repository Client . 122 CVS Client . 122 Git Client . 122 Mercurial Client . 122 Perforce Client . 123 Subversion Client . 124 Native Subversion Client . 124 SVNkit Client . 126 Re-indexing your Repository . 126 Repository Options . 128 Authentication . 130 Created by Atlassian in 2012.
    [Show full text]
  • REMOTE Preferredsubmitted to Others Without His Explicit Permission
    For more on Gilbert’s job hunt visit Gilbert’s personal web site Copyright 2021 by Gilbert Healton. Gilbert’s details can not be http://resume.healton.net/ REMOTE PREFERREDsubmitted to others without his explicit permission. Gilbert Healton [email protected] Perl-5, C, Linux with strong mentoring, planning. https://www.linkedin.com/in/ghealton/ Multii-language team software engineer. Now strongest in Perl, C, shell Arenas: commands, SQL. Linux and UNIX. History of Template Toolkit, HTML, Remote work ●●●● JavaScript, Apache, TCP/IP, networking, Git, and SVN. Very strong Back ends ●●●●● design, mentoring, documentation. Great customer support. Telcom ●●●● Net Security ○●●● 2020-08 to Software Developer – SMD Delivery – ESP 2021-06 Hard Skills: bash, zsh, Remote. Coding ●●●● C, perl, lua. Working on cloud based SMTP engine. Analyst ●●●●● AWS (AL1, ✔ Feature improvements written in C and Lua. Perl tests. Design ●●●●● Athena SQL, ✔ Document processes and on boarding processes. Documents ●●●● builds, ...) ✔ Use Circonus graphs to analyze failures. Debugging ●●●● github, git, ✔ Use git and Mercurial tools for reviews and source 2038 Bug fix ●●●● Mercurial management. Networking: (hg, Fisheye, ✔ “Interrupt Team” duties included 24x7 on-call duties, ssh, rsync, ○●●● Bamboo). starting build pipelines, responding to problems & requests. dev/tcp TCP/IP sockets ○●●● 2020-03 to Shell Developer – back end – energy sector Message queues ○●●● 2020-08 EOC Soft Skills: bash, ksh, DXC Technology. Remote multinational. Migrating large distributed AIX applications to Linux. Detail attention ●●●● csh, RHEL Life Learning ●●●● ✔ Quickly migrated scripts from suite with the most scripts. Oracle, perl, Legacy Apps ●●●●● ✔ Writing scripts to scan and automate code changes. AutoSys shell Mentoring ●●●●● Scripts, ✔ Bringing automated tests to environment without any.
    [Show full text]
  • Integrating Static Code Analysis and Defect Tracking
    MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS Integrating Static Code Analysis and Defect Tracking MASTER THESIS Jakub Papcun Brno, 2014 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Supervisor: Ing. RNDr. Barbora Bühnová, Ph.D. iv Acknowledgements I would like to thank my supervisor, Barbora Bühnová, for providing valuable feedback and guidance. I would also like to thank Ronny Kolb, for his patient guidance and all the advice he gave me during whole work on the thesis. Last but not least I would like to thank all members of ACT team in Honeywell ACS in Brno for all their help and inputs to my thesis. v Abstract Static code analysis is a powerful way of improving the quality of source code. Using tools such as Klocwork, issues in source code can be automatically detected. Some of those issues represent defects injected during implementation activities or even during earlier develop- ment phases. These issues should be properly tracked and analyzed. The present thesis investigates on how to best integrate static code analysis and defect tracking with the goal of using static code analysis data for project tracking and continuous improvement of the development process used by teams in Honeywell ACS. The thesis in- cludes the analysis of the state-of-the-art and state-of-the-practice regarding defect tracking from static code analysis tools.
    [Show full text]
  • Applying Agile Project Management for Accelerator Controls Software W
    RPPB05 Proceedings of ICALEPCS07, Knoxville, Tennessee, USA APPLYING AGILE PROJECT MANAGEMENT FOR ACCELERATOR CONTROLS SOFTWARE W. Sliwinski, N. Stapley, CERN, Geneva, Switzerland Abstract engineers, who are members of AB-CO group, develop Developing accelerator controls software is a frameworks, core components and complete systems. challenging task requiring not only a thorough knowledge Thus, the users’ community is diverse, the level of of the different aspects of particle accelerator operations, proficiency in programming varies and many people but also application of good development practices and within it work on temporary basis (such as project robust project management tools. Thus, there was a associates, fellows and technical students) for the Large demand for a complete environment for both developing Hadron Collider (LHC) start up. and deploying accelerator controls software, as well as the Requirements of the Process tools to manage the projects. As an outcome, a versatile development process was formulated, covering the Taking into account the needs of the controls controls software life cycle from the inception phase up to community and the specific nature of the controls domain, the release and deployment of the deliverables. In a list of requirements can be formulated which addition, a development environment was created characterize the properties of the anticipated development providing management tools that: standardize the process: common infrastructure for all the concerned projects; help • Maximise ease of use by providing a quick to organize work within project teams; ease the process of comprehension time (particularly significant for versioning and releasing; and provide an easy integration temporary members). of the test procedures and quality assurance reports.
    [Show full text]
  • TCD65-141111-2205-6028.Pdf
    1. TeamCity Documentation . 3 1.1 TeamCityReference . 4 1.1.1 What's New in TeamCity 6.5 . 4 1.1.2 Getting Started . 10 1.1.3 Concepts . 14 1.1.3.1 Agent Home Directory . 15 1.1.3.2 Agent Requirements . 16 1.1.3.3 Agent Work Directory . 16 1.1.3.4 Authentication Scheme . 16 1.1.3.5 Build Agent . 17 1.1.3.6 Build Artifact . 18 1.1.3.7 Build Chain . 18 1.1.3.8 Build Checkout Directory . 19 1.1.3.9 Build Configuration . 20 1.1.3.10 Build Configuration Template . 21 1.1.3.11 Build Grid . 22 1.1.3.12 Build History . 22 1.1.3.13 Build Log . 23 1.1.3.14 Build Number . 23 1.1.3.15 Build Queue . 23 1.1.3.16 Build Runner . 24 1.1.3.17 Build State . 24 1.1.3.18 Build Tag . 25 1.1.3.19 Build Working Directory . 25 1.1.3.20 Change . 26 1.1.3.21 Change State . 26 1.1.3.22 Clean Checkout . 27 1.1.3.23 Clean-Up . 28 1.1.3.24 Code Coverage . 28 1.1.3.25 Code Duplicates . 29 1.1.3.26 Code Inspection . 29 1.1.3.27 Continuous Integration . 29 1.1.3.28 Dependent Build . 30 1.1.3.29 Difference Viewer . 31 1.1.3.30 Guest User . 32 1.1.3.31 History Build . 32 1.1.3.32 Notifier . 33 1.1.3.33 Personal Build .
    [Show full text]
  • Atlassian Pull Request Template
    Atlassian Pull Request Template Aldrich often supervises disconcertingly when aerophobic Emanuel rebore perhaps and begirded her stylets. Lemony Vladimir still lour: high-hat and somnambulant Milo spooms quite next but convene her Antares bang. Lambert usually latch vertebrally or spices orthogonally when incommunicative Wade confabbing adjunctively and supersensibly. See details on highway page. In some cases you will want the break Issues into multiple smaller tasks. Desktop PC By SSTec Tutorials Kali Linux Installation Directly On phone Laptop Or PC. Play surface pull template that will need to shelf a repository to retention with customized message fields to get detailed or variety to rebound the jira. Compliance, privacy, platform roadmap, and more. Bind the number bitbucked pull request experience sense a web. Scale, data Service Management, Cloud, Jira Best practices, Customer stories, and more. Login To Gitlab Intellij. The other PDI components execute the processes designed with Spoon, and are executed from a comprehensive window. Description of PR that completes the offence here. JIRA dashboard you will find option open, when she click turn it, it out open a window that finger out options like are Issue Tracking, Project Management, Agile Kanban, Jira Classic and thereafter on as shown in screen shot below. Using Jira for testing, today! Using nexus with gitlab. Get the highlights in your inbox every week. Pushing never automatically does a merge. Learn well about our breathtaking games here! Chocolatey is trusted by businesses to change software deployments. No more posts to show. Learn how to create any type your issue in Bitbucket Cloud and circle track duty it.
    [Show full text]
  • Coding Horror: Setting up Subversion on Windows
    Coding Horror: Setting up Subversion on Windows http://www.codinghorror.com/blog/2008/04/setting-up-subversion... programming and human factors by Jeff Atwood * Apr 5, 2008 Seng up Subversion on Windows When it comes to readily available, free source control, I don't think you can do beer than Subversion at the moment. I'm not necessarily advocang Subversion; there are plenty of other great source control systems out there ‐‐ but few can match the ubiquity and relave simplicity of Subversion. Beyond that, source control is source control, as long as you're not using Visual SourceSafe . And did I menon that Subversion is ... free? Allow me to illustrate how straighorward it is to get a small Subversion server and client going on Windows . It'll take all of 30 minutes, tops, I promise. And that's assuming you read slowly. The first thing we'll do is download the latest Subversion Windows binary installer . At the me of wring, that's 1.46. I recommend overriding the default install path and going with something shorter: c:\svn\ Note that the installer adds c:\svn\bin to your path, so you can launch a command prompt and start working with it immediately. Let's create our first source repository, which is effecvely a system path. svnadmin create "c:\svn\repository" Within that newly created folder, uncomment the following lines in the conf/svnserve.conf file by removing the pound character from the start of each line: anon-access = none auth-access = write password-db = passwd Next, add some users to the conf/passwd file.
    [Show full text]
  • Implementing a Custom REST API with ABL Webhandler
    Implementing a Custom REST API with ABL WebHandler Chris Riddell Principal Architect, Portfolio+ Inc David Atkins Principal Solutions Architect, Progress Monday 7 October 2019 Agenda • Architecture evolution • Why Progress AppServer for OpenEdge? • OpenEdge REST API best practices • Portfolio+’s Implementation Experiences… • Wrap up Q & A 2 Remember this? Presentation (UI) Enterprise Services (API) Business Application [ABL] Service Interfaces Business Components Develop & Workflow Rules Entities Deploy & Test (ALM) Manage Data Access Data Sources Common Infrastructure Domain Services Social 3 © 20172019 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved. Reference Architecture for Cloud Deployment 4 Application Architecture 5 Why PAS for OpenEdge? Secure: Spring security framework included Scalability: Uses far less system resources Simplified: Multi-session multi-mode Agent Improved administration: Many tool options Flexibility: REST Service Interface Deployment flexibility: Supports containerization Future: Go forward AppServer for OpenEdge 6 REST Use Cases Modern Web Interfaces Mobile Apps Emerging Technologies Application Integration Modularization through Self-Service BI Microservices and Analytics 7 OpenEdge REST Service Interface Options A REST Service Interface: • Converts REST Request to ABL data • Routes that ABL data to appropriate ABL business logic • Converts ABL data to REST Response, & sets HTTP Status Code Recommended PAS for OpenEdge REST Service Interface options: • ‘No/low-code’
    [Show full text]
  • Maintaining and Securing Kerberos
    Maintaining and Securing Kerberos Tom Yu MIT Kerberos Consortium March 30, 2009 www.kerberos.org © 2009 The MIT Kerberos Consortium. All Rights Reserved. Overview Completed krb5-1.7 goals Rethinking the release cycle Guiding principles www.kerberos.org © 2009 The MIT Kerberos Consortium. All Rights Reserved. Mar. 30, 2009 2 Completed krb5-1.7 Goals Enhanced GSS-API error messages Cross-platform CCAPI (Mac and Windows) Kerberos Identity Management (KIM) API Master key rollover Incremental propagation Enctype negotiation Lots of Microsoft protocol extensions FAST (in progress) www.kerberos.org © 2009 The MIT Kerberos Consortium. All Rights Reserved. Mar. 30, 2009 3 Rethinking the Release Cycle Originally: 18-month cycle Proposed: 6–12 months New features available sooner Consensus of core developers Precedent: Ubuntu, GNOME, et al. www.kerberos.org © 2009 The MIT Kerberos Consortium. All Rights Reserved. Mar. 30, 2009 4 Advantages of Shorter Cycle Less scrambling to include features in release Release features only when ready Improved quality www.kerberos.org © 2009 The MIT Kerberos Consortium. All Rights Reserved. Mar. 30, 2009 5 Disadvantages of Shorter Cycle Longer maintenance lifetimes Security patch implications Possibly fewer features per release User/vendor reluctance to track releases www.kerberos.org © 2009 The MIT Kerberos Consortium. All Rights Reserved. Mar. 30, 2009 6 Topic Branches Develop new features or “topics” on branches Keep branch synchronized with trunk Integrate branch into trunk when ready Feature development can span releases Lightweight branch capability is essential www.kerberos.org © 2009 The MIT Kerberos Consortium. All Rights Reserved. Mar. 30, 2009 7 New Version Control System? Subversion (existing) Branches are heavyweight Weak merging support Git Branches are lightweight Better merging support Migration is costly Data model mismatches Hybrid approach: git-svn www.kerberos.org © 2009 The MIT Kerberos Consortium.
    [Show full text]
  • 1. Atlassian Intellij Connector
    1. Atlassian IntelliJ Connector . 2 1.1 Installation and Upgrade Guide for the IntelliJ Connector . 3 1.1.1 License and Copyright for the IntelliJ Connector . 3 1.1.2 Installing the IntelliJ Connector . 4 1.1.3 Upgrading the IntelliJ Connector . 5 1.1.4 Atlassian IntelliJ Connector Release Notes . 8 1.1.4.1 Atlassian IntelliJ Connector 2.1 Release Notes . 8 1.1.4.2 Atlassian IntelliJ Connector 2.0.1 Release Notes . 30 1.1.4.3 Atlassian IntelliJ Connector 2.0 Release Notes . 33 1.1.4.4 Atlassian IntelliJ Connector 2.0 Beta 12 Release Notes . 38 1.1.4.5 Atlassian IntelliJ Connector 2.0 Beta 11 Release Notes . 41 1.1.4.6 Atlassian IntelliJ Connector 2.0 Beta 10 Release Notes . 44 1.1.4.7 Atlassian IntelliJ Connector 2.0 Beta 9 Release Notes . 47 1.1.4.8 Atlassian IntelliJ Connector 2.0 Beta 8 Release Notes . 49 1.1.4.9 Atlassian IntelliJ Connector 2.0 Beta 7 Release Notes . 52 1.1.4.10 Atlassian IntelliJ Connector 2.0 Beta 6 Release Notes . 54 1.1.4.11 Atlassian IntelliJ Connector 2.0 Beta 5 Release Notes . 55 1.1.4.12 Atlassian IntelliJ Connector 2.0 Beta 4 Release Notes . 56 1.1.4.13 Atlassian IntelliJ Connector 2.0 Beta 3 Release Notes . 57 1.1.4.14 Atlassian IDE Plugin 2.0 Beta 2 for IDEA - Release Notes . 59 1.1.4.14.1 Atlassian IDE Plugin 2.0 Beta 2 for IDEA - Upgrade Notes .
    [Show full text]
  • 1. Guide to Installing an Atlassian Integrated Suite
    1. Guide to Installing an Atlassian Integrated Suite . 2 1.1 Here Be Dragons . 2 1.1.1 Dragons Stage 1 - Install JIRA . 4 1.1.2 Dragons Stage 2 - Set Up GreenHopper in JIRA . 9 1.1.3 Dragons Stage 3 - Install Confluence . 13 1.1.4 Dragons Stage 4 - Install FishEye and Crucible . 22 1.1.5 Dragons Stage 5 - Get JIRA and FishEye Talking . 28 1.1.6 Dragons Stage 6 - Get JIRA and Crucible Talking . 32 1.1.7 Dragons Stage 7 - Install Bamboo . 35 1.1.8 Dragons Stage 8 - Bamboo Gadgets and JIRA Victory . 42 1.1.9 After Dragons . 44 1.1.9.1 Adding Users to your Atlassian Integrated Suite . 48 1.1.9.2 Running Bamboo in a Console Window . 48 1.2 Dragon Slayers with JIRA Already Installed . 48 1.2.1 Dragons with JIRA Stage 1 - Set Up Environment and JIRA . 49 Atlassian Integration Guide Guide to Installing an Atlassian Integrated Suite We have put together a guide (see below) to integrating a suite of Atlassian applications. The guide consists of detailed step-by-step instructions for setting up a specific configuration. There are also links to the installation and configuration guides for each component. Setting up the integrated suite will give you awesome results, but we know that the setup procedure can be long and difficult. So we invite you to join the Atlassian Dragon Quest. Starting from scratch? If you do not have any Atlassian applications installed, please start at Here Be Dragons. Got JIRA? If you are already using JIRA, please start at Dragon Slayers with JIRA Already Installed.
    [Show full text]