Re: PostgreSQL 8.4 development plan
От | Mark Mielke |
---|---|
Тема | Re: PostgreSQL 8.4 development plan |
Дата | |
Msg-id | 47AB4CFC.2020001@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: PostgreSQL 8.4 development plan (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PostgreSQL 8.4 development plan
|
Список | pgsql-hackers |
Tom Lane wrote:<br /><blockquote cite="mid:7430.1202408095@sss.pgh.pa.us" type="cite"><blockquote type="cite"><blockquotetype="cite"><pre wrap="">From a relative time to install from source standpoint it looks like this: CVS - 10 minutes (no external dependencies) GIT - 8 minutes (no external dependencies) Mercurial - 1 minute (depends on Python) Subversion - 4-6 hours (depends on a multitude of packages and will only work with specific versionswhich you learn about the hard way at build time). </pre></blockquote></blockquote><prewrap=""> For those on platforms where SVN comes prepackaged, this might not be a big problem (except maybe for pulling in packages they don't want). For other developers this kind of thing could be a showstopper</pre></blockquote><br /> As with anything you are likely tosee on this issue, the above seems highly suspect as hard numbers. In my own case I believe installing Subversion is inthe 10 minute time frame as well unless you get into linking it with Apache and such which becomes unfair. Setting up anyof these solutions to be securely accessible from the network takes longer than 10 minutes, so the numbers listed canonly be for local installs, and not all systems have Python. I think think Solaris 8 does?<br /><br /> In terms of pickingan SCM candidate, I don't think "time to install from source" is a legitimate concern. Installing from source is great,but if the package needs to be installed from source, it is not well enough supported by the community to be worthusing.<br /><br /> Cheers,<br /> mark<br /><br /><br /><pre class="moz-signature" cols="72">-- Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a> </pre>
В списке pgsql-hackers по дате отправления: