Обсуждение: publishing changelogs on pgweb
Hi, This was proposed over a year ago, here http://archives.postgresql.org/message-id/25050.1184164913%40sss.pgh.pa.us Any thoughts on how could we do it? Maybe a hook on the anoncvs auto-update thing, that regenerated a set of static files? Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Alvaro Herrera wrote: > >> Hmm, do we include the cvs2cl-generated ChangeLog in the tarballs? > > > No, we don't. We used to but the file got too large. Perhaps we should > > supply a URL that generates that information. > > There are a couple of different queries that people would be interested > in: > > * the full cvs2cl log between any two release points; > * the cvs2cl log from latest release to branch tip. > > I do not think it's appropriate to stick this into the tarballs, as > there's an awful lot of noise in the logs (eg, docs tweaks, reverted > patches, trivial code cleanups); our practice of generating a condensed > release-notes page is a large public service in my eyes. But +1 to > providing a web page from which the detailed answers could be generated > easily. > > BTW, cvs2cl (at least the version I use) works fine against a remote > repository, so it's not like Ray couldn't have gotten the answer for > himself. But a web page would be more user-friendly. > > regards, tom lane -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Seems doable, at least in theory :) I've actually been toying with this a bit earlier, trying to get a summary of the CVS log messages into a database. That could be used to genereate pretty much anything. I ended up using the git repository instead, because it was easier - but given that it appears to be fairly fragile, I don't think that'd be a good idea in a case like this. IIRC, cvs2cl can actually produce XML output, which we could "easily" process and stick in a database, and then from there to the web. Adding this intermediate step would allow us to produce the output in multiple formats - for example, it wouldn't surprise me if people would appreciate an RSS feed... (Again, I've used the git repo for this myself, but that's proven to not be so good) Not sure how to solve the second of Toms points there automatically though - IIRC I hadn't solved the issue of getting the tags in there. I think it's easier to just run it with a cronjob, rather than trying to put more stuff into the commit hooks. We could still use it to trigger a run if the runs appear to be too slow - but I don't think we need anything like 5-minute granularity on the updates (which is the main reason for that commit hook) //Magnus Alvaro Herrera wrote: > Hi, > > This was proposed over a year ago, here > http://archives.postgresql.org/message-id/25050.1184164913%40sss.pgh.pa.us > > Any thoughts on how could we do it? Maybe a hook on the anoncvs > auto-update thing, that regenerated a set of static files? > > > Tom Lane wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> Alvaro Herrera wrote: >>>> Hmm, do we include the cvs2cl-generated ChangeLog in the tarballs? >>> No, we don't. We used to but the file got too large. Perhaps we should >>> supply a URL that generates that information. >> There are a couple of different queries that people would be interested >> in: >> >> * the full cvs2cl log between any two release points; >> * the cvs2cl log from latest release to branch tip. >> >> I do not think it's appropriate to stick this into the tarballs, as >> there's an awful lot of noise in the logs (eg, docs tweaks, reverted >> patches, trivial code cleanups); our practice of generating a condensed >> release-notes page is a large public service in my eyes. But +1 to >> providing a web page from which the detailed answers could be generated >> easily. >> >> BTW, cvs2cl (at least the version I use) works fine against a remote >> repository, so it's not like Ray couldn't have gotten the answer for >> himself. But a web page would be more user-friendly. >> >> regards, tom lane > >
Magnus Hagander wrote: > Seems doable, at least in theory :) I've cleaned up my script a bit and am running some further tests now. It does seem to work pretty well. But: >>> BTW, cvs2cl (at least the version I use) works fine against a remote >>> repository, so it's not like Ray couldn't have gotten the answer for >>> himself. But a web page would be more user-friendly. What version is this? Mine seems to need a local checkout to work at all... //Magnus
Magnus Hagander <magnus@hagander.net> writes:
>>> BTW, cvs2cl (at least the version I use) works fine against a remote
>>> repository, so it's not like Ray couldn't have gotten the answer for
>>> himself. But a web page would be more user-friendly.
> What version is this? Mine seems to need a local checkout to work at all...
Yeah, mine too, but you can certainly make a local checkout if you have
access to the remote repository.
One thing to watch out for is that (at least in the version I use) what
cvs2cl seems to care about is having a local directory structure that
matches the repository. If you use the -P option to prune away local
subdirectories that no longer contain any live files, then cvs2cl won't
find log entries for the files that had been in that subdirectory.
Most of the time this isn't a huge problem, but if you want a complete
history then it's a good idea to make your checkout without -P.
regards, tom lane
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >>>> BTW, cvs2cl (at least the version I use) works fine against a remote >>>> repository, so it's not like Ray couldn't have gotten the answer for >>>> himself. But a web page would be more user-friendly. > >> What version is this? Mine seems to need a local checkout to work at all... > > Yeah, mine too, but you can certainly make a local checkout if you have > access to the remote repository. Ah, misunderstanding.. > One thing to watch out for is that (at least in the version I use) what > cvs2cl seems to care about is having a local directory structure that > matches the repository. If you use the -P option to prune away local > subdirectories that no longer contain any live files, then cvs2cl won't > find log entries for the files that had been in that subdirectory. > Most of the time this isn't a huge problem, but if you want a complete > history then it's a good idea to make your checkout without -P. Good point, will be sure not to do that... //Magnus