A little bit abot Git

Distributed Nature

Git was designed from the ground up as a distributed version control system.

In a distributed version control software like Git every user has a complete copy of the repository data stored locally (a.k.a a local working copy), thereby making access to file history extremely fast, as well as allowing full functionality and access when disconnected from the network. It also means every user has a complete backup of the repository. If any repository is lost due to system failure only the changes which were unique to that repository are lost. If users frequently push and fetch changes with each other this tends to be an incredibly small amount of loss, if any at all.

In a centralized VCS like Subversion only the central repository has the complete history. This means that users must communicate over the network with the central repository to obtain older versions for a file, Backups must be maintained independently and if the central repository is lost due to system failure it must be restored from backup and all changes since that last backup are likely to be lost. (Depending on the backup policies).

Access Control

Due to being distributed, you inherently do not have to give commit access to other people. Instead, you decide when to merge what from whom.

Branch Handling

Branches in Git are a core concept used everyday by every user. In Subversion they are almost an afterthought and tend to be avoided unless absolutely necessary.

The reason branches are so core in Git is every developer's working directory is itself a branch. Even if two developers are modifying two different unrelated files at the same time it's easy to view these two different working directories as different branches stemming from the same common base revision of the project.

So than Git:

• Automatically tracks the project revision the branch started from.
  • Knowing the starting point of a branch is necessary in order to successfully merge the branch back to the main trunk that it came from.
• Automatically records branch merge events.
  • Merge records always include the following details:
  • Who performed the merge.
  • What branch(es) and revision(s) were merged.
    • All changes made on the branch(es) remain attributed to the original authors and the original timestamps of those changes.
  • What additional changes were made to complete the merge successfully.
    • Any changes made during the merge that is beyond those made on the branch(es) being merged is attributed to the user performing the merge.
  • When the merge was done

  • Why the merge was done (optional; can be supplied by the user).

• Automatically starts the next merge at the last merge.
  • Knowing what revision was last merged is necessary in order to successfully merge the same branches together again in the future.

Performance

Git is extremely fast. Since all operations (except for push and fetch) are local there is no network latency involved to:

• Perform a diff.
• View file history.
• Commit changes.
• Merge branches.
• Obtain any other revision of a file (not just the prior committed revision).
• Switch branches.

Space Requirements

Git's repository and working directory sizes are extremely small when compared to SVN.

Stepping Up: Migrating from an SVN to a Git repository

pull the svn history into a new git repository:

* mkdir project_name.svn
* cd project_name.svn
* git svn init path/to/svn/repo —no-metadata
* echo “svn_username = Real Name ” > users.txt
* git config svn.authorsfile users.txt
* git svn fetch

make an svn-free git repository:

* mkdir project_name.git
* cd project_name.git
* git init
* git remote add origin path/to/git/repo
* git pull project_name.svn
* git push origin master

yippie!

Free SVN/Git Hosting Services

Anyone who is not using any source control of what so ever, please never come back to this blog.
Now, seriously... you have to protect your work and efforts from evil nature (yap, coffee on the MacBook) damaging your precious work.
The conventional way is to get a personal server somewhere and install the source control of your choice on it, and giddie up, but for those of use who are still poor entrepreneurs with no wish what so ever to buy a server somewhere, here are some few options to consider when choosing a source control platform for your application.

Unfuddle - Nice, remindes my of Zoho for some reason . Web 2.0 to the max and packed with project tracking and management such as issue tickets, source control, time tracking, milestones and etc. (but still not a replacement for BaseCamp, but that's for another post), Their free package comes with 250Mb, support for infinite repositories on both Git and Subversion.

Assembla - only a small part of a feature-packed project management service, a basic 200Mb of SVN hosting. the project hosting comes with wiki pages, blogs, etc. The free package has all of this so even if you don’t stump up the $49 p/m for the paid you’ll get one hell of a service.

OpenSVN - One of the first to release free SVN hosting of open source projects and starting to show its age with a very clunky interface and barebones features. free but a trouble maker, i got a lot of 404s and peer resets during commits.

Bounty Source - Bounty Source offer your basic SVN along with a wiki and CMS for managing your projects online presence as well as a task tracker. Bounty Source have a unique feature though that enables a developer to be paid for the work they carry out on user feature requests.

SourceForge - Ya baby, the real deal, an old and great dino indeed. They tried to shot it up with some Web2.0 gradients and curves, but it still looks like Geocities in 1998 :)

Google Project Hosting - someone said gSourceForge? Google shamelessly (as for my opinion) simply took that old dino, and painted it blue :) . its features still lack and it is basically what i call an "executed to finish" job, like "yes, we at google now have a source tracker and such, but we didn't put to much work in it".

i personally moved from OpenSVN to unFuddle a few days ago, and i am very pleased at the moment.

Webistrano - Capistrano deployment the easy way

Blogfish introduced Webistrano, Webistrano is a Web UI for managing Capistrano deployments. It lets you manage projects and their stages like test, production, and staging with different settings. Those stages can then be deployed with Capistrano through Webistrano.



Webistrano's purpose is to make the deployment of multi-stage and multi-environment scenarios easy. Further it allows you to track who deployed what when to which servers and be alerted by email on each deployment.

Webistrano itself is a Ruby on Rails application that includes an edge version of Rails and all needed dependencies like Capistrano or Net::SSH. The only required dependencies are Ruby, Rake, and a database.
Currently the deployment part of Webistrano does not run on Windows.
The code is hosted at Rubyforge and distributed under the BSD license.

Webistrano can be downloaded here