I was recently in Melbourne attending the cf.Objective() ANZ conference and was hopeful of getting some further setup done on my MacBook Air to make it ready for prime-time development. This will be my third development environment in use, after Ubuntu and Windows 7.
I wanted to jump to distributed version control using Git (a DVCS being essential for offline development) but found that both compiling from source and using MacPorts require a version of the C compiler not installed on my MacBook Air. Worse, the way to get the C compiler was to install Xcode. Xcode, if you didn't know (I didn't), is a hefty 2.9 GB download from Apple containing their development platforms.
Luckily I came across maintained binaries for Git hosted on Google Code, so the XCode install on my limited-space Air is not required. The binaries are working well. Thanks to the maintainers for keeping this out there.
Showing posts with label Git. Show all posts
Showing posts with label Git. Show all posts
Monday, November 22, 2010
Tuesday, February 9, 2010
Book Review: Pragmatic Version Control Using Git
I have not posted a lot on this blog recently so I thought I would add a quick book review. I recently (about a fortnight ago) finished Pragmatic Version Control Using Git by Travis Swicegood, published by the Pragmatic Programmers / Pragmatic Bookshelf.
I come from a Subversion background. In fact, only recently I think I really started to hit my stride with the version control system. But as sometimes happens I was late to the party. An upstart version control system named Git, first popularized as the new version control system for the Linux kernel, is becoming increasingly popular. A key difference between Git and Subversion is that Git is a distributed version control system control. A git repository is designed to be cloned, changes are pulled between repositories and at anyone time multiple developers may be working on their own individual, complete copies of the repositories before refining their commit history and pooling their changes.
So although Git uses many of the same principles I am used to in Subversion, such as branches and tags, it is a fundamentally a different approach to source control, and requires a good book to explain it.
Travis Swicegood's Pragmatic Version Control Using Git has a lot in common with the previously released Pragmatic Version Control Using Subversion. Physically it is exactly the same dimensions in length and breadth and at 224 pages is about 30 pages longer. The pages are thick, high quality acid-free and mostly recycled paper. The print is grey scale and each chapter has a few diagrams or screenshots, but an average of ten or so plain command and output listings.
The first chapter in the book talks about the basic of what version control is and what some of the terminology means. Chapter two talks about how to get Git installed on your system and some configuration you might need to do. Chapter three sets up an example project has a brief overview of all the common actions, like adding files, committing them and creating a release branch. The detail is light, since the topics are covered in later chapters of the book.
Chapters four through nine delves into the details of the common operations you are likely to use in Git: Adding and committing files, using branches, examining the log, working with remote repositories, organisation and repository administration. The focus is on building on the knowledge form chapter three and exploring useful commands and when they might be useful.
Chapters ten and eleven cover migration to Git from other source control versions and you can set up a Git server.
As in Pragmatic Version Control using Subversion, there is a very useful Command Summary and Recipies section as one of the appendices. Long after you have finished the book you might find yourself returning there to get a quick refresher on the keystrokes required for different Git commands you may not commonly use, such as Rebasing.
The book is written in a very conversational style and is consequently very easy to read. There are couple of areas (for example, during the chapter about rebasing) where more detail and discussion would have been helpful in avoiding confusion.
I come from a Subversion background. In fact, only recently I think I really started to hit my stride with the version control system. But as sometimes happens I was late to the party. An upstart version control system named Git, first popularized as the new version control system for the Linux kernel, is becoming increasingly popular. A key difference between Git and Subversion is that Git is a distributed version control system control. A git repository is designed to be cloned, changes are pulled between repositories and at anyone time multiple developers may be working on their own individual, complete copies of the repositories before refining their commit history and pooling their changes.
So although Git uses many of the same principles I am used to in Subversion, such as branches and tags, it is a fundamentally a different approach to source control, and requires a good book to explain it.
Travis Swicegood's Pragmatic Version Control Using Git has a lot in common with the previously released Pragmatic Version Control Using Subversion. Physically it is exactly the same dimensions in length and breadth and at 224 pages is about 30 pages longer. The pages are thick, high quality acid-free and mostly recycled paper. The print is grey scale and each chapter has a few diagrams or screenshots, but an average of ten or so plain command and output listings.
The first chapter in the book talks about the basic of what version control is and what some of the terminology means. Chapter two talks about how to get Git installed on your system and some configuration you might need to do. Chapter three sets up an example project has a brief overview of all the common actions, like adding files, committing them and creating a release branch. The detail is light, since the topics are covered in later chapters of the book.
Chapters four through nine delves into the details of the common operations you are likely to use in Git: Adding and committing files, using branches, examining the log, working with remote repositories, organisation and repository administration. The focus is on building on the knowledge form chapter three and exploring useful commands and when they might be useful.
Chapters ten and eleven cover migration to Git from other source control versions and you can set up a Git server.
As in Pragmatic Version Control using Subversion, there is a very useful Command Summary and Recipies section as one of the appendices. Long after you have finished the book you might find yourself returning there to get a quick refresher on the keystrokes required for different Git commands you may not commonly use, such as Rebasing.
The book is written in a very conversational style and is consequently very easy to read. There are couple of areas (for example, during the chapter about rebasing) where more detail and discussion would have been helpful in avoiding confusion.
In comparison to the Pragmatic Version Control with Subversion book, less time is spent discussing conventions of use. This may in part be because Git codifies some of the conventions of Subversion - for example tags and branching - into actual functionality. It would have been nice however to cover in more depth some of the other issues of convention that arise from having a distributed source control system.
The examples in the book are easy to follow, but they are also a bit simplistic. Each chapter starts with instructions on how to clone the repository required for that chapter from the author's Git hosting site.
Overall I rate the book highly for newcomers committed to using Git. Readers already familiar with Subversion will breeze through the book. Those that are completely new to source control may struggle. Was it worth buying for me? Yes.
Let me know if you have any further questions about the book in the comment area.
Saturday, January 16, 2010
Recent Learning: Git and Picasa
(behind my desk, there are literally piles of technical books, waiting to be read. And like all technical books, they are slowly going off.)
Just last night I finished reading about Git in Pragmatic Version Control Using Git
The other thing I have been doing (and I finished tonight) was going through the Picasa 3.5 training videos on Lynda.com, presented by Dane Howard. My prior experience with Google Picasa has always involved being slightly confused and lacking confidence enough to to use the tool I use to manage my photos. I can safely say this confusion is gone now.
Apart from the whiz-bang features ('easily create a blog post using your photos!'- That explains the photo in this post) some core concepts which I took away from the training that helped me understand Picasa included:
- Photo edits within Picasa are non-desctructive. You can always roll back the edits. This is great because it allows to experiment with the simple but varied tuning and effects that are available.
- Picasa does not 'suck in' photos and store them separately. Each folder in the folder list corresponds to the real file folder that Picasa is watching on your computer. To manage which folders Picasa (and to give Picasa a kick to rescan a folder you have changed from the file system) you can use the Tools > Folder Manager dialog box.
- On the other hand, the import and export operations are designed to work outside the set of folders Picasa is watching. When you import photos, the photos are copied inside one of Picasa's default folders. Export, on the other hand, creates another copy of the files anywhere on the file system. Photos are rescaled according your requirements and the photo edits made within picasa are made permanent for these exported photos only.
- Albums are virtual folders. You use an Album to gather together photos around a particular topic without changing their location on the file system. For example, I created a 'Scenic Photos' album and dragged in what I thought were some scenic photos from my other folders. In my casual use of Picasa prior to the training I missed this whole concept of albums that the you, the user can create and manage.
So I am much happier using Picasa now, and keen to use Git in anger just to see how it work out.
Subscribe to:
Posts (Atom)