In early November I jumped on the SourceTree bandwagon and immediately Designer started getting an error when committing through the normal Mercurial binaries that an “eol” plugin was missing and no amount of committing, uninstalling, reinstalling SourceTree and/or Mercurial binaries could remove the mystery “eol” element from being an uncommitted change.
So I figured committing through SourceTree was now the only acceptable channel. Fine.
Then the craziness really started. Doing exactly what I have been doing with Mercurial SCM for months without issue produced startling results at an ever increasing pace like the one below when “something” decided I just didn’t need the old build path, application properties or the java source code anymore.
These days we operate a business that provides a hosted application built in XPages. This new behavior of randomly deleting code and design elements was disconcerting to say the least.
Through judicious use of design templates and local backup copies, I’ve been able to battle through the issues through heavy use of Revert… A good memory serves me well when I have to repeat the last three updates I just did after having to revert the last “unannounced” commit (a.k.a. Let’s remove some views!)
This last weekend though I decided I was spending more time getting back to Square 1 after one of the mishaps and I should just bite the bullet to create a new VM with a new Notes/Designer install with no Mercurial in sight plus a clean install of SourceTree.
Alas…SourceTree could not even clone the whole Repo from Bitbucket. (Per Lausten told me to file a bug report. I agreed. Last night the Atlassian site said they were experiencing technical troubles after I logged in to file the bug!)
So I made an entirely new Repo from a copy of the live database code. Even that was not without trials because apparently quite a bit of the repo stuff is stored somewhere within the NSF. How else can you explain the fact that even after deleting everything in the ODP and Bitbucket, the NSF still had a record of all the branches and commits plus now when I do a design refresh the task bar says that .hg…files are being inserted into the target database? I don’t remember that ever being the case before SourceTree.
Now I am totally willing to acknowledge that my usage is not what others describe as best practice and that my use case is an outlier and that may be part of the issue. As I showed in my “landmark series on Mercurial” (ha ha ha how’s that for tongue-in-cheek attitude? Sorry…working on a few hours sleep due to, you guessed it, SCM troubles most of the weekend), I switch the repo between NSF files and one of those NSF files gets replicated. Yes that causes some “Mystery Commits” due to replica ids and timestamps changing on design elements but the fact is that that process has been working flawlessly right up until the time when SourceTree was installed.
This weekend though I took Sir Leedy’s approach and made a separate template and refreshed the design whenever I needed to update the NSF but, as I mentioned above, that seems to have also produced some unexpected behavior. When you have 83 XPages, 170+ Custom Controls, and my guess is somewhere between 30,000 – 40,000 lines of Java source ( which is Pedestrian for some…I know) and Designer cannot even generate an NSF or NTF from the local SCM Repo that contains all of the design elements and all of the code, it starts to really make you consider an easier line of work like perhaps being an NFL tackling dummy. Why? Because you never know when or what may get deleted or just not added “for your convenience.”
I am so busy I have yet to actually connect my iPad Mini to my email and I have had it for three weeks which is why I have only tweeted the SourceTree Horror but a chat prompted me to pen some thoughts quickly today if not completely.
After The Season (ours, not the Holidays) I think I’ll be able to crack this nut and can post some positive vibes but my advice for now is be wary.