2009/4/1 Matthew Toseland <toad at amphibian.dyndns.org>:
> We (Ian, nextgens and I) agreed some time ago that we would try mercurial out.
> There is no consensus on git vs mercurial, however there is a clear, broad
> consensus that either would be better than SVN. This decision ran into a
> series of technical and communications problems, and was severely delayed,
> but will finally be implemented in the near future. The fact that at least
> four people have imported git repositories from SVN should tell us something!
> Therefore, nextgens will in the near future post an email explaining that we
> will do the switch in the very near future, including details of expected
> downtime and how to access the hg repository. The SVN repository will be made
> read-only, and HG will become the official repository.
Replies to some discussion in IRC:
> 02:53 <@toad_> well, we chose hg because 1) much better http transport (good
> for freenet, good for open repo's), 2) better java support, 3) better
> windows support
[...]
> 03:04 <@toad_> well there were some technical issues - the HTTP transport
> isn't very good is a big one, I think re java it's unclear, re windows i'm
> not sure
1] HTTP Support:
http support in freenet is via WebDAV, which is a web standard.
However, if you want to flexible (i.e. _real_ access control), you
should use ssh.
Map the login shell to git-shell (using authorized_keys , or just
edit the user profile).
2] Java support:
Do you means IDE support?
EGit is a eclipse integration.
There are plans to make egit a official eclipse project -- they have
submitted a (draft) proposal to EMO (Eclipse Management Organization)
3] Windows support.
git windows port is not as polish as the unix varient, but it works.
Never mention the egit use a pure java implementation (jgit), which is
platform independent.
Rants asides, there are a few different between git/hg that you may
want to know:
1] bandwidth
git native git:// protocol use much lessor bandwidth with hg,
but i think you are going http:// . or do you?
2] Permissions / Access control
git you need ssh/git-shell or git:// to restrict write
access to specific directory.
the recommended way, however, is splitting the repository
into many smaller repositories.
hg as much as apache .htaccess can do, afaict.
3] Partial Clone ( clone only a sub directory)
git no, split it to smaller repositories.
hg [readonly] preliminary support.
4] Branching
git "light weighted", really fast. allow ant/make only
build the changed files
hg mostly you will clone the repository for a new branch.
there were some plans to change that, but i have no idea.
