Category: Development

Fix: “perl: warning: Setting locale failed.”

On Ubuntu, if you have the following error:


perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "nl_NL.UTF-8",
LC_MONETARY = "nl_NL.UTF-8",
LC_COLLATE = "C",
LC_ADDRESS = "nl_NL.UTF-8",
LC_TELEPHONE = "nl_NL.UTF-8",
LC_NAME = "nl_NL.UTF-8",
LC_MEASUREMENT = "nl_NL.UTF-8",
LC_IDENTIFICATION = "nl_NL.UTF-8",
LC_NUMERIC = "nl_NL.UTF-8",
LC_PAPER = "nl_NL.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

check which locales are autogenerated with:
$ dpkg-reconfigure locales

(this should also generate the error again)

generate the missing locales with locale-gen, example:
$ locale-gen nl_NL.UTF-8

you can check if the error is solved with:
$ dpkg-reconfigure locales

if you want to change your system locale settings
$ vim /etc/default/locale

(not in “/etc/environment”, should be deprecated?)

Recommendations on Revision Control

http://phabricator.com/docs/phabricator/article/Recommendations_on_Revision_Control.html

 

Recommendations on Revision Control

Defined src/docs/flavortext/recommendations_on_revision_control.diviner:1
Group Flavor Text

Project recommendations on how to organize revision control.

This document is purely advisory. Phabricator works with a variety of revision control strategies, and diverging from the recommendations in this document will not impact your ability to use it for code review and management.

This is my (epriestley’s) personal take on the issue and not necessarily representative of the views of the Phabricator team as a whole.

Overview

There are a few ways to use SVN, a few ways to use Mercurial, and many many many ways to use Git. Particularly with Git, every project does things differently, and all these approaches are valid for small projects. When projects scale, strategies which enforce one idea is one commit are better.

One Idea is One Commit

Choose a strategy where one idea is one commit in the authoritative master/remote version of the repository. Specifically, this means that an entire conceptual changeset (“add a foo widget”) is represented in the remote as exactly one commit (in some form), not a sequence of checkpoint commits.

  • In SVN, this means don’t commit until after an idea has been completely written. All reasonable SVN workflows naturally enforce this.
  • In Git, this means squashing checkpoint commits as you go (with git commit --amend) or before pushing (with git rebase -i), or having a strict policy where your master/trunk contains only merge commits and each is a merge between the old master and a branch which represents a single idea. Although this preserves the checkpoint commits along the branches, you can view master alone as a series of single-idea commits.
  • In Mercurial, it is not generally possible to avoid having ideas spread across multiple commits. Mercurial does not support liberal mutability doctrines (so you can’t squash commits) and does not let you build a default out of only merge commits, so it is not possible to have an authoritative repository where one commit represents one idea in any real sense. Thus, Mercurial is not recommended for projects which may ever need to scale.

Why This Matters

A strategy where one idea is one commit has no real advantage over any other strategy until your repository hits a velocity where it becomes critical. In particular:
Continue reading “Recommendations on Revision Control”