Tag Archive: Source Control

Article: Source Control – Merge

Source control is a fantastic tool, but when it’s new, it can be confusing.  This month on SocialBizUg.org, I talk about merging.

This month I’m going to talk about merging. You write your code. You commit your code. You pull code from other developers and you merge it.  Ideally, you’ve communicated with your fellow developers and the merge just … well, merges.  There was nothing overlapping and it all merges together and you can push up the merged code. Great.  But what do you do when that doesn’t happen?  What do you do when it all conflicts?

Read the full article…

Stupid Source Control Mistake

So you’re using Source Control in XPages, hooray!

And you’re cruising right along.  Committing changes, pulling code, pushing code, merging, hooray!

Then one day, you pull new code, and you right-click expecting to sync the on-disk with the local NSF.  But suddenly out of the blue, sync isn’t an option.  Just “Associate with New NSF” and “Associate with Existing NSF”.  But your on-disk is already associated with an NSF.  What happened?  Did it get UN-associated?  It might not have.

First pull of the day?  Maybe you went straight to Package Explorer and pulled.  You didn’t yet open or click on your local NSF, so it isn’t in memory.  Apparently to source control, it isn’t available.  Go back to your applications list and open the twistie for the local NSF.  Wake up Designer and go back to Package Explorer.  Voila!  Now you can sync again.

Version Control with Git by Jon Loeliger & Matthew McCullough

Version Control with Git

by Jon Loeliger & Matthew McCullough

Publisher: O’Reilly Media

This is a comprehensive book on Git with everything you would need to know from A to Z.

Chapters: 1. Introduction, 2. Installing Git, 3. Getting Started, 4. Basic Git Concepts, 5. File Management and the Index, 6. Commits, 7. Branches, 8. Diffs, 9. Merges, 10. Altering Commits, 11. The Stash and the Reflog, 12. Remote Repositories, 13. Repository Management, 14. Patches, 15. Hooks, 16. Combining Projects, 17. Submodule Best Practices, 18. Using Git with Subversion Repositories, 19. Advanced Manipulations, 20. Tips, Tricks, and Techniques, 21. Git and GitHub

Did I mention this book is comprehensive?  It really digs into Git, from how Git got started, how it was developed and deep into the inner workings of Git.  This will be great for some people and exactly what they want to know.  It was a little too in depth for me, but it’s better to have too much material versus not enough.  The book is well organized and the examples are clear enough that if you are not interested in the details, you can move on to what you need to know.  As stated early on the reader should be “comfortable” with the Unix shell.  Um, yeah.  Not that the book is at fault with this requirement, it’s entirely a Git requirement, but if you don’t do Unix, you probably shouldn’t do Git or you’ll be learning two rather complex things at once.

Having used other source control systems prior to reading this, I appreciated many comparisons of Git and other systems.  While it isn’t necessary to understand source control prior to reading this book, it was nice to have a frame of reference if you do know other systems.

While the book was a deep dive into Git, I didn’t feel like it was particularly over or under any specific level of user.  Beginner users and advanced users alike could learn a great deal of information from Version Control with Git.  From the history and getting started sections, up through the advanced section.  The tips and tricks chapter is useful for all levels of user, as well as the many tips sprinkled throughout the book.

Amazon affiliate link

Version Control with Git

OReilly affiliate link

Obtained From: Publisher
Payment: Free

I review for the O'Reilly Blogger Review Program

Article: 5 Tips For Source Control in Domino

I’ve posted a couple of articles on SocialBizUg.org on Source Control.  This month I give you 5 tips to help use it with fewer issues.

5 Tips For Source Control in Domino

Hopefully you read my articles on setting up source control and using source control, and you’ve started using it. I now use source control on every project I work on, even if I am the only developer on the project.  It has gotten to the point where I find it so useful, I can’t imagine working without source control. So if you haven’t gotten started yet, go back and read those articles and get going!  Now that I’ve been using it for a while, I have some tips for using source control, particularly when you are working with other developers.

Read more…

Odd Problem with Mercurial and Bitbucket and Domino

I’ve been using source control for a while now.  I’m a convert and a huge fan.  I’ve been using Mercurial in Domino Designer 9 pushed up to Bitbucket.  I’ve had several different projects, some alone and some with a team.  I’ve gotten to the point where I prefer to use source control over not using it.


I ran into an odd problem.  I created a new NSF in Designer.  I shared it up to bitbucket.  I opened up a new VM and pulled down a clone of the repository (something I’ve done many times).  Designer went through all the normal steps and then… nothing happened.  The repository never appeared in Designer.  Just for the heck of it, I pulled down another repository I had access to, same steps and POOF there it was in Designer.  Tried another clone of another repository and … nothing.

I tried the same thing in another VM that I have been using for months with zero problems and same results.  Two different VMs.  One with Designer 8.5.3 UP1 and one with Designer 9.  App A works perfectly on both.  App B doesn’t work on either.

The folder for App B ends up in the workspace folder, just like App A.  However, it never appears in Designer’s Navigator or Package Explorer.  Refresh doesn’t work.  Closing and re-opening Designer doesn’t work.  Even creating a new NSF and trying to link it to the repository doesn’t work.  App A appears in the list of choices, but App B does not.  Spinning my chair clockwise didn’t help either.  Nor did throwing salt over my shoulder.

On my original VM, I can still commit and push up the changes to Bitbucket for App B (well for App A, too, but that one’s working so that makes sense).

Anyone?  Any thoughts?  Anyone else seeing this?  (For the record, I had a co-worker try and pull the clone, too and he had the same exact results).