Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rgS0y-0069wm-QW for pgsql-www@arkaria.postgresql.org; Sat, 02 Mar 2024 16:15:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rgS0x-00GhW8-DA for pgsql-www@arkaria.postgresql.org; Sat, 02 Mar 2024 16:15:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rgS0w-00GhVz-Tx for pgsql-www@lists.postgresql.org; Sat, 02 Mar 2024 16:15:07 +0000 Received: from mout-u-204.mailbox.org ([80.241.59.204]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rgS0u-002QjE-9q for pgsql-www@postgresql.org; Sat, 02 Mar 2024 16:15:06 +0000 Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-204.mailbox.org (Postfix) with ESMTPS id 4Tn95x0w4Zz9swL; Sat, 2 Mar 2024 17:15:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ewie.name; s=MBO0001; t=1709396101; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=msnwA6dXgtHpqAEWVsb73S88yroNJUU47UBw9YVr4fg=; b=VlF4BH4t08M9MXVfNfv+V8JQpa7cmO1kyRrhfi0VHXHpDBp/WaAywCVaacKJX/nTeQudsN SweRfy/4mMtokK6Bd119sWLLPSlb8wCmXdCev7AX7kUpMBFcSDx11nMpSuNkbmHRliXsE4 ebecsspK3i+3PXULTOxhK3cmVQsJ/9ny16IRPky/6Yxd0lbvnCFc4KGWW53BKQjY+7Epij yRIrVN4b4HhiAZt/uM6vSj8yu3CMBwTnVlD+aiTXWekv6hcroSZ5H2mghi7NhvmjRyPDnL tBtrgrQkbzI9Uq9DGneacSsCMJR3BH5M2R101faDFu0UNIiUb5nKkF5YF3qvUQ== Date: Sat, 2 Mar 2024 17:14:59 +0100 From: Erik Wienhold To: Marcos Pegoraro Cc: pgsql-www@postgresql.org Subject: Re: Diff of this page with other version Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Tn95x0w4Zz9swL List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2024-03-02 15:35 +0100, Marcos Pegoraro wrote: > I think it is so common to all that it is difficult to see small diffs when > navigating through doc pages of different versions of the same page. I'm > not talking about completely new doc pages, like merge.sgml from version 14 > to 15, but those ones which have small diffs on that file. As an example > consider copy.sgml +1 for the general idea. > Version 16 has this text > NULL 'null_string' > DEFAULT 'default_string' > HEADER [ boolean | MATCH ] > QUOTE 'quote_character' > > But version 15 has this > NULL 'null_string' > HEADER [ boolean | MATCH ] > QUOTE 'quote_character' > > As you can see, the DEFAULT line was added on version 16, but it is not > easy to see what was changed on both versions. > > Another example would be SQL/JSON Path Operators And Methods of func.sgml > of version 16 and devel. There are new methods boolean(), decimal(), > bigint(), timestamp(), timestamptz() and some others but they are not easy > to see that they don't exist in version 16 but would be there when version > 17 comes in. I think that it's relatively easy to add version info to the elements in func.sgml. But only focusing on additions to the docs totally misses changes to the text itself which is sometimes reworded instead of just adding sama paragraphs. > One can say that I have to read release notes before I upgrade a cluster > because that page shows all important features and changes between > versions. But sometimes this is a small info that just shows a better > understanding of that feature or maybe we have several versions running and > have doubts of what small feature exists in what version. > > So, it would be interesting if we could visually see what was changed on > both pages. Then, what I propose is something like you have when using a > diff tool, but in a single page, not side by side. > > An easy way to do that would be add on all changed text a tag like > Here goes changed or new > text > > Obviously when a commit is done the committer has to add this span tag to > that commit, so that part would be colored with green background only if > page 16 is compared with previous ones. The HTML is generated from the SGML docs. So version info has to be added there. Or we use some automated tool to get the diff of the rendered HTML. W3C has a diff tool[1][2] based on GNU diffutils. See [3] for a diff of CREATE TABLE between v15 and v16. > I know we have to put these tags to all files we already have but this can > be done with some regex search tool to do this change to all files. I think you underestimate the effort because the changes are not always as clear (adding one line) as for copy.sgml as you've shown above. For example, if I check create_table.sgml between v15 and v16, I see that the addition of STORAGE modified an existing line. So that regex has to match and wrap just the relevant substring. When new storage modes are added we end up with nested version info in order to compare vXX with pre v16: STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN | FOOBAR | DEFAULT } > So, would this change on all doc pages be relevant ? > If you agree with me than we can think if a tool to convert is needed or > just a search replace is fine. I recommend looking into [2] as a proof-of-concept. [1] https://services.w3.org/htmldiff [2] https://github.com/w3c/htmldiff-ui [2] https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.postgresql.org%2Fdocs%2F15%2Fsql-createtable.html&doc2=https%3A%2F%2Fwww.postgresql.org%2Fdocs%2F16%2Fsql-createtable.html -- Erik