I have always really hated the Git Version Control System (or VCS).
I am pretty comfortable working with other products like RCS, CVS and Subversion (SVN). I am not a developer, so my main use for a VCS is a to allow me to keep track of the changes in my SlackBuild scripts or my server’s log book. I use RCS for this, it is simple but effective.
Of course, in order to compile software it is often required to check out the source code for the program. This is how I got familiar with CVS, SVN, mercurial and git. Way back when I was “build manager” for a software company, I have used PVCS, Clearcase and Visual SourceSafe which are all commercial programs. So, I have been around.
Still, git still confused me after all that time as a end-user. Git uses some alien (to me) concepts which I did not grasp because I never took the trouble to dive into its documentation – I knew just enough to checkout source code from a git repository and did not need – did not want to – know more.
This changed recently. Because two of the projects I am involved with are preparing to use git as their Version Control System, I was forced to start learning how to approach the tool as a developer.
I quickly decided it was worth the while to run two parallel tracks: start reading documentation, and at the same time actually using git by setting up a server for hosting git repositories.
I found some places which host very good reading material.
- The Pro Git book at http://progit.org/ . This book is hosted itself in a git repository and the language translations are coordinated using git. Well-written with lots of visual examples.
- The Git Community Book at http://book.git-scm.com/ .
I’m halfway through the “Pro Git” book, retracing my steps a few times after the new concepts found a place in my brain. Indeed, git is starting to make sense now. Surely it has some very strong points which make it interesting not only for large projects with lots of developers who are scattered all over the place (like the Linux kernel developers) but also for small projects like those I am participating in.
Perhaps I will document more about my git activities in a future Wiki article – for instance how I am setting up an online git repository.
This made me think of something else: could it be beneficial to dump the history of my SlackBuild script repository (past and future) into a git repository? What do you think – will it help you if you are able to look at older revisions of my SlackBuild scripts? Some time ago I started copying the SlackBuild script into the documentation directory of every Slackware package I create, but I realize that once I release a newer package, the older scripts disappear from public view.
Leave your opinions in the comments section below please.
Eric
Personally I *LOVE* Git, specially for developing software. But then, it *is* hard to learn, specially if you are used to CVS or Subversion or similar. Personally, I would like the idea of having the slackbuilds in some kind of VCS repository.
This doesn’t apply to you Eric, but in case others are looking for a solution locally for just their own personal repo’s, I recommend rdiff-backup.
My repo isn’t shared with others (which is why rdiff doesn’t satisfy what you’re looking for) but I needed a way to backup all my binaries and source tarballs, etc. in my build system for gnome, and all my other slackbuilds.
I had tried git at first, then mercurial, and finally bzr . But the problems I had with those solutions was that they were limited on binary size. Perhaps ( and likely ) I did something wrong.
The rdiff-backup allowed me to create the incremental diffs of my whole buildsystem, with the ability to jump back in time if need be, or simply pulll out older files as needed.
Git is a very well designed tool. I use it mainly for keeping track of my personal scripts and also to share some configuration files in my home network. The learning curve was very smooth for me, maybe because I didn’t have any svn or cvs usage background.
And yes it will be great to have a git trace of your slackbuild repository. I can foresee the benefit in terms of having a clear view of the history of ecah slackbuild but also, for us who rely a lot on your slackbuilds, the educational value is obvious.
You might also consider Mercurial as an alternative to Git. There’s a nice tutorial written by Joel on http://hginit.com/
I did this already with my personal SlackBuilds. Here it is: http://github.com/nonstop/slackbuilds/
Before git I tried mercurial. For small projects I think there are no changes between git and hg, but for bigger ones hg is VERY slow.
having your repository on git should be a nice idea also for maintaing branches for different slackware versions or for forking and maintaining a local repo with custom changes in branches 🙂
I’m trying to do something similar with slackbuilds.org repo customizing it for current and I like the results 😀
When you get familiar with git, you will know that svn is so lame… Yes, git is beautiful.
A nice article with several must-know git commands: http://about.digg.com/blog/10-useful-git-commands
Eric
A series of git howto-articles was written by Amarok developer Edward Toroshchin, published on his blog. You can find “Git is your friend, not a foe” at http://hades.name/blog/tag/git/
Eric
It would be nive to have all SlackBuilds in one git repository. Master branch – official SlackBuilds (e.g. those from sources directory), and may be optional several other branches (slackbuilds.org, yours, etc.).
Yeah Eric, I think it’s going that way. I think you should too 🙂
Kindest regards,
Bradley.
Unfortunately SVN for Slackware does NOT support Kerberos. For that reason I must use Debian :(. I am using multilib, but don’t know why cannot compile subversion on my machines. For the multilib or not – subversion can’t compile for amd64. So… the official package do not support Kerberos and the mesh is full. I need krb support for svn because of my job, but… 🙁 …must use Debian…