Обсуждение: Some git conversion issues
Working on the git conversion with keywords, and I've noticed a couple of strange things that don't come up the same way in git. All of these are in non-code files, but they do defeat the "identical tarball" mode. For example, a number of files have commits showing up in cvs with nothing at all changed. This triggered an update of the keywords only, with no contents changed. For example, look at: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_AIX.diff?r1=1.19.2.9;r2=1.19.2.10 http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_HPUX.diff?r1=1.14.2.9;r2=1.14.2.10 http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_Solaris.diff?r1=1.22.2.10;r2=1.22.2.11 Some show up as completely empty, like: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/generate_history.pl.diff?r1=1.1;r2=1.1.2.1 Does anybody know how this can even happen? Wouldn't cvs normally just not commit the file if there are no changes? I'm also seeing some entries tagged with "vendor branch", such as: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/README revision 1.1.1.1 Same issue there, the file comes out on the other end with the wrong keyword (in this case, listed as 1.1). I admit I don't even know what a vendor branch is, except I know I've been annoyed by them before :-) Other than keywords, the contents of every branch and every tag are correct. I haven't checked any arbitrary revisions (that's really hard to do with cvs..), but I have a script that checks every branch and every tag present in configure, configure.in and README (in the root dir), which should hopefully cover everything. Does anybody know a better way to find out all tags and branches that exist, or some other file I should also be looking at? The full list of files having keyword issues due to these two things (AFAICT so far, these are the only issues) are: doc/FAQ_AIX doc/src/sgml/generate_history.pl doc/src/sgml/release-old.sgml src/backend/catalog/README src/backend/nodes/README src/backend/po/es.po src/backend/storage/ipc/README src/backend/storage/smgr/README src/bin/initdb/po/de.po src/bin/initdb/po/fr.po src/bin/pg_config/po/de.po src/bin/pg_config/po/fr.po src/bin/pg_controldata/po/de.po src/bin/pg_controldata/po/es.po src/bin/pg_controldata/po/fr.po src/bin/pg_ctl/po/de.po src/bin/pg_dump/po/de.po src/bin/pg_dump/po/fr.po src/bin/pg_dump/po/sv.po src/bin/pg_resetxlog/po/de.po src/bin/psql/po/de.po src/bin/psql/po/es.po src/bin/psql/po/fr.po src/bin/psql/po/sv.po src/bin/scripts/po/de.po src/bin/scripts/po/fr.po src/interfaces/libpq/po/de.po src/interfaces/libpq/po/fr.po src/interfaces/libpq/po/sv.po Any thoughts or ideas on how to fix these? Or shuld we accept and ignore those differences? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> wrote: > I'm also seeing some entries tagged with "vendor branch", such as: > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/README > revision 1.1.1.1 > > Same issue there, the file comes out on the other end with the > wrong keyword (in this case, listed as 1.1). > > I admit I don't even know what a vendor branch is, except I know > I've been annoyed by them before :-) I believe revision 1.1.1.1 is normally seen only for file brought in through the "cvs import" command. "vendor branch" would make some sense as a commit message for an import. -Kevin
On Tue, Jul 20, 2010 at 15:31, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Magnus Hagander <magnus@hagander.net> wrote: > >> I'm also seeing some entries tagged with "vendor branch", such as: >> > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/smgr/README >> revision 1.1.1.1 >> >> Same issue there, the file comes out on the other end with the >> wrong keyword (in this case, listed as 1.1). >> >> I admit I don't even know what a vendor branch is, except I know >> I've been annoyed by them before :-) > > I believe revision 1.1.1.1 is normally seen only for file brought in > through the "cvs import" command. "vendor branch" would make some > sense as a commit message for an import. Yeah, something like that. But why do we for the file above have one "initial revision" and one "vendor branch", whereas for other files we don't? (and there's no difference betweenthem) Or rather, we do have two for example for md.c - but the second one is not listed as being on vendor branch. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> wrote: >> I believe revision 1.1.1.1 is normally seen only for file brought >> in through the "cvs import" command. "vendor branch" would make >> some sense as a commit message for an import. > > Yeah, something like that. But why do we for the file above have > one "initial revision" and one "vendor branch", whereas for other > files we don't? (and there's no difference between them) Hmmm... I quick check of CVS documentation indicates that 1.1.1 is reserved for the "vendor branch" created by an import. New vendor versions can be imported and will bump 1.1.1.1 to 1.1.1.2 and so on.When you commit a modification to a vendor branch file,it goes onto the trunk. So, either there was something which *looked* like a modification to CVS which got massaged out (whitespace or some such), or someone independently imported the file and someone (possibly a different someone) committed the file independently of the import. I think the latter is probably more likely, but the former seems within the realm of possibility. Where they are identical, unless the imported version is included in any tag or PostgreSQL branch, I would eliminate it and keep the "normal" copy. Short of maintaining a coherent history, I don't see the point of keeping two separate but identical revisions of a file. -Kevin
Magnus Hagander wrote: > Working on the git conversion with keywords, and I've noticed a couple of > strange things that don't come up the same way in git. All of these are in > non-code files, but they do defeat the "identical tarball" mode. > > For example, a number of files have commits showing up in cvs with nothing at > all changed. This triggered an update of the keywords only, with no contents > changed. > > For example, look at: > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_AIX.diff?r1=1.19.2.9;r2=1.19.2.10 > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_HPUX.diff?r1=1.14.2.9;r2=1.14.2.10 > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_Solaris.diff?r1=1.22.2.10;r2=1.22.2.11 > > Some show up as completely empty, like: > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/generate_history.pl.diff?r1=1.1;r2=1.1.2.1 > > > Does anybody know how this can even happen? Wouldn't cvs normally just > not commit the file if there are no changes? I have reproduced this by modifying just the CVS tag: $PostgreSQL: pgsql/src/backend/catalog/README,v 1.15 2010/07/2018:38:53 momjian Exp $ so it is possible, and can be ignored. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
On Tue, Jul 20, 2010 at 20:42, Bruce Momjian <bruce@momjian.us> wrote: > Magnus Hagander wrote: >> Working on the git conversion with keywords, and I've noticed a couple of >> strange things that don't come up the same way in git. All of these are in >> non-code files, but they do defeat the "identical tarball" mode. >> >> For example, a number of files have commits showing up in cvs with nothing at >> all changed. This triggered an update of the keywords only, with no contents >> changed. >> >> For example, look at: >> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_AIX.diff?r1=1.19.2.9;r2=1.19.2.10 >> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_HPUX.diff?r1=1.14.2.9;r2=1.14.2.10 >> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/Attic/FAQ_Solaris.diff?r1=1.22.2.10;r2=1.22.2.11 >> >> Some show up as completely empty, like: >> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/generate_history.pl.diff?r1=1.1;r2=1.1.2.1 >> >> >> Does anybody know how this can even happen? Wouldn't cvs normally just >> not commit the file if there are no changes? > > I have reproduced this by modifying just the CVS tag: > > $PostgreSQL: pgsql/src/backend/catalog/README,v 1.15 2010/07/20 > 18:38:53 momjian Exp $ To clarify with what Bruce said on IM to me, the situation is when the workflow is to manually copy a file from one repo to another before committing (a working one vs the committer one for example), it may not be up to date on the version id. Personally this never happens because I move files by making "cvs diff" in one and applying in the other, not copying the files. For one thing, this showed up in a lot of .po files for 8.1.0RC1. Peter, can you comment on if this coincides with the tools you use to do those things? > so it is possible, and can be ignored. Yeah, but do we want to? It means a git checkout of the branch tip will be slightly different - in keywords only - from the previous checkout in cvs. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > > I have reproduced this by modifying just the CVS tag: > > > > ? ? ? ?$PostgreSQL: pgsql/src/backend/catalog/README,v 1.15 2010/07/20 > > ? ? ? ?18:38:53 momjian Exp $ > > To clarify with what Bruce said on IM to me, the situation is when the > workflow is to manually copy a file from one repo to another before > committing (a working one vs the committer one for example), it may > not be up to date on the version id. Personally this never happens > because I move files by making "cvs diff" in one and applying in the > other, not copying the files. > > For one thing, this showed up in a lot of .po files for 8.1.0RC1. > Peter, can you comment on if this coincides with the tools you use to > do those things? > > > > so it is possible, and can be ignored. > > Yeah, but do we want to? It means a git checkout of the branch tip > will be slightly different - in keywords only - from the previous > checkout in cvs. > Well, we are planning to remove these tags in git anyway, and I don't think anyone cares about those tags not being consistent. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. +
On tis, 2010-07-20 at 20:46 +0200, Magnus Hagander wrote: > For one thing, this showed up in a lot of .po files for 8.1.0RC1. > Peter, can you comment on if this coincides with the tools you use to > do those things? There are/were some games being played with the key words, so this effect sounds plausible to me.
On tis, 2010-07-20 at 15:12 +0200, Magnus Hagander wrote: > Working on the git conversion What's the tool that is being used now? Can you keep us up to date on the options etc. you plan to use?
+On Tue, Jul 20, 2010 at 21:15, Peter Eisentraut <peter_e@gmx.net> wrote: > On tis, 2010-07-20 at 15:12 +0200, Magnus Hagander wrote: >> Working on the git conversion > > What's the tool that is being used now? Can you keep us up to date on > the options etc. you plan to use? I'm currently running tests with a bunch of different tools, to see which looks best. Right now, it looks like cvs2git is best when we want the keywords included. And yes, I'll definitely post the exact options as soon as I've finished the testruns. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/