[CMake] Re: Migration to subversion

Joshua Jensen jjensen at workspacewhiz.com
Fri Jan 4 18:38:24 EST 2008


----- 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


More information about the CMake mailing list