In the first article in this series (Git: Rebase vs Merge) I covered the tactics of rebasing. I discussed what merge commits are, and how to avoid them with rebasing. In this post I'll cover the benefits of rebasing, including how its use speeds up finding hard to
TL;DR Update the /usr/local/crashplan/bin/run.conf with the maximum value you want your java heap to be allowed to use: SRV_JAVA_OPTS="-Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPlan -Xms20m -Xmx1024m -Dsun.net.inetaddr.ttl=300 -Dnetworkaddress.cache.ttl=300 -Dsun.net.inetaddr.negative.
I firmly believe ReSharper is the best thing to happen to .Net since Visual Studio (NCrunch is a close second). In evangelizing it I managed to convince my program to purchase copies for every developer. One caveat: I had to train everyone. So next week I'm doing a
Exposing Web API endpoints from DotNetNuke is very easy to do and is extremely useful for accessing the internals of DNN. For example, if I want to get a list of all of the custom roles that are available for a particular DNN site, I can easily do so by
Distributed version control (git): Check. Feature branches: Check. Rebasing: Ugh, seriously? On multiple projects I've attempted to introduce the concept of rebasing commits. It rarely goes well (at first). The initial reaction tends to be reluctance and confusion. Reluctance, because it adds complexity and appears to give nothing