Re: PostgreSQL Developer meeting minutes up
От | Magnus Hagander |
---|---|
Тема | Re: PostgreSQL Developer meeting minutes up |
Дата | |
Msg-id | 4A1C006B.8080600@hagander.net обсуждение исходный текст |
Ответ на | Re: PostgreSQL Developer meeting minutes up (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: PostgreSQL Developer meeting minutes up
|
Список | pgsql-hackers |
Andrew Dunstan wrote: > > [moving this onto -hackers, where I think it belongs] > > Tom Lane wrote: >> Huh? The buildfarm will only prove that HEAD of the active branches >> builds. What the concern was was whether we could correctly extract >> past states (particularly, but not solely, the tags corresponding to >> releases) from a converted git repository. The testing I had in mind >> was to check out various tags and diff that tree against actual release >> tarballs. >> >> >> > > It appears that our git repo is only picking up the branch tags (e.g. > REL8_0_STABLE) , not all the release tags (e.g. REL8_0_5) . That needs > to be fixed (if possible). Hmm. I looked through the source of the import script. It appears to mention tags here and there, but doesn't seem to do it. There is a comment that reads: # Previous CVS versions just added the tag to the current HEAD # revision and didn't insert a dead revision on thebranch with # the same date, like it is happening now. # This means history is unclear as we can't reliably determine # if the tagging happened at the same time as the addition to # the branch. For now, just assume it did. # # XXX can't reproduce for now, disabling, as it breaks some # things # Basically, it comes down to cvs tags not being actual first class happening, but just metadata on files. I'm sure we could script the creation of these tags fairly reliably on *our* repository since we know which files are always updated when a tag is added. I'm thinking we could just parse the log for configure.in and grab the tags from there. Thoughts? -- Magnus HaganderSelf: http://www.hagander.net/Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: