Re: [HACKERS] Some git conversion issues
+On Tue, Jul 20, 2010 at 21:15, Peter Eisentraut 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some git conversion issues
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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some git conversion issues
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some git conversion issues
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 http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some git conversion issues
On Tue, Jul 20, 2010 at 20:42, Bruce Momjian 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some git conversion issues
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 http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some git conversion issues
Magnus Hagander 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some git conversion issues
On Tue, Jul 20, 2010 at 15:31, Kevin Grittner wrote: > Magnus Hagander 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Some git conversion issues
Magnus Hagander 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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
