While I have been a happy subversion user, there are some areas that are a continual source of frustration. No commits offline. Limited merging facilities. (See my earlier post.) The limitations on merging is the serious issue for me. Prose production presents opportunities for merging that subverion cannot handle (at least at present). Distributed version control systems such as Git or Mercurial solve both these problems. Centralized version control systems like subversion are a good model for me since I work on two machines (at home and at work). This can, of course, be mimicked with distributed version control systems, but I am also reluctant to abandon my subversion repository and am not sure if I trust the extant migration scripts. However, Git now includes the git-svn command that allows you to use Git locally with a centralized subversion repository. Dr Nic explains how in this post. I will be exploring this in the New Year. So I have installed Git. Here is the bash script that I used to install Git on OS X Leopard:
#!/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.
{ 3 } Comments
Please elaborate. What are those opportunities? This suggestion alone is far more intriguing than things like offline commits, which are touted everywhere and more of a convenience than a new way of working.
Subversion is great for propagating a working environment on multiple machines, and backing up against disaster. But you’re right that it gives no help at all for intelligently using all the information it safeguards for things like relocating bits of text within and between files, observing the timeline of changes, etc..
In general, I am astonished how poor word processing tools are for large complex documents. It’s too hard to get an overview of a document structure, to zoom in/out, to describe and save chunks of text for insertion later, to see visually how a document changes over time, to save associated assets (figures, etc.) in an orderly way. Latex Reftex is a pretty good combo, as are Scrivener markdown, but it all feels quite jury-rigged. There’s a long way to go.
There are several. Chief among them is the ability to merge some but not all differences. I would like to be able to pick the changes to merge. I discussed this here, there is a little more discussion of this in section 2.4 of “Subversion and TextMate: Making colaboration easier for LaTeX users”. This section also describes a fix, in subversion, with svnmerge.py. I have played with svnmerge.py, but utlimately I found it awkward to use in practice and an inelegant solution.
The problem, of course, is that subversion is broken by design. See Linus Torvalds google talk I embedded in this post.
This is one of the benefits of using an editor that supports code folding. ;)
OK, but there are a number of ad hoc ways of dealing with this.
As you mention, RefTeX does this. TextMate has similar in built facilities for dealing with LaTeX documents.
Totally agree with you about this. This is part of the reason that I have claimed before that none of the GUI implementations of subversion are compelling.
Agreed, but I still believe that text based solutions will you get you further than any alternatives that I know of, and there is room to extend the existing text based solutions.
Very interesting. Please do pass on your experiences with git as they develop. I’m also considering if git, mercurial, or bazaar might be a useful additional to my latex workflow.
Linus mentions that git doesn’t track files but tracks content. This could be especially useful for work in latex, where one often moves passages of text from one file to another. I suppose a content-based rather than file-based addressing system would make it much easier to merge a selected set of meaningful blocks of text and track that change.
On the other hand, I am bit disturbed by git’s poor windows support and by Linus’s focus on speed and large codebases. All of this suggests the system has been highly optimized around problems very specific to the linux kernel. Mark Shuttleworth and the Bazaar website make a good pitch for the value of a lossless repository, especially for relatively small projects.
My impression is that all these systems support integrating with svn. The quality of the GUI’s for history-tracking and merging will probably decide how much value these features really add for writing.
Post a Comment