----- Original Message -----
From: James Mansion
Date: 1/4/2008 3:38 PM
> Gonzalo Garramuño wrote:
>> In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*.
>>
> Does git work on Win32?

Pretty well, I've found, using http://code.google.com/p/msysgit/

I've spent the past couple weeks looking (again) heavily into Bazaar, Git, and Mercurial. Let me see if I can recap some of my positive and negative experiences, bearing in mind I'm a Windows user. Let me start by saying they all seem to work reasonably well and are all distributed.

Bazaar:

* Pro: I love the lightweight checkout support from a central repository. For games with gigabytes of assets, storing the history locally for all those assets is often unreasonable. Lightweight checkouts provide a direct connection to the server and work almost exactly like Subversion/Perforce.
* Pro: For a checkout, I can bzr unbind it and commit locally only.  Nice.
* Pro: Bazaar has a smart server built in. I set it up and had it running over an Stunnel client certificate connection in no time. No need to set up an SSH server for pushes! Yeah! * Pro/Con: Branches are directories and can be switched in place or used as a separate tree.
* Con: No authentication for the smart server.  Blech.
* Con: Bazaar for Win32 requires a patch or initial large bzr branch operations fail. Ironically, I got the one line patch from their own bug database. It just isn't integrated yet.
* Con: Initial bzr branches take much longer than Git.
* Con: No visuals during branch, push, or pull operations to show me how the network transfer is going. * Con: Bazaar seems to eat 100% of the CPU time when performing its operations.
* Con: No submodule/subproject support.

Git:

* This one is much different than any other version control system I've used. This may be good or bad. I don't know. My curiosity is piqued enough to fight things like the SSH support. * Pro: When cloning a local repository, you can get the secondary repository to refer to the heavyweight content in the initial repository, thereby saving disk space. * Pro: As far as GUIs go for all 3, QGit is one of the better ones. It still doesn't compare to a complete tool like P4V/P4Win. * Pro: Has submodule support built in now. This means I can put n different repositories in a hierarchy and have it mostly treat the whole tree as one repository. There is still some work to be done here, but it is definitely a big deal.
* Pro: Shows progress on clones.
* Pro/Con: Branches are named and switched in place.
* Pro/Con: Has the ability to create a shallow clone without all the history. Unfortunately, the clone is mostly useless for development. * Con: The local repository clone space savings only applies to local repositories. There is no equivalent of the Bazaar lightweight checkout from the server repository. * Con: Requires an SSH daemon to push data. I just barely got this going (through copSSH) with the replacement git-shell, because I don't want people to have shell access to my machine. Locking down user permissions and directories on a Windows box stinks. I've got to see about setting up the SSH authorized keys. * Con: msysgit doesn't come with git-daemon, but git-daemon is for read-only, pull access anyway.

Mercurial:

* Pro: Seems reasonably fast.
* Pro: Has an access control list extension.
* Pro/Con: Branches are named and switched in place.
* Con: No lightweight clones of repositories.  Unix hardlinks don't count.
* Con: The hgwebdir.cgi was a pain to set up, and it doesn't support client certificates over https. Boo! * Con: I can't figure out how to get the SSH support working. It just hangs, and hg -v --debug is not that helpful.
* Con: The submodule support through the Forest extension feels incomplete.

svk:

* Pro: Has an ultra cool svk sync -s HEAD command that starts your repository from the latest with no back history.

If I sat down with this longer, I'm sure I could really flesh these lists out.

Josh
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to