{"thread":{"id":"19064","subject":"Google Code: Support for Mercurial and Analysis of Git and Mercurial","startedAt":"2009-04-26T05:03:31Z","lastAt":"2009-04-30T00:00:56Z","messageCount":26,"participants":["Christian Couder","Paolo Ciarrocchi","Johannes Schindelin","Jakub Narebski","Michael Witten","Matthias Andree","Miles Bader","James Cloos","A Large Angry SCM","Alex Blewitt","Shawn O. Pearce","Mark Lodato"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"112329","messageId":"200904260703.31243.chriscool@tuxfamily.org","threadId":"19064","inReplyTo":null,"subject":"Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Christian Couder","fromEmail":"chriscool@tuxfamily.org","sentAt":"2009-04-26T05:03:31Z","receivedAt":"2009-04-26T05:03:31Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nFor information, now Google Code supports Mercurial for project hosting:\n\nhttp://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html\n\nMercurial was choosen over Git because of this (one year old) analysis:\n\nhttp://code.google.com/p/support/wiki/DVCSAnalysis\n\nThere is this article on LWN about the analysis:\n\nhttp://lwn.net/Articles/330138/\n\nRegards,\nChristian.\n"},{"id":"112341","messageId":"b4087cc50904260012y6620718dqf59766463f9d519@mail.gmail.com","threadId":"19064","inReplyTo":"200904260703.31243.chriscool@tuxfamily.org","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-26T07:12:15Z","receivedAt":"2009-04-26T07:12:15Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Apr 26, 2009 at 00:03, Christian Couder wrote:\n> Hi,\n>\n> For information, now Google Code supports Mercurial [and not git] for project hosting:\n\n>From an 'advocacy' viewpoint, I think this is a major blow to git.\n"},{"id":"112343","messageId":"m363grq13i.fsf@localhost.localdomain","threadId":"19064","inReplyTo":"200904260703.31243.chriscool@tuxfamily.org","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-04-26T08:16:16Z","receivedAt":"2009-04-26T08:16:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Christian Couder writes:\n\n> For information, now Google Code supports Mercurial for project hosting:\n> \n> http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html\n> \n> Mercurial was choosen over Git because of this (one year old) analysis:\n> \n> http://code.google.com/p/support/wiki/DVCSAnalysis\n> \n> There is this article on LWN about the analysis:\n> \n> http://lwn.net/Articles/330138/\n\nIt is a pity that the choice was based on year old analysis. One year\nfor actively developed and fast moving targets such like Git and\nMercurial is ages in terms of development history. But I guess this\nis unavoidable.\n\nFor example periodic \"maintenance\" (garbage collecting) is nowadays\nquite automatic in git, with fetching into pack, periodic repacking if\nnumber of loose objects is above tthreshold, and \"git gc --auto\".\n\nWhether Mercurial or Git has better UI and better documentation is\nIMHO a matter of debate. Git documentation is much better that it\nwas, with \"Git User's Manual\" and \"Git Community Book\"; UI also is\nbeing improved.\n\nI can't comment on MS Windows support, but AFAIK Mercurial has better\nsupport here than Git.\n\n\nThe deciding feature (well, one of deciding features) was the fact\nthat Mercurial has better HTTP support... I guess (it was not obvious\nfrom the analysis, but it was hinted at) that Mercurial uses its\ncustom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\nin Git.\n\nPerhaps it is time to restart work on _\"smart\" HTTP protocol_?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"112340","messageId":"4d8e3fd30904260123r35b6a348uab3ad22fde9daa3f@mail.gmail.com","threadId":"19064","inReplyTo":"m363grq13i.fsf@localhost.localdomain","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2009-04-26T08:23:54Z","receivedAt":"2009-04-26T08:23:54Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 4/26/09, Jakub Narebski wrote:\n\n> The deciding feature (well, one of deciding features) was the fact\n> that Mercurial has better HTTP support... I guess (it was not obvious\n> from the analysis, but it was hinted at) that Mercurial uses its\n> custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n> in Git.\n>\n> Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n>\n\n\nwasn't Shawn working on it?\n\nciao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\nhttp://mypage.vodafone.it/\n"},{"id":"112342","messageId":"op.uszlmeoo1e62zd@merlin.emma.line.org","threadId":"19064","inReplyTo":"m363grq13i.fsf@localhost.localdomain","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Matthias Andree","fromEmail":"matthias.andree@gmx.de","sentAt":"2009-04-26T09:21:40Z","receivedAt":"2009-04-26T09:21:40Z","isPatch":false,"sender":{"key":"matthias.andree@gmx.de","avatar":null},"body":"Am 26.04.2009, 10:16 Uhr, schrieb Jakub Narebski :\n\n> I can't comment on MS Windows support, but AFAIK Mercurial has better\n> support here than Git.\n\nI have some experience here, and with exception to the SVN 1.6 breaks \ngit-svn for https:// (probably due to misbehaviour of APR or SVN stuff on \nCygwin), it works flawless on Cygwin 1.5. (SVN 1.5 on Cygwin 1.5 or SVN \n1.6 on Cygwin 1.7 seem to work).\n\nI wonder why people are always pissed at Cygwin - it's quite easy to setup \nand works.\n\nWith Mercurial, I've sometimes found that it's awkward to integrate with \nother tools such as Emacs. It only works if you use the hg.exe approach, \nwhich entails packing the whole module library into the .exe and is \ninefficient. Particularly, it seems slower on start than the native or \nbyte-compiled Python code for many operations. Not benchmarked, just a gut \nfeeling. And I'm talking about a rather swift laptop here, Intel Core Duo \nT2500 (2 x 2 GHz), 2 GB RAM, Win XP SP3.\n\n> The deciding feature (well, one of deciding features) was the fact\n> that Mercurial has better HTTP support... I guess (it was not obvious\n> from the analysis, but it was hinted at) that Mercurial uses its\n> custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n> in Git.\n>\n> Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n\nThat would certainly be useful, but the \"packs\" approach is something that \nmay make this more difficult than for Mercurial. Git+SSH works rather well \nthough.\n\n-- \nMatthias Andree\n"},{"id":"112336","messageId":"alpine.DEB.1.00.0904261206170.10279@pacific.mpi-cbg.de","threadId":"19064","inReplyTo":"4d8e3fd30904260123r35b6a348uab3ad22fde9daa3f@mail.gmail.com","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-26T10:07:01Z","receivedAt":"2009-04-26T10:07:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Apr 2009, Paolo Ciarrocchi wrote:\n\n> On 4/26/09, Jakub Narebski wrote:\n> \n> > The deciding feature (well, one of deciding features) was the fact\n> > that Mercurial has better HTTP support... I guess (it was not obvious\n> > from the analysis, but it was hinted at) that Mercurial uses its\n> > custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n> > in Git.\n> >\n> > Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n> >\n> \n> \n> wasn't Shawn working on it?\n\nGIVE HIM A BREAK!\n\nIsn't Shawn doing enough for Git? No need to offload the stuff on him \n_that you could very well tackle yourself_.\n\nCiao,\nDscho\n"},{"id":"112335","messageId":"200904261209.08108.jnareb@gmail.com","threadId":"19064","inReplyTo":"op.uszlmeoo1e62zd@merlin.emma.line.org","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-04-26T10:09:07Z","receivedAt":"2009-04-26T10:09:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 26 April 2009, Matthias Andree wrote:\n> Am 26.04.2009, 10:16 Uhr, schrieb Jakub Narebski :\n> \n> > I can't comment on MS Windows support, but AFAIK Mercurial has better\n> > support here than Git.\n> \n> I have some experience here, and with exception to the SVN 1.6 breaks \n> git-svn for https:// (probably due to misbehaviour of APR or SVN stuff on \n> Cygwin), it works flawless on Cygwin 1.5. (SVN 1.5 on Cygwin 1.5 or SVN \n> 1.6 on Cygwin 1.7 seem to work).\n> \n> I wonder why people are always pissed at Cygwin - it's quite easy to setup \n> and works.\n\nWell, but you have to install Cygwin (or use MsysGit, which isn't there\nyet). On the other hand you need to install Python for Mercurial...\nbut perhaps it is bundled in Windows install package for Mercurial.\n\nBeside it isn't only about being easy to install and use (and have\ndecent enough performance) given SCM on MS Windows, but also about\ntools such like TortoiseHg and VisualHg (as Windows users are usually\nnot used to using CLI alone). Although also this improves for Git,\nwith TortoiseGit, Git Extensions and git-cheetah. And I think it was\nmuch worse (for Git vs Mercurial) at the time the analysis in question\nwas conducted.\n\n[...]\n> > The deciding feature (well, one of deciding features) was the fact\n> > that Mercurial has better HTTP support... I guess (it was not obvious\n> > from the analysis, but it was hinted at) that Mercurial uses its\n> > custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n> > in Git.\n> >\n> > Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n> \n> That would certainly be useful, but the \"packs\" approach is something that \n> may make this more difficult than for Mercurial. Git+SSH works rather well \n> though.\n\nAs you can find in mailing list archives the design part of \"tunelling\"\npack protocol over HTTP, using git-aware server (for example some CGI\nscript, or simple HTTP server like Mercurial's hg-serve), is done. Even\ntaking into account the fact that HTTP protocol by itself is stateless.\nUnfortunately development itself of \"smart\" HTTP server for Git got\nstalled... if it was present, the conclusion of mentioned analysis might\nhave been different. OTOH perhaps it would be not, as it is my impression\nthat Google Code stuff is either Python or Java...\n\n\nP.S. I wonder what happened to GMane interface... seems stalled.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"112334","messageId":"alpine.DEB.1.00.0904261208000.10279@pacific.mpi-cbg.de","threadId":"19064","inReplyTo":"200904260703.31243.chriscool@tuxfamily.org","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-26T10:13:23Z","receivedAt":"2009-04-26T10:13:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Apr 2009, Christian Couder wrote:\n\n> For information, now Google Code supports Mercurial for project hosting:\n> \n> http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html\n> \n> Mercurial was choosen over Git because of this (one year old) analysis:\n> \n> http://code.google.com/p/support/wiki/DVCSAnalysis\n> \n> There is this article on LWN about the analysis:\n> \n> http://lwn.net/Articles/330138/\n\nFWIW some little bird (yes, related to the Google Code team) told me that \nthe real reason was because a certain person important in Git development \nwas upsetting the Google Code team. It _might_ be related to the fact \nthat the original Googe Code team had a substantial involvement in \nSubversion...\n\nSo, don't believe that the reason Git is not supported by Google Code is a \ntechnical one (just like it was no technical reason at all for Python to \nchoose Hg over Git).\n\nOh, and I have to be very clear on some important point: they are free to \nchoose what they want. I, for one, am happy that not everybody and her \ndog uses Git. That way, we can steal cute ideas from other projects like \nHg or Bazaar.\n\nCiao,\nDscho\n"},{"id":"112333","messageId":"200904261216.58444.jnareb@gmail.com","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261206170.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-04-26T10:16:58Z","receivedAt":"2009-04-26T10:16:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 26 April 2009, Johannes Schindelin wrote:\n> On Sun, 26 Apr 2009, Paolo Ciarrocchi wrote:\n> > On 4/26/09, Jakub Narebski wrote:\n> > \n> > > The deciding feature (well, one of deciding features) was the fact\n> > > that Mercurial has better HTTP support... I guess (it was not obvious\n> > > from the analysis, but it was hinted at) that Mercurial uses its\n> > > custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n> > > in Git.\n> > >\n> > > Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n> > \n> > wasn't Shawn working on it?\n> \n> GIVE HIM A BREAK!\n> \n> Isn't Shawn doing enough for Git? No need to offload the stuff on him \n> _that you could very well tackle yourself_.\n\nIt is a bit pity that we don't have \"smart\" HTTP protocol as one of\ngit projects for this year Google Summer of Code 2009.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"112332","messageId":"alpine.DEB.1.00.0904261217510.10279@pacific.mpi-cbg.de","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261206170.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-26T10:18:41Z","receivedAt":"2009-04-26T10:18:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Apr 2009, Johannes Schindelin wrote:\n\n> On Sun, 26 Apr 2009, Paolo Ciarrocchi wrote:\n> \n> > On 4/26/09, Jakub Narebski wrote:\n> > \n> > > The deciding feature (well, one of deciding features) was the fact\n> > > that Mercurial has better HTTP support... I guess (it was not obvious\n> > > from the analysis, but it was hinted at) that Mercurial uses its\n> > > custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n> > > in Git.\n> > >\n> > > Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n> > >\n> > \n> > \n> > wasn't Shawn working on it?\n> \n> GIVE HIM A BREAK!\n\nSorry. While it reflects exactly what I felt reading your mail, I should \nhave phrased it like this:\n\n\tDon't ask what Shawn can do for you. Ask what you can do for \n\tShawn.\n\nCiao,\nDscho\n"},{"id":"112331","messageId":"4d8e3fd30904260321u46a4b177xe7c96c13836f3490@mail.gmail.com","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261206170.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2009-04-26T10:21:02Z","receivedAt":"2009-04-26T10:21:02Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 4/26/09, Johannes Schindelin wrote:\n> Hi,\n>\n> On Sun, 26 Apr 2009, Paolo Ciarrocchi wrote:\n>\n>> On 4/26/09, Jakub Narebski wrote:\n>>\n>> > The deciding feature (well, one of deciding features) was the fact\n>> > that Mercurial has better HTTP support... I guess (it was not obvious\n>> > from the analysis, but it was hinted at) that Mercurial uses its\n>> > custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n>> > in Git.\n>> >\n>> > Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n>> >\n>>\n>>\n>> wasn't Shawn working on it?\n>\n> GIVE HIM A BREAK!\n\nit was just a question.\n\n> Isn't Shawn doing enough for Git? No need to offload the stuff on him\n> _that you could very well tackle yourself_.\n\n\nshawn is a stellar developer and with my message i didn't want to\nimply that he should do more than what is already doing.\nIt was just a question to better understand the issue.\n\nciao.\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\nhttp://mypage.vodafone.it/\n"},{"id":"112393","messageId":"op.uszscpuf1e62zd@merlin.emma.line.org","threadId":"19064","inReplyTo":"200904261209.08108.jnareb@gmail.com","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Matthias Andree","fromEmail":"matthias.andree@gmx.de","sentAt":"2009-04-26T11:47:03Z","receivedAt":"2009-04-26T11:47:03Z","isPatch":false,"sender":{"key":"matthias.andree@gmx.de","avatar":null},"body":"Am 26.04.2009, 12:09 Uhr, schrieb Jakub Narebski :\n\n> On Sun, 26 April 2009, Matthias Andree wrote:\n>> Am 26.04.2009, 10:16 Uhr, schrieb Jakub Narebski :\n>>\n>> > I can't comment on MS Windows support, but AFAIK Mercurial has better\n>> > support here than Git.\n>>\n>> I have some experience here, and with exception to the SVN 1.6 breaks\n>> git-svn for https:// (probably due to misbehaviour of APR or SVN stuff \n>> on\n>> Cygwin), it works flawless on Cygwin 1.5. (SVN 1.5 on Cygwin 1.5 or SVN\n>> 1.6 on Cygwin 1.7 seem to work).\n>>\n>> I wonder why people are always pissed at Cygwin - it's quite easy to \n>> setup and works.\n>\n> Well, but you have to install Cygwin (or use MsysGit, which isn't there\n> yet). On the other hand you need to install Python for Mercurial...\n> but perhaps it is bundled in Windows install package for Mercurial.\n\nAFAIR Mercurial is compiled through py2exe, but I'd have to look again \nwhat that actually means WRT Python installations.\n\n> Beside it isn't only about being easy to install and use (and have\n> decent enough performance) given SCM on MS Windows, but also about\n> tools such like TortoiseHg and VisualHg (as Windows users are usually\n> not used to using CLI alone). Although also this improves for Git,\n> with TortoiseGit, Git Extensions and git-cheetah. And I think it was\n> much worse (for Git vs Mercurial) at the time the analysis in question\n> was conducted.\n\nI wonder why people always talk about \"not being used to console\" or \nwhatever. These captive GUIs serialize work and tend to get in the way. It \nmay be different for beasts like Eclipse, but I haven't tried the latter.\n\nI have yet to see any TortoiseCrap that does not smell. Judging from \nTortoise{CVS,SVN,Hg}, they are feature-limited, cumbersome-to-use \nfrontends where a command line client would be much faster. However you \ncan't mix Unix versions of SCM exes and Tortoise-compiled exes easily due \nto differing [CR-]LF conventions.\n\nI've done away with all that TortoiseCrap and use SCM from the command \nline.\n\nI acknowledge that code browsing as in gitk or git-gui is more concise \nthan a shell at times, but that doesn't warrant Tortoise* Explorer \nextension stuff which only wraps the trivial operations anyhow.\n\nMy opinion is that if people can't be bothered to learn the few SCM \ncommands, they won't fully understand what Tortoises creep to do, and then \nthey shouldn't be let anywhere near any kind of shell - graphical or text \nconsole - anyways.\n\n> As you can find in mailing list archives the design part of \"tunelling\"\n> pack protocol over HTTP, using git-aware server (for example some CGI\n> script, or simple HTTP server like Mercurial's hg-serve), is done. Even\n> taking into account the fact that HTTP protocol by itself is stateless.\n> Unfortunately development itself of \"smart\" HTTP server for Git got\n> stalled... if it was present, the conclusion of mentioned analysis might\n> have been different. OTOH perhaps it would be not, as it is my \n> impression that Google Code stuff is either Python or Java...\n\nI don't care much about Google anything, to be frank.\n\n> P.S. I wonder what happened to GMane interface... seems stalled.\n\nWhat's so difficult about mailing \"subscribe git MY@ADDRE.SS.example\" to \nmajordomo at vger dot kernel dot org?\n\n-- \nMatthias Andree\n"},{"id":"112391","messageId":"loom.20090426T120010-583@post.gmane.org","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261217510.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Alex Blewitt","fromEmail":"alex.blewitt@gmail.com","sentAt":"2009-04-26T12:02:28Z","receivedAt":"2009-04-26T12:02:28Z","isPatch":false,"sender":{"key":"alex.blewitt@gmail.com","avatar":"https://gravatar.com/avatar/fb95a3b593b290f03a8d3b022c20b2825205702c5651f731f65d33512dfe6ab2?d=mp&s=160"},"body":"Johannes Schindelin gmx.de> writes:\n\n> \n> Hi,\n> \n> On Sun, 26 Apr 2009, Johannes Schindelin wrote:\n> \n> > On Sun, 26 Apr 2009, Paolo Ciarrocchi wrote:\n> > \n> > > On 4/26/09, Jakub Narebski gmail.com> wrote:\n> > > \n> > > > Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n> > > >\n> > > \n> > > \n> > > wasn't Shawn working on it?\n> > \n> > GIVE HIM A BREAK!\n> \n> Sorry. While it reflects exactly what I felt reading your mail, I should \n> have phrased it like this:\n> \n> \tDon't ask what Shawn can do for you. Ask what you can do for \n> \tShawn.\n\nIt's something I raised a while ago with the eclipse.egit discussion; I'm happy\nto step forward and see what I can do to improve the HTTP access, since I \nthink that's critical for adoption in organizations who, through no fault of \nthe end user, are either not directly connected to the internet or have to go \nvia HTTP proxies due to firewall limitations.\n\nAlex\n"},{"id":"112385","messageId":"49F475B8.20903@gmail.com","threadId":"19064","inReplyTo":"m363grq13i.fsf@localhost.localdomain","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-04-26T14:54:48Z","receivedAt":"2009-04-26T14:54:48Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> Christian Couder writes:\n> \n>> For information, now Google Code supports Mercurial for project hosting:\n>>\n>> http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html\n>>\n>> Mercurial was choosen over Git because of this (one year old) analysis:\n>>\n>> http://code.google.com/p/support/wiki/DVCSAnalysis\n>>\n>> There is this article on LWN about the analysis:\n>>\n>> http://lwn.net/Articles/330138/\n> \n> It is a pity that the choice was based on year old analysis. One year\n> for actively developed and fast moving targets such like Git and\n> Mercurial is ages in terms of development history. But I guess this\n> is unavoidable.\n> \n> For example periodic \"maintenance\" (garbage collecting) is nowadays\n> quite automatic in git, with fetching into pack, periodic repacking if\n> number of loose objects is above tthreshold, and \"git gc --auto\".\n> \n> Whether Mercurial or Git has better UI and better documentation is\n> IMHO a matter of debate. Git documentation is much better that it\n> was, with \"Git User's Manual\" and \"Git Community Book\"; UI also is\n> being improved.\n> \n> I can't comment on MS Windows support, but AFAIK Mercurial has better\n> support here than Git.\n> \n> \n> The deciding feature (well, one of deciding features) was the fact\n> that Mercurial has better HTTP support... I guess (it was not obvious\n> from the analysis, but it was hinted at) that Mercurial uses its\n> custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n> in Git.\n> \n> Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n> \n\nAnother important criteria was which, both or neither of Git and Hg \nwould actually work and perform well on top of Google Code's underling \nstorage system and except to mention they would be using Bigtable, the \nreport did not discuss this. Git on top of Bigtable will not perform well.\n\nRead the paper and do the math if you are interested.\n\n\thttp://labs.google.com/papers/bigtable-osdi06.pdf\n"},{"id":"112383","messageId":"b4087cc50904260945g161fb95dk2cba781e83136ce1@mail.gmail.com","threadId":"19064","inReplyTo":"49F475B8.20903@gmail.com","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-26T16:45:53Z","receivedAt":"2009-04-26T16:45:53Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Apr 26, 2009 at 09:54, A Large Angry SCM wrote:\n> Another important criteria was which, both or neither of Git and Hg would\n> actually work and perform well on top of Google Code's underling storage\n> system and except to mention they would be using Bigtable, the report did\n> not discuss this. Git on top of Bigtable will not perform well.\n>\n> Read the paper and do the math if you are interested.\n>\n>        http://labs.google.com/papers/bigtable-osdi06.pdf\n>\n\nIf the math is so simple, then surely you could have supplied a quick\noverview of the problem. Nobody likes \"this is left as an exercise for\nthe reader\".\n"},{"id":"112382","messageId":"b4087cc50904260947n394d9c89nf0e821b0504091c5@mail.gmail.com","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261208000.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2009-04-26T16:47:19Z","receivedAt":"2009-04-26T16:47:19Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Sun, Apr 26, 2009 at 05:13, Johannes Schindelin\n wrote:\n> So, don't believe that the reason Git is not supported by Google Code is a\n> technical one (just like it was no technical reason at all for Python to\n> choose Hg over Git).\n\nFrankly, I think that it can be considered technical for Python\ndevelopers to choose an SCM written in Python. I can't fault them for\nthat.\n"},{"id":"112381","messageId":"alpine.DEB.1.00.0904261854460.10279@pacific.mpi-cbg.de","threadId":"19064","inReplyTo":"49F475B8.20903@gmail.com","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-26T16:56:54Z","receivedAt":"2009-04-26T16:56:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Apr 2009, A Large Angry SCM wrote:\n\n> Another important criteria was which, both or neither of Git and Hg \n> would actually work and perform well on top of Google Code's underling \n> storage system and except to mention they would be using Bigtable, the \n> report did not discuss this. Git on top of Bigtable will not perform \n> well.\n\nActually, did we not arrive at the conclusion that it could perform well \nat least with the filesystem layer on top of big table, but even better if \nthe big tables stored certain chunks (not really all that different from \nthe chunks needed for mirror-sync!)?\n\nBack when I discussed this with a Googler, it was all too obvious that \nthey are not interested (and in the meantime I understand why, see my \nother mail).\n\nCiao,\nDscho\n"},{"id":"112379","messageId":"49F49AF0.1020301@gmail.com","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261854460.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-04-26T17:33:36Z","receivedAt":"2009-04-26T17:33:36Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 26 Apr 2009, A Large Angry SCM wrote:\n> \n>> Another important criteria was which, both or neither of Git and Hg \n>> would actually work and perform well on top of Google Code's underling \n>> storage system and except to mention they would be using Bigtable, the \n>> report did not discuss this. Git on top of Bigtable will not perform \n>> well.\n> \n> Actually, did we not arrive at the conclusion that it could perform well \n> at least with the filesystem layer on top of big table, but even better if \n> the big tables stored certain chunks (not really all that different from \n> the chunks needed for mirror-sync!)?\n> \n> Back when I discussed this with a Googler, it was all too obvious that \n> they are not interested (and in the meantime I understand why, see my \n> other mail).\n> \n\nI don't remember the mirror-sync discussion. But I do remember that when \nthe discussion turned to implementing a filesystem on top of Bigtable \nthat would not cause performance problems for Git, my response was that \nyou'd still be much better off going to GFS directly instead of faking a \nfilesystem on top of Bigtable without all of the Bigtable limitations.\n\nBigtable _is_ appealing to implement the Git object store on. It's too \nbad the latency in Bigtable would make it horribly slow.\n"},{"id":"112376","messageId":"alpine.DEB.1.00.0904261943070.10279@pacific.mpi-cbg.de","threadId":"19064","inReplyTo":"49F49AF0.1020301@gmail.com","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-04-26T17:45:18Z","receivedAt":"2009-04-26T17:45:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 26 Apr 2009, A Large Angry SCM wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Sun, 26 Apr 2009, A Large Angry SCM wrote:\n> > \n> > > Another important criteria was which, both or neither of Git and Hg \n> > > would actually work and perform well on top of Google Code's \n> > > underling storage system and except to mention they would be using \n> > > Bigtable, the report did not discuss this. Git on top of Bigtable \n> > > will not perform well.\n> > \n> > Actually, did we not arrive at the conclusion that it could perform \n> > well at least with the filesystem layer on top of big table, but even \n> > better if the big tables stored certain chunks (not really all that \n> > different from the chunks needed for mirror-sync!)?\n> > \n> > Back when I discussed this with a Googler, it was all too obvious that \n> > they are not interested (and in the meantime I understand why, see my \n> > other mail).\n> \n> I don't remember the mirror-sync discussion. But I do remember that when \n> the discussion turned to implementing a filesystem on top of Bigtable \n> that would not cause performance problems for Git, my response was that \n> you'd still be much better off going to GFS directly instead of faking a \n> filesystem on top of Bigtable without all of the Bigtable limitations.\n\nUmm, GFS is built on top of Bigtable, no?\n\n> Bigtable _is_ appealing to implement the Git object store on. It's too \n> bad the latency in Bigtable would make it horribly slow.\n\nIf you store one object per Bigtable, yes. If you store a few undelta'd \nobjects there, and then use the pack run to optimize those tables, I think \nit would not be horribly slow. Of course, you'd need to do exactly the \nsame optimizations necessary for mirror-sync, but I might have mentioned \nthat already ;-)\n\nCiao,\nDscho\n"},{"id":"112374","messageId":"49F4A138.6040808@gmail.com","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261943070.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-04-26T18:00:24Z","receivedAt":"2009-04-26T18:00:24Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 26 Apr 2009, A Large Angry SCM wrote:\n> \n>> Johannes Schindelin wrote:\n>>\n>>> On Sun, 26 Apr 2009, A Large Angry SCM wrote:\n>>>\n>>>> Another important criteria was which, both or neither of Git and Hg \n>>>> would actually work and perform well on top of Google Code's \n>>>> underling storage system and except to mention they would be using \n>>>> Bigtable, the report did not discuss this. Git on top of Bigtable \n>>>> will not perform well.\n>>> Actually, did we not arrive at the conclusion that it could perform \n>>> well at least with the filesystem layer on top of big table, but even \n>>> better if the big tables stored certain chunks (not really all that \n>>> different from the chunks needed for mirror-sync!)?\n>>>\n>>> Back when I discussed this with a Googler, it was all too obvious that \n>>> they are not interested (and in the meantime I understand why, see my \n>>> other mail).\n>> I don't remember the mirror-sync discussion. But I do remember that when \n>> the discussion turned to implementing a filesystem on top of Bigtable \n>> that would not cause performance problems for Git, my response was that \n>> you'd still be much better off going to GFS directly instead of faking a \n>> filesystem on top of Bigtable without all of the Bigtable limitations.\n> \n> Umm, GFS is built on top of Bigtable, no?\n\nOther way around.\n\n>> Bigtable _is_ appealing to implement the Git object store on. It's too \n>> bad the latency in Bigtable would make it horribly slow.\n> \n> If you store one object per Bigtable, yes. If you store a few undelta'd \n> objects there, and then use the pack run to optimize those tables, I think \n> it would not be horribly slow. Of course, you'd need to do exactly the \n> same optimizations necessary for mirror-sync, but I might have mentioned \n> that already ;-)\n\nBut now you have to find where you stored those \"few undelta'd objects\" \nand then go get the object you're interested in. The only way you can \nwin with that scheme is if you can find groups of objects that are \n(almost) always accessed together, for all objects (and still not get \ntripped up by the other limitations of Bigtable).\n\nOne method would be to group all of the commit objects into one BT entry \nand then create a BT entry for each commit that contains all the trees \nand blobs. This may be fast enough for some operations but would cause \nthe storage requirements to explode.\n"},{"id":"112370","messageId":"m3mya3b5qw.fsf@lugabout.jhcloos.org","threadId":"19064","inReplyTo":"m363grq13i.fsf@localhost.localdomain","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2009-04-26T18:59:27Z","receivedAt":"2009-04-26T18:59:27Z","isPatch":false,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Jakub\" == Jakub Narebski writes:\n\nJakub> Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n\nI had put together some ideas for how that could work, but didn’t post\nthem because it looked like smarter http transport was fait accompli.\n\nThe general idea was to use an http server as a proxy for git-daemon.\nSites running git-daemon could put up such a proxy which will only\naccept proxy attempts to their own daemon, and sites or users behind\nrestrictive firewalls (or http proxies) could set up such a proxy which\nrequires http-level authentication but then will proxy for any git-daemon.\n\nIIRC, I intended to suggest the name post_proxy for the config files.\nOne could add a post_proxy to a repo (for the former style) or in their\nglobal config (for the latter style). Either way, an http_proxy could\nstill be used, if necessary, to access the post_proxy.\n\nAny stream the client would send to a remote git-daemon would be\nencapsulted and sent via an HTTP POST to the post_proxy, which would\nuse the git protocol to send it to the specified git-daemon. Any\nreply back from the git-daemon would be sent to the client as the reply\nto the POST.\n\nThe proxy can be readilly written as a CGI, as a mod_lang extension (for\none’s favourite lang), as a standalone server, or as an extension to\nprojects such as gitweb or cgit.\n\nI never got past the rough design phase because, when I was preparing to\npost the idea, it looked like alternate code was already written....\n\nIs there any interest in this?\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"112366","messageId":"200904262157.39450.jnareb@gmail.com","threadId":"19064","inReplyTo":"200904261209.08108.jnareb@gmail.com","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-04-26T19:57:36Z","receivedAt":"2009-04-26T19:57:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 26 April 2009, Jakub Narebski wrote:\n> On Sun, 26 April 2009, Matthias Andree wrote:\n> > Am 26.04.2009, 10:16 Uhr, schrieb Jakub Narebski :\n\n> [...]\n> > > The deciding feature (well, one of deciding features) was the fact\n> > > that Mercurial has better HTTP support... I guess (it was not obvious\n> > > from the analysis, but it was hinted at) that Mercurial uses its\n> > > custom protocol over HTTP, as opposed to \"dumb\" HTTP protocol support\n> > > in Git.\n> > >\n> > > Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n> > \n> > That would certainly be useful, but the \"packs\" approach is something that \n> > may make this more difficult than for Mercurial. Git+SSH works rather well \n> > though.\n> \n> As you can find in mailing list archives the design part of \"tunelling\"\n> pack protocol over HTTP, using git-aware server (for example some CGI\n> script, or simple HTTP server like Mercurial's hg-serve), is done.\n[...]\n\nSee thread named \"More on git over HTTP POST\" and its predecessor\n\n http://permalink.gmane.org/gmane.comp.version-control.git/91196\n http://thread.gmane.org/gmane.comp.version-control.git/91104/focus=91196\n\n-- \nJakub Narebski\nPoland\n"},{"id":"112357","messageId":"87tz4bgik2.fsf@catnip.gol.com","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261208000.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2009-04-26T22:24:13Z","receivedAt":"2009-04-26T22:24:13Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n> So, don't believe that the reason Git is not supported by Google Code is a \n> technical one (just like it was no technical reason at all for Python to \n> choose Hg over Git).\n\nI look at it this way: having added another VCS to the previously\nsubversion-only google-code, they've probably generalized parts of their\nframework in a way that should make it much easier to add git support in\nthe future!\n\nMaybe it's time to file another git support request at google code...\n\n:-)\n\n-Miles\n\n-- \nPatience, n. A minor form of despair, disguised as a virtue.\n"},{"id":"112460","messageId":"20090427203133.GG23604@spearce.org","threadId":"19064","inReplyTo":"loom.20090426T120010-583@post.gmane.org","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-04-27T20:31:33Z","receivedAt":"2009-04-27T20:31:33Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Blewitt wrote:\n> Johannes Schindelin gmx.de> writes:\n> > On Sun, 26 Apr 2009, Johannes Schindelin wrote:\n> > > On Sun, 26 Apr 2009, Paolo Ciarrocchi wrote:\n> > > > On 4/26/09, Jakub Narebski gmail.com> wrote:\n> > > > \n> > > > > Perhaps it is time to restart work on _\"smart\" HTTP protocol_?\n> > > > \n> > > > wasn't Shawn working on it?\n\nErrh, uhm, yes, I had planned to work on it. I failed to find\nthe time. Gerrit Code Review and the necessary patches to JGit\nhave basically sucked up any time that I have, for anything. Oh,\nand so has \"repo\", the hack^W^W^W^tool Android uses to manage its\nforrest of 140+ Git repositories.\n\n> > > GIVE HIM A BREAK!\n> > \n> > Sorry. While it reflects exactly what I felt reading your mail, I should \n> > have phrased it like this:\n> > \n> > \tDon't ask what Shawn can do for you. Ask what you can do for \n> > \tShawn.\n> \n> It's something I raised a while ago with the eclipse.egit discussion; I'm happy\n> to step forward and see what I can do to improve the HTTP access, since I \n> think that's critical for adoption in organizations who, through no fault of \n> the end user, are either not directly connected to the internet or have to go \n> via HTTP proxies due to firewall limitations.\n\nI'm quite looking forward to this. I'm thrilled to see another\nperson is interested in better HTTP support, and is trying to\nwork on it.\n\n-- \nShawn.\n"},{"id":"112461","messageId":"20090427211502.GI23604@spearce.org","threadId":"19064","inReplyTo":"alpine.DEB.1.00.0904261208000.10279@pacific.mpi-cbg.de","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2009-04-27T21:15:02Z","receivedAt":"2009-04-27T21:15:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Sun, 26 Apr 2009, Christian Couder wrote:\n> \n> > For information, now Google Code supports Mercurial [...]\n> > \n> > Mercurial was choosen over Git because of this (one year old) analysis:\n> > \n> > http://code.google.com/p/support/wiki/DVCSAnalysis\n> \n> FWIW some little bird (yes, related to the Google Code team) told me that \n> the real reason was because [...]\n\nThere were certainly technical factors involved.\n\nAs the DVCSAnalysis document above describes, Hg's relatively\nefficient custom Hg-in-HTTP protocol performs about as well as git://\ndoes, but requires only stateless HTTP, rather than a stateful\ndirect TCP connection.\n\nThere is a fundemental reason why Google App Engine only supports\nincoming HTTP connections on 80/443. Its easy to stand up a new\napplication behind the existing load balancers. Its quite a bit\nmore effort to add support for yet-another-protocol.\n\nAs the recent discussion on eclipse.egit\n\n http://www.eclipse.org/newsportal/article.php?id=34&group=eclipse.egit#34\n\nshowed, many users are stuck behind corporate firewalls where only\nHTTP transit is available.\n\nTossing aside the Google server infrastructure and why HTTP might be\npreferred there, Google also tries to target the widest user base\npossible. Running your VCS through HTTP, which can be easily run\nthrough a corporate proxy, gives a wider user base than running your\nVCS through an SSH tunnel, or a relatively new IANA assigned port.\n\nA long-time GCC committer, and an old SVN committer, pointed out\nto me the other day that the reason why SVN uses HTTP is so it\ncan get around corporate firewalls without involving the IT staff.\nBecause for the past 10 years, being \"on the Internet\" has meant\nbeing \"behind an HTTP and SMTP proxy\". And \"tunneling through HTTP\"\nis somehow safe, no matter how insecure the protocol might be;\nwhile opening an IANA assigned port causes the world to end.\n\nIOW, if Git wants to expand into these user communities where the\nindividual is stuck behind a corporate proxy that only permits HTTP\n\"for security reasons\" (but blindly winds up passing through whatever\nit gets), we need to support a more efficient HTTP protocol.\n\n-- \nShawn.\n"},{"id":"112727","messageId":"ca433830904291700q608f6192i66a83bca9b88b739@mail.gmail.com","threadId":"19064","inReplyTo":"20090427211502.GI23604@spearce.org","subject":"Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2009-04-30T00:00:56Z","receivedAt":"2009-04-30T00:00:56Z","isPatch":false,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"On Mon, Apr 27, 2009 at 5:15 PM, Shawn O. Pearce wrote:\n> IOW, if Git wants to expand into these user communities where the\n> individual is stuck behind a corporate proxy that only permits HTTP\n> \"for security reasons\" (but blindly winds up passing through whatever\n> it gets), we need to support a more efficient HTTP protocol.\n\nAnother advantage of supporting HTTP is allowing HTTPS. SSL can take\nadvantage of an existing PKI infrastructure, either the Internet's\nexisting server-side certificate system, or a corporate server- and\npossibly client-side PKI infrastructure.\n\n--\nMark\n"}]}