Hello Simon, On 2013-08-20 at 08:48:26 +0200, Simon Peyton-Jones wrote:
Thanks. Some quick questions
1. What's the difference between ghc.haskell.org and git.haskell.org?
ghc.haskell.org *currently* points to the same IP address as git.haskell.org, so it makes only a difference for services which use the hostname to differentiate the namespace. This is currently only done for the http:// protocol. For git:// and ssh:// it doesn't make any significant difference (currently). However, in order to facilitate future migrations, git.haskell.org should be used, as then we could relocate git.haskell.org to a different IP without needing to update the URLs in all documents again.
2. Is there anything to choose between these two? ./sync-all -r git://git.haskell.org remote set-url origin ./sync-all -r http://git.haskell.org remote set-url origin
git:// uses port 9418 which may sometimes may be blocked by firewalls. Otoh, plain http:// gets through corporate firewalls more easily. (At some point we might even offer https:// if we get SSL certs) git:// is slightly faster than http:// as it doesn't incur the HTTP-protocol overhead & processing latency. It's basically the raw "Git" protocol over a plain TCP connection. http:// currently uses the same Apache process as is used for serving http://darcs.haskell.org and http://ghc.haskell.org; so if Apache becomes non-responsive or dies, so does the http://git.haskell.org service. The ssh:// and git:// services however, being independent processes, would continue to work (if only Apache was affected). Also, git:// is currently set up in such a way, that it gets restarted automatically if the git-daemon process dies. So git:// is the high-availability option here. Does this answer your question? :-)
3. The repositories page http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Repositories says "this page has been replaced by "Repositories" but the link is circular.. leads to the same page.
4. The Gitolite plan page http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan is very helpful, but is in the nature of a "delta"/change-over plan. Are you planning to replace it (perhaps on "Repositories"?) with instructions for how to use the new setup? I think that would be v helpful for dolts like me.
Yes, we're planning/going to update the Trac documentation to provide more help understanding the new setup. Cheers, hvr