Code Reviews are common in software development. One programmer reviews another’s code to find potential issues or to see if the developer could have used something that the system already provided.
With multiple programmers, you can probably expect a versioning system, perhaps a centralized versioning system like SVN or Perforce. With that system, each programmer would make his/her changes and then would check in his/her changes into the repository. From there, the programmer’s peers would review the code.
What’s the problem with this system? The code is already checked in. The pressure is on the peers to ensure that the code is good, and it’s likely that this could slip through the cracks. I mean, those peers are working on getting 10 features complete themselves.
Enter Git
Well, I would argue that Git has a strong code review process built right in. This is due to the process of how distributed version control works.
Read the rest of this entry »
So not only is git useful for the small projects, it’s also good for keeping track of todos and issues. Ticgit is a distributed ticketing systems based on git. It provides a command line interface as well as a web interface via sinatra and stores all of the ticket info in a separate branch, called ticgit. Rather clever I think.
Read the rest of this entry »
We know that when you are working with a bunch of developers for code that’s going to be deployed to the world that version control is something that you want in your toolbox. I would like to submit that it’s not the only reason to use source control.
I bought a Flex book to, well, teach myself Flex. The book right now is taking me though one application and is building it out piece by piece. So I began to think: “What if I just keep track of all my changes through git?”
For one, Flex is nice because it’s all XML, so that makes revision tracking fairly easy. Also, git is very easy to get started because you don’t have to do any server setup. Just issue a git init command and get going. Then after each chapter, I can tag the repository for posterity’s sake. And I have to say, it’s been great to see how the code has changes, especially since Flex Builder generates code.
That’s one thing I love about git, and mercurial, it’s so easy to start using version control for even the littlest of tasks.
I got this tip from Jerry Jackson who told me about storing all of my configuration files, like .bash_profile or .vimrc, in an etc directory inside of my home directory. Once the files are in that directory, you could create a subversion repository; and inside of this repository, put the etc directory in that. Once the files are in a repository, you can check out that repository on any machine. Now you have a way to keep all of your config files easily in sync.
Read the rest of this entry »
First and foremost, this blog is for me. It’s kind of a collection of things that I’m learning and want to learn. So for me, I’m going to start with the basics of SVN
I first used CVS and it does it’s job. There are somethings I wish that were easier. That’s where SVN comes in. A lot of the commands are the same. svn add or svn commit is not that much different from that of cvs add or cvs commit, unless you get to some of the other features.
Read the rest of this entry »