Today @DavidLeedy (@NotesIn9) released another great video tutorial (watch it on Youtube here) . This time: using source control with Domino Designer and XPages (and more of course). The following tools were utilized (all of them are free of charge and easy to use):
- Atlassian SourceTree
- Mercurial (as a feature of SourceTree)
- Bitbucket (Website, remote repository even free for private usage)
- Built-in source control of Domino Designer
Though it looks really simple David put a lot of time and effort to do the video - so thanks again David for the great show!
One thing just attracted my attention instantly: David pointed out to use local NSF on disk projects (only/preferably) This is something that does not come in handy for me - and maybe for you, too, as I am working on a Domino server even when developing. This makes testing much easier than refreshing a database for testing purposes always with the local template file.
So this is what I experienced during my dabbling within the last hour (as a first impression):
- The automatic refreshing of the workspace has a huge impact on the client's and server's performance. Just notice the refreshing progressbar in the lower right corner of your Domino Designer
- If you are doing a scheduled replicaton from your local dev server to another server that may cause trouble. I even didn't let that happen by deactivating replication during my tests (I was afraid of trouble as I used "real" projects...)
But there is a "solution" for that constellation:
- Turn off automatic refresh of the workspace
- Refresh manually before committing to your repository
Wow, that's easy, hm?
How to do that
Just don't touch the refresh setting or set it back to the default value:
Refresh the on disk project manually after changes made in your NSF before committing with SourceTree:
Remember: you are using a local repository only, SourceTree does the rest with a remote repository and manages the branches etc.
Brad Balassaitis posted about an error that may occur using Hg Flow and documented a workaround here.
And more: check out my tutorial on how to import an existing Mercurial repository into a new NSF container.