#!/bin/bash
# 
# With hgsubversion, you can clone *ANY* folder in a subversion repository. 
# (Well, really any non-empty folder)
# Let me repeat, you do not have to clone the entire repository! It could be
# a branch or even a folder within a branch. If you clone a branch folder,
# your pushed changesets will go into the branch.
# 
# Requires:
#   subversion installed
#   rebase extension
#   hgsubversion extension
#
# We have the following repositories:
#     SVN repo <-> hg-svn
# 
# SVN repo:       company subversion repo on remote server, https://ip/svn
# hg-svn:         local developer copy of SVN repo using hgsubversion 
# 
# Our goal is to clone/checkout only a sub-folder, make changes, and see
# what happens.
# 
# Example:

# Turn on debugging so we can see the commands as they're issued.
set -x
# Clean up after any previous run.
rm -rf folder_test

mkdir folder_test
cd folder_test

# Create a "company" SVN repository.
svnadmin create SVN
svn co file://`pwd`/SVN SVN_temp

# Put something in the SVN repository or we won't be able
# to see why some of the steps are necessary.
cd SVN_temp/
svn mkdir trunk tags branches
svn ci -m "Initial folders"
echo "Company file" > trunk/company.txt
svn add trunk/company.txt
svn mkdir trunk/subfolder
echo "text" >> trunk/subfolder/anotherfile.txt
svn add trunk/subfolder/anotherfile.txt
svn ci -m "Added some files"
cd ..

# Create our clone of SVN. Just grab the folder you want. It could be
# a branch or even a folder in a branch.
hg clone file://`pwd`/SVN/trunk/subfolder hg-svn

# Make some changes
cd hg-svn
echo "more text" >> anotherfile.txt
echo "text" >> newfile.txt
hg add newfile.txt
hg com -m "Made some change in hg."
hg push
cd ..

# Look at the complete subversion repository to see what happened.
cd SVN_temp
svn up

# See that out line was added.
cat trunk/subfolder/anotherfile.txt

# See the new file.
set +x
echo "=========================="
echo "Results:"
find . | egrep -v '\.svn'
cd ..

# Use the following command to see the log of changes:
# svn log -v SVN_temp

#!/bin/bash
# 
# Merging a separate feature repository into a folder in an SVN repository by 
# way of two hg repositories.
# 
# Inspired by: http://hgtip.com/tips/advanced/2009-11-17-combining-repositories/
# 
# Requires:
#   subversion installed
#   convert extension
#   mq extension (for strip)
#   rebase extension
#   hgsubversion extension
#
# We have the following four repositories:
#     SVN repo <-> hg-svn <-> hg-svn-work
#     feature
# 
# SVN repo:       company subversion repo on remote server, https://ip/svn
# hg-svn:         local developer copy of SVN repo using hgsubversion 
# hg-svn-work:    a local working copy of hg-svn. (Why? In my case,
#                 it's inside a Linux virtual machine running on a Mac.
#                 hg-svn is on the Mac.)
# feature:        a completely separate hg repository containing some new 
#                 program developed in isolation. (Perhaps a contract job?)
# 
# Our goal is to put feature and all of its history into SVN, but we must
# place it into a sub-folder /new/feature.
# 
# Steps:
# 1. Use hg convert to re-map feature/* to feature/new/feature/*.
# 2. Hg pull the converted feature repo into hg-svn-work.
# 3. Hg rebase the pulled feature onto the previous tip.
# 4. Hg push the changes to hg-svn
# 5. Hg push from hg-svn into the SVN repo.
# 6. Hg pull changes from hg-svn into hg-svn-work
# 7. Hg strip the pulled feature changesets from step 2.
# 
# Using a feature branch:
#   It would be nice to put feature into its own subversion branch
#   first and then merge it back into the trunk. If you'd like to do
#   this, enable USE_A_BRANCH below.
USE_A_BRANCH=1  # enable = 1

# Example:

# Turn on debugging so we can see the commands as they're issued.
set -x
# Clean up after any previous run.
rm -rf feature_test

mkdir feature_test
cd feature_test

# Create a "company" SVN repository.
svnadmin create SVN
svn co file://`pwd`/SVN SVN_temp

# Put something in the SVN repository or we won't be able
# to see why some of the steps are necessary.
cd SVN_temp/
svn mkdir trunk tags branches
svn ci -m "Initial folders"
echo "Company file" > trunk/company.txt
svn add trunk/company.txt
svn ci -m "Added company.txt"
cd ..

if [ "$USE_A_BRANCH" = "1" ]; then
    # Create a feature branch in subversion
    svn copy file://`pwd`/SVN/trunk file://`pwd`/SVN/branches/feature -m "Added feature branch"
fi

# Create our first and second level clones of SVN.
if [ "$USE_A_BRANCH" = "1" ]; then
    # Make sure to clone the new branch!
    hg clone file://`pwd`/SVN/branches/feature hg-svn
else
    hg clone file://`pwd`/SVN/trunk hg-svn
fi
hg clone hg-svn hg-svn-work

# Create a new feature in its own repository. It needs more than one
# changeset to show how hgsubversion will rebase after pushing each 
# changeset.
hg init feature
cd feature
echo "Some text" >> readme.txt
hg add readme.txt 
hg com -m "Added readme.txt"
echo "Some more text" >> readme.txt
hg com -m "Added more text"
cd ..

