[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