Re: Splitting lengthy sgml files

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <ishii(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Splitting lengthy sgml files
Date: 2016-03-08 13:54:28
Message-ID: CA+TgmoZ0m7bDSWrHqc7vGjD1pE7N59FEKmdiO_7JPuO5Y23ceQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 7, 2016 at 10:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
>> There are very lengthy (over 10k lines, for example) SGML files in
>> docs. While working on translating docs using GitHub, I noticed that
>> sometimes diffs are not showed in pull requests due to the limitation
>> of GitHub, which makes me pretty difficult to review PR. Any chance to
>> split those lengthy SGML files into smaller SGML files?
>
> Surely that's a github bug that you should be complaining to them about?

Well I'm sure it's not like they did it for no reason. At some point
displaying a diff on a giant file is going to result in a page that
takes too long to load.

> I'm disinclined to split existing files because (a) it would complicate
> back-patching and (b) it would be completely destructive to git history.
> git claims to understand about file moves but it doesn't do a terribly
> good job with that history-wise (try git log or git blame on
> recently-moved files such as pgbench). And I've never heard even
> a claim that it understands splits.

But we've split very long source files in the past, and I don't see
why splitting doc files is any stupider.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2016-03-08 13:58:22 Re: Allowing to run a buildfarm animal under valgrind
Previous Message Robert Haas 2016-03-08 13:53:09 Re: Relation extension scalability