Monday, March 08, 2010

Part 3: xlog - Preparing to hack

The previously published parts of this series can be found here:
So, we've downloaded the source code for xlog from the CVS repoistory:
  cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/xlog co xlog
Even before configuring, the first thing I do is put the whole thing into a Git repository. The main reason for doing this upfront is that it then becomes possible to see what files are created or altered during the software building process. When we get around to making changes we can then make use of branches and commits.
  cd xlog
  git init-db
  git add .
  git commit -m 'Initial commit'
Use 'git status' to see which files are different.

Lets now build the software, as per README.cvs.

  ln -s ...
  autoconf
  automake
  ./configure
  make
  make install
Now, 'make install' will fail unless you give yourself system (root) privileges as it will try to install the code into the system directories (eg. /usr/bin, /usr/lib etc.). For the developer, there are several methods to get around this requirement. I use a tool called 'epkg', which allows software to be installed

To update the repository from upstream:

  (commit any outstanding changes to another branch)
  git checkout master
  cvs update
These changes can then be pulled into a local working branch by using:
  git checkout (your-branch)
  git rebase master

1 comment:

Luke said...

Sweet. Definitely a good idea to use version control for your local changes; I've actually done this before using CVS on top of SVN :) What do you think of git and its user interface?