Home of the Mobile Linux Lab
Version control systems
for how I'm using Subversion to manage the process pieces
For this project I am using 2 version control systems:
- Subversion will be used for maintaining the source code repositories.
- git will be used for monitoring various directories for changes
Git vs Subversion
The choice of Subversion is based on my past experience and familiarity
with using it for tracking source code. For most enterprises,
Subversion or something similar (ie, a centrally managed repository such
as Clearcase, Perforce, Accurev) will be in place or mandated. Might as well go
with the standards.
(About a month into the project). I can now say that I've tried git for
managing my scripts, html, php, etc. My observations..
Since there is just one of me, and there is a clearly defined central
location (rossberry.net) I'm sticking with Subversion for now for
tracking my work.
- Git generates change sets, which are changes to sets of files.
There really is no file version identifier. It lends itself to making
many changes across a large set of files, stabilizing those changes then
releasing the stabilized set as the next revision.
- Git is designed for distributed, multi-author version control.
There is no single point of truth except by convention and agreement.
The emphasis is on "pulling" the changes you want from any other
repository, rather than "pushing" or "committing" them to a central
location for safe keeping. There is not much advantage to this if there is just one
person doing the development
- You can make git act in a "svn-ish" fashion, ie, with a central
repo, but it is unnatural.
Git for tracking /etc
I was just trying out git by itself for managing and monitoring /etc.
However I've recently found the etckeeper package which is a set of scripts
for using git (or another version control system) to monitor changes to
/etc (or any other directory). This looks extremely useful.
If you don't want to try etckeeper, then my notes below on git can be
One of the issues I've run into is that Xen (in particular)
likes to scribble in somewhat undocumented places. Git has the quality
that a directory with existing content can become a 'sandbox' with just
a few commands
echo "*passwd*" > .gitignore
echo "*shadow*" >> .gitignore
echo "*lvm*" >> .gitignore
echo "*cache*" >> .gitignore
echo "*gconf*" >> .gitignore
git add *
git commit -m "Adding all of :/etc"
Once this is done, "git status" quickly shows you what files have
changed and a "git diff" will show you how they've changed. I do this
for /etc, /var/lib/xen (ignoring images), and /var/lib/libvirtd. At
this point I'm not pushing or merging these individual repos together,
though I may in the future. It provides a very handy way of tracking
what and how things have changed.
As a note, this saved me a lot of work while working on this project. While in the /etc/xen directory I executed "scp tempfile cobbler-lt" which of course blew away cobbler-lt rather than copying the file to the cobbler-lt vm. OUCH!. A quick git diff and I was back in business.
As I noted above, you can use git in a central repo fashion. The
documentation is umm, misleading on how to set it up. Here's what I
found to work
As I said, it is a bit unnatural...
- Create a normal git repo with content
- Decide on your central location
- mkdir /somedir/central
- cd central
- git --bare init --shared
- git --bare fetch /somedir/source_git_repo
- an 'ls' at this point will show you a set of files that looks like
an svn repo directory. This is not a working git tree. You can
not make any changes here.
- cd /somedir
- git clone /somedir/central local_git
- cd local_git;touch t;git add t;git commit -m t;git push
- You can pull from or to local_git as usual.
- You can push from
local_git into central.
- You can push from any other repo cloned from central or local_git
- You can not push from your original source_git_repo. Nor can
you pull from it into central. Delete it.
- I never figured out how to push anything other than master. I'm
sure it's possible, I just lost interest.