Adding Jar and zip files to SourceTree Repositories

When we use JAR files such as DocX4J for exporting from XPages we need to store these within the git repositories so that the developer can add them to their /jvm/lib folder when building the XPage application. If the correct jars are not present the build fails.

The files are stored in a /jar folder away from the /notes folder where the Noes design elements are. We also use a /documentation folder for user guides etc..

When you add these jar or zip files to the repo they do not appear in SourceTree. In my case all that appeared was the /jars/readme.txt file.

The project specific .gitignore file was blank but the default settings in git are to ignore all compiled files and all zipped files. Given that we store documentation and artwork files int eh repo the .zip would also a problem for us.

You need to modify the global .gitignore file as shown below. The project specific .gitignore file is additive tot he global settings and does not replace them.

git ignore
git ignore

Draft Engage / BLUG Slides – Seeing the Wood for the Trees

Engage - probably the best user group in the world

I am very honored to be speaking at the fantastic Engage User Group ( formerly known as BLUG ) this week.

The session is called “Seeing the Wood for the Trees” and is about how I and my colleagues use Domino Designer, Git Source Control and some mostly Atlassian products to manage our help tickets, project management, release management and billing.

The session is at 14:45 on Tuesday and is 50% slides / 50% live demo.

As I have learnt to my cost before it is difficult to go into Source Control in deep detail in 45 minutes so this session is a high level overview for both managers and Developers to show some of what can be achieved by using Source Control with Domino.

We waited a long time for Source Control in DDE and it got off to a shaky start but I am really pleased with what IBM has given us and how it works now. It really has allowed us to integrate the management of Notes / XPages code into our overall processes.

There is obviously more we want to do but this is a good story to share.

All suggestions welcomed. Apologies in advance for needing to moderate comments – my only disappointment in moving from Domino Blog has been how badly WP manages Spam – even with various plug-ins.

The DRAFT slides are here.

The GIT Command Line Rules ( but only on this occasion mind you )

We have been working on a big project for some time and were ready to merge our “develop branch” into our master branch – see a here for the model we are trying to use.

We use SourceTree from Atlassian  which is very good normally but on this occasion we just couldn’t get it to resolve the design conflicts ( every item in this case ) – 2 of us for 2 hours trying everything.

In this particular case we knew that we wanted to use ALL of the design elements from “Develop” and none from “master”

In the end we resorted to the command line and did it in 30 seconds with some help from Stack Overflow – judging by the 394 up votes we were not alone.

>git checkout Develop    ( the capital D has caused us untold grief in this project )

>git merge -s ours master

>git checkout master

>git merge Develop

Voila – it was done. Martin Jinoch will be smiling to himself, he loves the command line every time.

And here is the result – a labour of love in a single picture 🙂

**yes we know there are things we should have done better now that we have committed to this project over 300 times – thats why I will eventually put our learning here – http://focul.net/sourcecontrol

Image:The GIT Command Line Rules ( but only on this occasion mind you )