Bitbucket is a place for you and your team to host and follow your Mercurial projects. Mercurial is a so-called DVCS, or Distributed Version Control System, a new paradigm in version control, rapidly substituting the likes of Subversion and CVS.

We have plans for several purposes, including an extremely generous free plan. If you want to host an open source project with us, we are happy to grant sponsorships and give out free professional plans. We rely on open source software, and are always happy to give something back to the community!

The screenshots they provide make the site look very similar to GitHub—even down to the coloring of the diffs. If mercurial is your distributed version control of choice, you might check them out.

Daring Fireball, as ever, with the wry commentary:

It strikes me as an odd coincidence that two serious Subversion clients would debut at a time when many developers are starting to switch away from Subversion to distributed revision control systems such as Git and Mercurial.

#!/bin/sh
#
# installgit.sh
#
# A bash script to install the latest version of Git. Be sure to set the variables to the desired values. 
#
# http://git.or.cz/
#
# Mark Eli Kalderon 2008-03-15

# Git. Change to the desired versions if necessary
VER="1.5.4.4"
GIT="git-${VER}"
GITMAN="git-manpages-${VER}"

# Build directories. Change to the desired directories if necessary.
GBLDDIR=/var/tmp/${GIT}-build

# Create Git build directory, but save source files if they exist.
test -d ${GBLDDIR} || mkdir ${GBLDDIR}
test -d ${GBLDDIR}/${GIT} && /bin/rm -rf ${GBLDDIR}/${GIT}
cd $GBLDDIR

# Download and unpack Git source.
curl http://kernel.org/pub/software/scm/git/${GIT}.tar.gz -O
tar -xvzf ${GIT}.tar.gz
cd ${GIT}

# Configure and build Git.
./configure --prefix=/usr/local 
make

# Install Git. Will prompt for password.
sudo make install

# Install documentation. Will prompt for password.
curl -O http://kernel.org/pub/software/scm/git/${GITMAN}.tar.bz2
sudo tar xjv -C /usr/local/share/man -f ${GITMAN}.tar.bz2

Call the script installgit.sh and run it with:

$ ./installgit.sh

Installing Git with documentation is another matter. The brave should consult this document. The timid might content themselves with the online Git User’s Manual. Updated script to include SubtleGradient’s sane instructions on how to install Git documentation.

Suppose you have a document that you are writing and that you are considering restructuring that document. Suppose, further, you are unsure the restructuring will come off in the end. If the document is being kept in a subversion repository, then it is natural to create a branch. The trunk is the directory where the document in its main or current line of development is being kept. The branch is the directory where the alternaitive line of development is being kept. A minimal example of the directory structure would look like this:

|-- mylatexproject\
    |-- trunk\
        |-- mydocument.tex
    |-- branch\
        |-- mydocument.tex

(The diagram is in one way misleading—the trunk and branch directories can contain multiple files.) To create a branch, simply copy trunk\mydocument.tex into branch\ (using the subversion commands, so that subversion knows what’s happening).

If after restructuring your document, you are happy with the changes, then you merge these changes into the trunk. This is done with the command:

svn merge

This command does two things:

1. It compares the differences between two files
2. It applies the differences to a location in the working copy

The command thus takes three arguments. The first two arguments are the locations of the files to be compared (where these can be specified, for example, with their urls in the repository), and the path of the file in the working copy where these changes are to be applied. Notice that the changes are applied to a file in your working copy, so you will need to commit these changes after the merge. For more information see the subversion book or use the command:

svn help merge

Sounds easy. It is. But there are limitations to subversion’s merge command. Let me discuss two.

The first limitation becomes apparent when you repeatedly merge changes. It can happen that you merge the same change twice over. Sometimes this is not a problem. If subversion sees that the relevant file already has the relevant change then it does nothing. But suppose the change has been made but has been further modified. Merging a second time will produce a conflict. The problem arises because subversion doesn’t remember what changes have already been merged into the trunk and so attempts to merge these again.

The second limitation is the inability to exclude a previous revision form being merged. This is particularly relevant to writers. Suppose you are writing a paper and have been invited to give a talk based on that material. It is natural to create a branch. It is also natural to eliminate some things from the talk like footnotes. You do this and commit the change. But suppose in writing the talk you hit upon things that should be in the paper. Suppose commit these changes as well. You would now want to merge these changes into the paper, which is in the trunk. However, you cannot tell svn merge to merge only those changes, and to not merge the previous changes. So with svn merge you would end up losing the footnotes in the original paper.

It is partly for these reasons that Linus Torvalds regards subversion as broken by design. It is true that these problems do not arise in distributed models of version control such as Git and Mercurial.

Fortunately, for subversion users, these and related limiations are being addressed in the next major releas of subversion (1.5.0). But if you cannot wait until then, the script svnmerge.py can help. svnmerge.py is a tool for automatic branch management that addresses these problems. It remembers which changes have already been merged and does the right thing by only merging the new changes. And it lists changes available for merging so that some, but not all, of these can be merged. I have been playing around with svnmerge.py, and will post more about is use.

• Subversion

• Subversion, Serendipity, and Discipline

• Subversion and the Single User

• LaTeX and Subversion

• Circle Six Subversion

• Subverting Difference

• Subversion and TextMate

have ended, but I wanted to make one last observation. For authors producing complex documents whose development they need to track, what’s important is version control, not necessarily subversion. There are a variety of version control systems on the market, and while subversion suits my present needs, others may suit your needs better.

One important conceptual difference between version control systems is whether they use a centralized or distributed model. Subversion uses a centralized model. There is a central repository from which local working copies may be checked out. Intriguingly, other version control systems use a distributed model. Git and Mercurial are examples. If you are interested in a version control system based on a distributed model have a look at Mercurial and Mark Adams post about Mercurial and the single user. And if you have a spare hour (and a thick enough skin to persist through his abusive personality—apparently subversion users are stupid and ugly), here is Linus Torvalds explaining the virtues of git’s distributed model:

Update Forgot to mention, if you are using TextMate and are curious about Mercurial, there is a Mercurial bundle that you might try.