See my blog post about the presentation: http://per.lausten.dk/blog/2012/11/source-control-with-domino-designer-8-5-3-and-git-my-talk-at-dannotes-november-2012.html

1. Introduction to
source control with
Domino Designer 8.5.3
and Git
PHL-Consult.dk
info@PHL-Consult.dk
Per Henrik Lausten
November 28, 2012 per.lausten.dk/blog/
twitter.com/perlausten

2. About Per Henrik Lausten
●
Full-time developer and part-time administrator with my
own one-man company
●
Chairman of NotesNet – an assocation of 25 independent
consultants
●
Member of the board at OpenNTF – open source for IBM
Notes/Domino and IBM Connections
●
Member of the board at DanNotes
●
Mentor for XPages developers in several companies
●
Experienced XPages web application developer
●
startdithjerte.dk
●
mediaplus.dk
●
cbbpremiumpro.dk
●
collaborationtoday.info
●
sherlockapp.dk
●
and more

3. Agenda
●
Purpose of source control
●
Central vs. distributed source control
●
Distributed source control: terminology
●
Source control best practices
●
Source control in DDE 8.5.3
●
Managing the source code
●
Tips
●
Demo: sharing
●
Demo: cloning

4. Purpose of source control
●
For teams and individuals
●
Tracking and controlling changes
●
Being able to test new code without risking the integrity of
working code
●
Being able to work on a new version and still being able to
support production versions (example: 1.0, 2.0 beta)
●
Being able to review past changes to isolate regression
bugs
●
When integrated with defect/request tracking can become
a self documenting list of change reasons

5. Central vs. distributed source control
Central
●
Uses a central repository on a server
●
Requires an active network connection to the server
●
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
●
Systems: Subversion ( SVN ), CVS, IBM Rational
ClearCase, IBM Rational Team Concert, Microsoft
Team Foundation Server, and more

6. Central vs. distributed source control (cont.)
Distributed
●
Everybody has a working copy of the repository locally on their
machine (peer-to-peer approach)
●
Committing, branching and merging is all done locally (can work
offline)
●
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
●
Systems: Git, Mercurial, and more

7. Distributed source control: terminology
●
Committing
●
Reverting
●
Branching
●
Switching
●
Merging
●
Tagging
●
Cloning
●
Pulling
●
Pushing

8. Source control best practices
●
Commit related changes
●
Commit often
●
Don‘t commit half-done work
●
Test code before you commit
●
Write good commit messages
●
Version control is not a backup system (so don't use it for auto-
committing on a schedule)
●
Use branches
●
Agree on a workflow
Source: http://www.git-tower.com/files/cheatsheet/Git_Cheat_Sheet_grey.pdf

9. Source control in DDE 8.5.3
●
Team development -> Set Up Source Control for this
Application...
●
This creates an on-disk Eclipse project of the source code
in the application (NSF)

10. Source control in DDE 8.5.3 (continued)
●
You need to synchronize the application (NSF) source
code with the on-disk project (automatic by default)
●
It is the on-disk project which is under source control
management

11. Managing the source code
●
Requires a tool
●
Can be installed in Domino Designer (as an Eclipse
plug-in install)
(example tools: Mercurial for Eclipse, SVN for Eclipse,
Egit)
●
Can be installed outside of Domino Designer
(example tools: TortoiseCVS, TortoiseSVN, TortoiseGit,
CVS)
●
Can even be installed on your Mac if you run Windows
in a VM
(example tools: Sourcetree, Tower)

12. Tips
●
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
●
If possible run a local development server and work from
that

13. Demo: sharing
●
Create application
●
Create on-disk project
●
Share on-disk project (initial commit)
●
Committing additional changes
●
Editing source code in the on-disk project (outside of
DDE)
●
Adding source code to the on-disk project (outside of
DDE)

14. Demo: cloning
●
Cloning an existing source controlled project as an on-
disk project:
Collaboration Today on Github
https://github.com/OpenNTF/collaborationtoday
●
Import on-disk project into DDE workspace (from
Package Explorer)
●
Associate on-disk project with new NSF

15. Questions?
Per Henrik Lausten
per@PHL-Consult.dk
PHL-Consult.dk
per.lausten.dk/blog
@perlausten

16. Reference
●
Keith Strickland: source control in DDE
●
Part 1:
http://xprentice.gbs.com/A55BAC/keithstric.nsf/default.xsp?documentId=B236F39DEAF6C52F85257A72001157BF
●
Part 2:
http://xprentice.gbs.com/A55BAC/keithstric.nsf/default.xsp?documentId=B5D76A6DA163DCB585257A7C004802B
●
Part 3:
http://xprentice.gbs.com/A55BAC/keithstric.nsf/default.xsp?documentId=C2C46D278948A24985257A7D0055D25
●
Martin Jinoch: version control for Notes developers:
http://jinoch.cz/my-blug-presentation-version-control
●
Martin Jinoch: Using Git with Domino Designer - the hardcore way:
http://jinoch.cz/using-git-domino-designer-hardcore-way
●
Enrico Campidoglio - Grokking Git by seeing it:
http://vimeo.com/52633764#at=0
●
AD102 : Source Control For The IBM Lotus® Domino® Developer by Declan Sciolla-Lynch (Lotusphere 2012)
●
EGit for IBM Domino Designer:
http://www.openntf.org/internal/home.nsf/project.xsp?action=openDocument&documentId=D1668ED7018AA0858625
●
Wikipedia: http://en.wikipedia.org/wiki/Revision_control
●
Try Git online: http://try.github.com/
●
Book: Pro Git: http://git-scm.com/book