# Create a clone/copy of feature where we move everything into the
# subfolder that it needs to be in for the company SVN layout.
echo "rename . new/feature" > map.txt
hg convert --filemap map.txt feature feature-conv
rm map.txt

# Pull the converted feature repository into our working
# copy of the SVN repository. Save the current tip since we will
# need it to rebase.
cd hg-svn-work/
OLD_TIP=`hg log --template "{rev}\n" -r tip`
hg pull -f ../feature-conv
# All of the new changesets start from OLD_TIP + 1. Rebase them on
# OLD_TIP.
hg rebase --source $(($OLD_TIP + 1)) --dest $OLD_TIP
# Push the changes up one level to hg-svn
hg push
cd ..

# Clean up the feature copy.
rm -rf feature-conv

cd hg-svn/
# Update hg-svn since hgsubversion will not detect any outgoing 
# changesets otherwise.
hg up
# Push the changes to SVN. Each changeset pushed will cause a rebase.
# If you are pushing a lot of changesets (e.g. I did 85), this will take a
# while since the algorithm is O(n^2). The first push of N changesets rebases
# N-1 changesets, then the next rebases N-2, etc. It will appear pleasantly
# faster as it goes.
hg push
cd ..

# Pull the newly rebased changesets back to our working repository. 
# Unfortunately, we've now done half of an svn push/rebase here. We need
# to manually strip away all of the revisions we pulled from feature-conv
# earlier as they've all been duplicated now.
cd hg-svn-work/
hg pull
hg strip -f -n $(($OLD_TIP + 1))
cd ..

cd SVN_temp
svn up

if [ "$USE_A_BRANCH" = "1" ]; then
    # Optionally, merge the svn feature branch back to the trunk
    # Note: I don't know (yet) of a simpler way to do this.
    DIR=$(dirname $(pwd))
    svn merge file://$DIR/SVN/branches/feature trunk
    svn ci -m "Merging feature branch back to trunk"
    svn delete branches/feature
    svn ci -m "Closing feature branch"
fi

set +x
echo "=========================="
echo "Results:"
find . | egrep -v '\.svn'
cd ..

# Use the following command to see the log of changes:
# svn log -v SVN_temp

Well, it’s not new…

The human understanding when it has once adopted an opinion (either as being the received opinion or as being agreeable to itself) draws all things else to support and agree with it. And though there be a greater number and weight of instances to be found on the other side, yet these it either neglects and despises, or else by some distinction sets aside and rejects, in order that by this great and pernicious predetermination the authority of its former conclusions may remain inviolate. — Sir Francis Bacon Aphorism 46,’ Novum Organum, Book I (1620)

and apparently, it’s not just stubbornness…

There are two competing ideas on the process that governs the formation and maintenance of beliefs: 1) people maintain a belief because they have limited access to opposing beliefs, or 2) because they actively filter information in a way that avoids conflicting views. A new meta-analysis of past studies confirms the existence of active avoidance; when people are offered an opposing viewpoint, they will ignore it in favor of a supportive viewpoint in two out of three instances. — Ars Technica Study: choir prefers being preached to by 2:1 margin

That study revealed things that most of us have noticed to be true: more “close-minded” people tend to prefer their bias more than others and bias increases with age.

Can it be treated in others?

Unfortunately, the study only confirmed that the effect is real, but can say nothing of how it works. What it says, to me based on my own experiences with highly polarized people, is that the harder you hit someone with an opposing viewpoint, the more resolutely they will dig their mental feet in the ground. A long term, subtle approach may be the only effective means. And what is worse, it seems that the longer and more subtler the approach, the better the results with the highly annoying side effect that it takes a long time.

This reminds me of a tactic used in corporate meetings, but that could really apply anywhere. If you wish to get an opponent to take your idea, often it is best to suggest the idea as though it came from the opponent and then to remark on what a fabulous idea it is. More often than not, people’s vanity will work in your favor. No one likes to admit they were wrong even when the idea was never really theirs to begin with.

Can we treat ourselves?

The first step to solving a problem, is admitting that you have one. We all have firm ideas, and future research will probably lend insight as to why we all suffer from Mental Inertia. The only effective self-treatment is to try to be conscious of it. Associate your displeasure with other people’s stubbornness with Mental Inertia. It’ll help us all to realize when we’re guilty ourselves.

So, should we abandon all of our firmly held beliefs? No, by all means, hold them dear, just be willing to honestly listen to new and contrary ideas.

Right-Clicking From Cory Foy:

do a “Shift-Ctrl-Click” to access all the Right-Click goodness

94Mbps on a 100 Mbps link

I would have normally used scp to do the transfer, but had read ssh + tar was much faster due to scp’s implementation being inefficient. Guess, it’s true. Rock on, folks.

nylon -f -a company_ip

I like to run it in the foreground so I don’t forget to turn it off. Another note is that for some reason I wasn’t able to get nylon to work with Firefox unless I told Firefox to use the older SOCKS v4 protocol. Nylon hasn’t been updated in a couple of years, perhaps it has a v5 bug?

Another option that I haven’t tried, but appears to work with windows as well is 3proxy (with the world’s worst website).

Finally, the two solutions above can give you full internet access and not just web pages. However, viewing web pages through a proxy in this manner can be quite sluggish, so it might be worth your time to use squid as your web proxy since it caches content.

Here’s to freedom.