Source Control For The Domino Developer

AD102 : Source Control
For The IBM Lotus® Domino®
Developer
Declan Sciolla-Lynch

@qtzar

© 2012 IBM Corporation

About Me
■ Involved in the Lotus community for over 15 years
■

■ Contributor to OpenNTF
─ Blogsphere
─ FileSendr
─ Xtalk
─ @qtzar
■ Lotus Awards Finalist for 2010 & 2011
■

■ 2012 IBM Champion for Collaborative Solutions
■

■ Co-Author of the 'XPages Extension Library' book from IBM Press to be released
April 2012
■

■ Blog : www.qtzar.com
| © 2012 IBM Corporation

Agenda
■ What is source control
■ Types Of Source Control Systems
■ Installing Source Control in IBM Lotus® Domino® Designer
■ Using Source Control In Domino Designer
─ Committing
─ Reverting
─ Branching
─ Switching
─ Merging
─ Tagging
─ Cloning
─ Pulling
─ Pushing
■ Integrating Source Control With Bug Tracking


Source Control Isn't...

JUST
FOR
TEAMS

Source Control Isn't...


Source Control Is Good For
■ Tracking changes in your code
■

■ Backing out of code that isn't working
■

■ Experimenting with changes without risking the integrity of working code
■

■ Being able to review past changes to isolate regression bugs
■

■ Working with a team of developers on the same code base
■

■ When integrated with defect/request tracking can become a self documenting list
of change reasons


Two Types Of Source Control
■ Client/Server Based
─ Requires an active network connection to the server
─ Everybody works from the same repository
─ Higher chance of conflicting changes when committing
─ Branching and Merging are more complex
─ Central repository always reflects latest version
─ Developers need to serialize their work
─
■ Distributed
─ Everybody has their own repository locally on their machine
─ Committing, Branching and Merging is all done locally
─ Can Push and Pull changes from any other local or remote repository
─ No central repository means no definitive 'latest version'
– You can create a server based repository that each person pulls/pushes with

– Increases the possibility of merging conflicts
─ Developers can work independent of each other and later merge their work
─

Two Types Of Source Control
■ Client/Server Based
─ Subversion® ( SVN )
─ CVS
─ IBM Rational® ClearCase®
─ IBM Rational® Team ConcertTM
─ Microsoft® Team Foundation Server
─ Borland® StarTeam®
─
■ Distributed
─ GIT
─ Mercurial
─ Bazaar
─ Darcs
─ BitKeeper


Installing In Domino Designer
■ Requires Domino Designer 8.5.3
─
■ Domino Designer is based on EclipseTM 3.4
─ Not all SCM software packages support Eclipse
─ Some don't support Eclipse 3.4
─ You may have to use older versions
─



■ Mercurial
─ Site : http://cbes.javaforge.com/update
─ Use version 1.6.0 MercurialEclipse
─ Use version 1.4.3 Mercurial Binaries
─
■ GIT
─ Use the Domino GIT Project from OpenNTF
─ Created by Nathan T Freeman



■ Subversion
─ Two Update Sites Required
– http://download.eclipse.org/technology/subversive/0.7/update-site/
– http://community.polarion.com/projects/subversive/download/eclipse/2.0/update-site/
─


■ You will need to be able to install from an update site
■

■ Go to the 'File → Application → Install' menu
■

■ If you don't see the menu option you need to enable it in your Domino Designer
preferences
■



■ Select the option to install new features
■

■

■

■ Then add a new update site
■ Complete the details for your selected SCM package
■ Click 'Finish' to start searching for software to install


■ Depending on the SCM selected you may need to show the older versions
─ MercurialEclipse requires an older version
─ De-select the following option
─
─
─
─ The older version can now be selected
■

■

■

■ Once selected click 'next' and follow the prompts to install the update site
■

■ Restart your designer client when prompted to activate the new plugins


■ You can verify that the plugins are installed
File → Application → Application Management


Creating A Source Controlled Application
■ Before you can do any source control operations on an application you need to
create an 'On Disk' version
■

■ This is a special flat-file version of the application that the source control plugins
can read
■

■ It is automatically synchronized with the NSF/NTF as you make changes
■

■ Synchronization can happen in both directions
■

■ Then you point the Source Control to the 'On Disk' version


■ A couple of additional notes...
■

─ Always use your own COPY of the database to develop in
– Using a replica or shared DB causes issues
– Your design changes are your own till you pull/merge in other changes
– ( pulling and merging is discussed later )
─
─ If possible run a local development server and work from that
– Really speeds up Domino Designer
–

─ Never work directly against your production environment
– A good admin would never allow this to happen in the first place
─
─
–


Committing
■ Before making any changes you should do an initial commit
■

■ Then you should commit changes every time you make a change and have
tested it
■

■ A change can consist of one or more design elements
■

■ You should always enter in a good description of the change


Committing


Committing

■ As you commit changes a revision history of the application is built up
■

■

■

■

■

■

■ You can use the 'History' panel to see this by using the 'Team → Show In
History' menu
■


Committing
■ The revision history also shows what design elements changed for the selected
changeset


Committing
■ Double clicking on a design element in the history will show you the differences
■

■

■

■

■

■

■

■

■ Handy when you want to remind yourself of exactly what changed at a later date


Reverting
■ Think of it as an Undo for multiple changes
■

■ Two types of reverting
─ Reverting changes before they are committed
─ Reverting to an older changeset
■

■ Select 'Team → Revert' to start the process


Reverting
■ If there are uncommitted changes they will be listed


Reverting
■ If you have not made changes since last commit then you need to select an
older revision


