On Sun, May 2, 2010 at 1:36 PM, eviljoel <[email protected]> wrote:
> Hello,
>
> Actually, this is the best reason I've heard to move to git over hg
> yet:  The effect it might have on other projects.

tl;dr version: if you can stick with svn, then both git and hg are
well supported with bidirectional support.  If you move to git,
there's a popular way to have bidirectional support in hg.  If you
move to hg, you basically need to use hg.

Going from Ryan's criticisms of SVN
(http://lists.libsdl.org/pipermail/sdl-libsdl.org/2010-February/075191.html),
both git and hg meet these:
* SVN keeps a backup of the latest version, but not the entire
history.  You cannot commit off the network.
* No bisect in SVN
* Push/pull on a LAN
* Anyone can create branches
* Much more compact repository (git's history of all ioquake3 commits is 15MB).
* Distributed backups by all users
* No need to fork
* Better tools (see bisect)
* No .svn directories scattered about
* End users won't see a difference

If you stick with SVN, both git and hg clients can have bidirectional
support with git-svn and hgsubversion respectively.  The ioquake3 tree
is very linear (only 2 branches) and follows the standard
trunk/branches/tags layout which apparently hgsubversion requires.
What you're losing is that it's slower for the initial pull and git/hg
branches are probably more than SVN can handle.  You can eliminate the
slow init by having a mirror on github and something for hg too.  It's
probably more work for you to integrate git/hg changes in their native
branches back to subversion.

If you move to git, git users are happy.  Hg users can use a 3rd party
tool hg-git to get bidirectional support (from Debian's package):

"The Hg-Git plugin for Mercurial adds the ability to push and pull to/from
 a Git server repository. This means you can collaborate on Git based
 projects from Mercurial, or use a Git server as a collaboration point
 for a team with developers using both Git and Mercurial.
 .
 The plugin can convert commits/changesets losslessly from one system to
 another, so you can push via a Mercurial repository and another
 Mercurial client can pull it and their changeset node ids will be
 identical - Mercurial data does not get lost in translation."

Note that the author of the tool says it's still beta but feature
complete/stable.  http://hg-git.github.com/

If you move to hg, Hg users are happy.  I haven't seen a bidirectional
tool for interacting with hg servers from git.  It does look like it's
possible to use hg-git in order to create a .git directory.  You can
make commits in git but you have to convert them to hg commits and
then push them using hg.
http://mercurial.selenic.com/wiki/HgGit#Using_hg-git_to_interact_with_a_hg_repository_with_git

If there was a bidirectional tool, I would expect it to be listed
here: 
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#Mercurial

FYI I'm not a mercurial user so I'm going by their wiki/documentation.
_______________________________________________
ioquake3 mailing list
[email protected]
http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org
By sending this message I agree to love ioquake3 and libsdl.

Reply via email to