cvs

CVS Status Like the One in SVN - Bash Script

Yeah, I know - CVS is an archaic mess and there's not a single reason in the entire world to be using it in 2009... except if you are a Drupal contributor and need to maintain a module (or contribute to one) on drupal.org. For reasons that are complicated and don't matter to this blog post, Drupal uses CVS and there's no word that it will switch to something decent like SVN (git users - stay quiet), any time soon.

Fine, but when you actively use a version control, you need to be able to quickly see modified files. Files that need to be added or committed to version control. If you use a GUI CVS client - fine, but I don't. I do most of my development on remote Linux servers and command-line is my only cvs tool. Now that can get tricky in many ways. One of the ways is 'cvs status' command.

For reasons that I will never understand, CVS authors decided to show status of all files when you run this command over a directory. Plus they show 5 lines of information for each file. In the end - you can't see anything, if you are just looking for the names of modified files. Classic case of "less is more" (by the way - fixed in SVN, the improved CVS).

To emulate the behaviour of "svn status" that just shows a list of modified and new files, I wrote a quick bash script that hopefully somebody else, unlucky enough to be stuck with CVS, may find useful, as well:

#!/bin/sh

patterns=( 
	'?' 
	'Locally Added'
	'Locally Modified' 
	)

for i in "${patterns[@]}"
do
  cvs -Q status -R . | grep -i "$i"
done

Linus Torvalds Presents: Git - Truly Distributed SCM

Linus Torvalds recently gave a presentation at Google about a new source-control management (SCM) system he has authored and that is being actively maintained by an open-source community - Git.

If you are a happy user of Subversion, you should take a break right now and watch the video (if you are a "happy" user of CVS, you are hopeless), because it will change and broaden your thinking. Git is not just another version control, it is fundamentally different the way it works.

And it is better! But, how? Ask yourself some questions about your current SCM:

  • Do you commit every day? Should you?
  • Can you commit if you are offline?
  • Do you use branches?
  • Do you look forward to merging branches?
  • Do you need to have guidelines about naming branches/tags?
  • What if your SCM server's disk died?

 

Now imagine that you have a system where none of these questions give you a shiver. That would be Git.

Syndicate content