Some git conversion issues
in [PgSql]
|
Prev: review: psql: edit function, show function commands patch
Next: [HACKERS] Solaris Sparc - dblink regression test failure
From: "Kevin Grittner" on 20 Jul 2010 09:31 Magnus Hagander <magnus(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 20 Jul 2010 09:51 On Tue, Jul 20, 2010 at 15:31, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > Magnus Hagander <magnus(a)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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 20 Jul 2010 10:04 Magnus Hagander <magnus(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 20 Jul 2010 14:42 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 $ so it is possible, and can be ignored. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 20 Jul 2010 14:46
On Tue, Jul 20, 2010 at 20:42, Bruce Momjian <bruce(a)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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |