Daniel Cheng wrote:
> 2009/4/1 Matthew Toseland <[email protected]>:
>> 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).
> 

No way. We have been there... I really don't miss the delays of when I'm 
sshing in without a valid reverse dns entry. Nor the inability to commit 
(push, whatever you call it) when I'm behind a http-only proxy.

> 2]  Java support:
> 
> Do you means IDE support?
> EGit is a eclipse integration.
> 

I think he meant "like openjdk does". But speaking about IDE, Netbeans 
have native hg support.

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

Arguably we^wI don't care about this one. It's not like we had many or 
even any windows developer.

However I see an argument for choosing a tool which will allow them to 
contribute if they want to.

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

We are going HTTP in any case... And as far as http support is 
concerned, HG is much more efficient than git.

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

We are going to change the model in any case imho. I am not sure we want 
anyone else but the Reviewers to push to the auto-built tree.

We might provide per-dev trees or encourage people to use 
github/bitbucket ...

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

On unix clones are almost free (you can hardlink them if they are on the 
same FS)
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to