Sometimes Linus is a genius

When you begin to do more advanced things with subversion (not my idea, trust me), I would have to conclude using tarballs and larger hard drives is more useful than subversion.

For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company [Transmeta[11]] and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN (Subversion) users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was “CVS done right”, or something like that, and if you start with that kind of slogan, there’s nowhere you can go. There is no way to do CVS right.[12]

source: Wikipedia on Git.

Please, for the love of sanity (and science), do not use Subversion…..you have been warned!

Using git for all my scm/vcs needs, I’m starting to wonder how the hell I ever lived with CVS lol. (The documentation for git isn’t to bad these days either)

git rules, cvs drools

Hmm, after a using git for all of my stuffs these past few days…..

CVS can go rot in hell, someone actually wrote a real system 😉

As much as I try to keep my OpenBSD box lean & mean, git is fairly light on runtime dependencies:

Terry@vectra$ cat /var/db/pkg/git-1.5.6.4/+REQUIRING                            
libiconv-1.12
p5-Error-0.17009
curl-7.18.2
rsync-3.0.3

libiconv is required by other things I use, and I believe gettext depends on it, and a lot of stuff uses gettext lol (uh, almost everything). curl and rsync are also useful to have around, and rsync I actually would want installed anyway (just in case I need it someday). So really, there is no serious dependency issue from it, since OpenBSDs standard git package doesn’t include the TK gui tools like FreeBSDs does. TBH, although I usually keep tcl/tk on my development systems, I never use tcl or tk-bindings. And I really have no desire to use any git front ends, nor gitk/git-gui for that matter.

Using git after getting used to living with CVS for so long, I can’t help but wonder….. why the **** anyone uses CVS anymore. Even Subversion is easier to live with then CVS, but not always a fun thing to install/manage at times, ‘least it is well documented (and tirival for cvs users to pick up hehe).

git… simple, effective, fast, and not brain damaged.

A quick conversion from cvs to git

notes:

  • I store all files related to services under /srv, or provide symbolic links.
  • Personal files are stored in a CVSROOT of :ext:Terry@vectra:/srv/cvs/ and are filed under module ‘Terry’, for lack of a better name lol.
  • server is vectra, workstation is dixie; communication done via the Secure SHell protocol.
  • I don’t use graphical software for these kind of tasks. GUIs are available, but I don’t want them wasting my time
  • The contents of my personal CVS module will be stored in it’s own spot as ‘cvs-head’ for backup purposes: I have no plans of committing to CVS or merging stuff back into it.
  • Access git is more or less just me and occasionally root@hostname, but may be expanded later
OpenBSD server:
# su - root
...
# pkg_add git cvsps
...
# groupadd -g 2005 git
# cd /srv/
# mkdir git
# chmod 7755 git
if you want to lock down the CVS, go to the CVSROOT
and revoke write access on your modules files
e.g. chmod -R ugo-w fooproject
# cd git
# git cvsimport -ikv -d /srv/cvs -C cvs-head Terry
...
# mkdir Terry
# chmod 0750 Terry; chown Terry:git Terry
# su - Terry
$ cd /srv/git/Terry
$ git init
...
FreeBSD workstation:

$ su - root
# pkg_add -r git
# pw groupadd -n git -g 2005 -M Terry
# exit
$ git clone vectra:/srv/git/cvs-head /tmp/Terry
$ cd /tmp/Terry; mv * .* ~/
$ cd ~
$ git remote add origin vectra:/srv/git/Terry
$ git push origin master
...

In a little while, I’ll probably refine things. Originally, I used the old mv file.ext file.c-vN.M and (cd ..; tar cf – project | gzip -c > /tmp/project-N.M.tar && mv /tmp/project-N-M.tar ./project/backups/) style approaches to my stuffs. The first time I went into using a source code management / version control system for a project, I selected Subversion (also known as svn) and enjoyed it quite a lot. Later on, when I decided to start checking in my configuration files, well… I like to keep my OpenBSD box pretty lean & mean; thus I used what came in the base, which was cvs (concurrent versions system). Subversion and CVS are so much alike, that I could live with CVS very easily (after all, it’s just my config files and an occasional project). I prefer svn to cvs, but hey, I’m a cheap bastard!

I’ve been thinking over the merits of Subversion, Bazaar (bzr), and git for various projects. I generally ruled out Monotone on inputs from another programmer, and having a general lack of interest in it myself. I also considered Mercurial (also known as hg), but I’m more familiar with git then hg. One of my friends uses hg for submitting patches to Mozilla and what not, and there is a project I’m involved with that I feel would benefit from using bzr; but either of those would mean a dependency on Python. Despite my levels of fluency in Python, my file server doesn’t have need of a scripting language like Ruby or Python; because OpenBSD provides Perl, SED, and AWK. So for me, git is a smaller package and it is just as easy to choose to pickup git as it is bzr. My workstation will always have Python, but that’s because I write python code lol.

Several of my various micro-projects use git on my work station, because there is no real need to stick them in the CVS server – and I don’t like CVS or rcs enough to employ them for the task lol. I’ve also considered replacing cvs with git on my laptop, and using it to fire off final commits to the CVS server, but eh… fuck CVS.