Calendar

chromium: updated to 44.0.2403.107. This is a bugfix release which should solve issues for sites that do not properly support https redirection. chromium-widevine-plugin: updated to 44.0.2403.107. Package contains the Widevine Content Decryption Module (CDM) 1.4.8.823, extracted from official Chrome binaries (this package needs chromium of the same version).

chromium: updated to 44.0.2403.89. Note: only the 64-bit package has NaCl (Native Client) support due to the absense of a 32-bit toolchain needed to build NaCl. chromium-widevine-plugin: updated to 44.0.2403.89. Package contains the Widevine Content Decryption Module (CDM) 1.4.8.823, extracted from official Chrome binaries (this package needs chromium of the same version).

This is KDE 5_15.07 for Slackware, consisting of the KDE Frameworks 5.12.0, Plasma 5.3.2 and Applications 15.04.3. Compared to my KDE 5_15.06 no further changes were made apart from the updates to Frameworks, Plasma and Applications. Note: This is meant only to be installed on top of Slackware -current and it will *replace* any version […]

14.1/4.14.3/deps/qt: removed my qt-4.8.6 package (containing some KDE related patches) because now Slackware 14.1 has qt-4.8.7 with those same patches in its official repository. I encourage you to upgrade to that version.

13.37/slackware64-compat32: Refreshed the *compat32 packages. 14.0/slackware64-compat32: Refreshed the *compat32 packages. 14.1/compat32-tools-3.5-noarch-5alien.tgz: In massconvert32.sh, handle the move of cups from a/ to ap/ gracefully if this compat32-tools package is installed on Slackware

Meta

Using git for version control

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.

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.

Share this:

Like this:

Comments

Comment from Ismael CPosted: February 26, 2010 at 17:56

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.

Comment from oldmanPosted: February 26, 2010 at 18:10

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.

Comment from escaflownPosted: February 26, 2010 at 19:56

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.

Comment from escaflownPosted: February 26, 2010 at 20:06

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.

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.

Comment from PoncePosted: February 27, 2010 at 11:00

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 😀

Comment from GrissiomPosted: February 27, 2010 at 12:31

When you get familiar with git, you will know that svn is so lame… Yes, git is beautiful.

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.).

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…