Rollback, Backout And Stripping
■ Rollback
─ Undoes the last action you took
─
■ Backout
─ Remove a single changeset from the middle of the repository
─ May result in a conflict that will need to be resolved
─
■ Stripping
─ Removes all changesets back to the selected changeset
─ Destroys the true history of the repository
─ Stripped changesets cannot be recovered


Branching
■ Branching allows you to have multiple versions of an application within the same
code base
■

■ A great way to try out new code without affecting other branches
─ A developer may create an 'experimental' branch to try out a new way of doing something
■

■ Or create a new branch for each new version of the application
─ Some developers could be working on maintaining the V1 branch
─ Some developers could be working on new features for the V2 branch
■

■ Branches can also be further branched as required


Branching


Branching
■ As you commit changes to the branch the history graph will show the new
branch


Switching
■ Use the 'Switch To' menu to change between branches


Switching
■ Select where you want to switch to, it doesn't have to be a branch.


Switching
■ After switching, the repository will be updated to reflect that revision.
■

■ Then the 'NSF ↔ On Disk Project' sync will kick in and the NSF will be updated
to reflect the On Disk version.
■

■ If there are a lot of differences in the revision you have switched to this process
can take a few moments.


Merging
■ Taking the changes made in one branch and applying them to a different branch
─ Bug fixes in the V1 Branch can be merged into the V2 branch
─ The experimental branch can be merged into active development branch
■

■ Merging branches is often easy but edge cases can be tricky
─ A design element deleted in one branch but changed in another branch
─ A design element changed in the same place in both branches
■

■ Not 100% automatic, the developer needs to be involved
─ Merge conflicts need to be resolved before the merge can complete
─ Binary files like images can't be merged so a winner needs to be selected
─ Developer should fully test the resulting code before committing the final merged results
─ Developer can reverse the merge by not committing it to the repository


Merging


Tagging
■ As the repository history gets bigger it gets harder to find a specific revision
■

■ Tagging allows you to assign a name to a specific revision
─ When you make a new release to production tag the revision with the version number
─ Tag your alpha, beta and Release Candidate revisions
─
■ Tags don't take up resources so don't hesitate to use them
■

■ Tags can be reassigned but this is a bad practice
─ Some source control systems allow you to move a tag to a different revision
─ Destroys the true history of the repository
─


Tagging


Cloning
■ Cloning a repository creates a copy of a remote repository on your local machine
─ Normally done when a new developer joins a team
─ The clone remembers where it originally came from so you can later pull and push changes
─
■ Cloning just creates the 'On Disk' version of the application
─ The developer can then create a real NSF/NTF to work in
■

■ The initial clone process can be slow for a large project
■

■ Start the process in the Package Explorer by creating a new project


Cloning
■ Select your Source Control system from the list of wizards


Cloning


Pulling
■ Pulling updates your repository with changesets from a remote repository
■

■ Only changesets you are missing are transferred
■

■ As a general rule you should always commit your own changes before pulling in
additional changesets
■

■ If your pulling changesets into the same branch your currently working in then
you should do a merging pull


Pulling


Pushing
■ Pushing will send your changesets to a remote repository
■

■ If your repository has new branches you may have to select the 'Force' option


Pushing
■ You can also elect to only push up to a certain revision, later revisions will not be
pushed to the remote repository


Integrating A Feature/Defect Tracker
■ Both Open Source and Commerical options available
─ Redmine
─ Trac
─ Jira ( commercial license by Atlassian )
─ Buglizza
─ FogBugz ( commercial license by FogCreek)
■

■ Can read the commit text from your repository and perform actions based on
special codes in the text
■

■ Can be used as a central repository for Distributed Source Control systems
─ Just another repository that everybody can pull from and push to
■

■ The setup of these systems is beyond the scope of this presentation
─ Bitnami has a number of pre-installed kits for easy deployment in your organization
─ http://bitnami.org
─ | © 2012 IBM Corporation

■ Fixes, Closes
─ Followed by tracker #
─ Automatically closes the defect/feature
─
■ Refs, issueID
─ Followed by Tracker #
─ Add link to that revision in the issue
history
■

■ @0h0m
─ Time tracking in hours and minutes
■

■ Different systems may use their
own codes


Resources
■ Mercurial For Eclipse
─ http://www.javaforge.com/project/HGE
─
■ SVN For Eclipse
─ http://www.eclipse.org/subversive/
─
■ Egit
─ http://eclipse.org/egit/
─
■ Redmine
─ http://redmine.org
─
■ Bitnami
─ http://bitnami.org


Session Evaluations
■ Please fill in your session evaluations
■

■

■ Speaker
─ Declan Sciolla-Lynch
─
■ Session Number
─ AD102
─
■ Session Title
─ Source Control For The IBM Lotus Domino Developer

@qtzar

Questions


Legal disclaimer
© IBM Corporation 2012. All Rights Reserved.

The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication,
it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice.
IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.

References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced
in this presentation may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any
way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other
results.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance
characteristics may vary by customer.

IBM, the IBM logo, Lotus, Lotus Notes, Notes, Domino, Quickr, Sametime, WebSphere, UC2, PartnerWorld and Lotusphere are trademarks of International Business Machines Corporation in the United
States, other countries, or both. Unyte is a trademark of WebDialogs, Inc., in the United States, other countries, or both.

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.

88 | © 2012 IBM Corporation

Source Control For The Domino Developer

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Source Control For The Domino Developer

Ähnlich wie Source Control For The Domino Developer (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Source Control For The Domino Developer

Hinweis der Redaktion