Re: [HACKERS] git: uh-oh
On Fri, Sep 10, 2010 at 07:51, Tom Lane t...@sss.pgh.pa.us wrote: Hey Magnus, what exactly was your process for verifying the file contents of the various release tags in the git conversion? Did you check them against the published tarballs, or against what the CVS repository said they should be? Because I've just found that this odd-looking manufactured commit: I do: cvs -q -d /usr/local/cvsroot export -d /opt/compare_working/cvs -r $B pgsql followed by git archive --format=tar $B | (cd /opt/compare_working/git tar xf -) and then diff -Nr /opt/compare_working/cvs /opt/compare_working/git /opt/diffs/$B.diff For each branch head and tag. I don't look at the tarballs at all. is there because these files have no REL7_3_5 tag according to CVS. Which is damn weird, because they all have tags for the preceding and following releases, *and they are there in the published tarball*. It looks to me like what didn't get tagged is a few complete directories, which means the most likely mechanism is the cvs tag operation being run in a checkout tree that lacked these subdirectories for some reason. But that's just a guess; we'll probably never know for sure. Anyway I am now thinking that we'd better compare published tarballs to the CVS tags and find out what other discrepancies there are. The checking we've done to verify releases in the past has always been that the tarballs were sane, not that the tagging was sane, so in case of any discrepancy I'd say the tarball should be considered authoritative. Ouch. yeah, if the tarballs and cvs don't match, we really can't expect the tarballs and git to match.. I've already found one other issue: the root HISTORY and INSTALL files have REL7_3_10 tags and should not. This is not entirely CVS' fault though: I think what happened is that Marc manually moved the already-applied REL7_3_10 tag when we re-did that release, and didn't account for the fact that I'd deleted those two files in the branch meanwhile. That one is also confusing cvs2git no end. Ouch. Yeah, moving tags is evil. -- 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] git: uh-oh
2010/9/10 Tom Lane t...@sss.pgh.pa.us: I wrote: OK, so I tried a conversion with the it.po hack I showed before; not trying to fix any of the other instances yet, but just see what happens with the 8.4.3/8.4.4 case. It's definitely better: * Marc's 8.4.3 tag commit is now the last ancestor of REL8_4_3, and the previous commits in the branch are earlier ancestors. No more 8.4.3 as a stub branch. * it.po is shown as added, not modified, in Peter's 8.4-branch commit of 2010-05-13. * The cherrypick additions of xml2.out and xml2.sql no longer reference it.po too. But we're not quite there yet. What I find for it.po is these two commits, which immediately follow the addition of it.po on the main branch: commit fd0c9e8bbf50f65a6d03a5d5d59e19cf67c7bc94 refs/tags/REL8_4_3 Author: Peter Eisentraut pete...@gmx.net Date: Fri Feb 19 00:40:07 2010 + log addition on branch D src/bin/pg_dump/po/it.po commit f345298286359f666211c7555420d147222888bf refs/tags/REL8_4_3 Author: PostgreSQL Daemon webmas...@postgresql.org Date: Fri Feb 19 00:40:06 2010 + This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'. Cherrypick from master 2010-02-19 00:40:05 UTC Peter Eisentraut pete...@gmx.net 'Translation updates for 9.0alpha4': src/bin/pg_dump/po/it.po A src/bin/pg_dump/po/it.po After some more experimentation I believe I've found the answer: what we should do is hack the CVS history so that the branch revisions sprout from the mainline revision that they should logically have sprouted from, not the chronologically-most-recent revision. When I modify it.po as shown in the attached patch, I get a conversion that has no funny business at all: it.po is deleted where it should be, and added where it should be, and there's *no* manufactured commit anywhere. Now, when you look at the patch, it's probably going to scare the daylights out of you. But it's really not that bad. What we're doing is renumbering the 1.7.6.1 revision to 1.5.6.1 (because it now sprouts from 1.5 not 1.7 on the mainline) and replacing its delta content with an appropriate delta from 1.5 not 1.7. The delta content is easily generated via cvs diff -n between the relevant versions --- AFAICT all we have to do to the diff output is double any @-signs. We can also easily verify that we did it right, by checking out the branch revision from CVS afterwards and seeing that it has the right content. Once I understood what needed to be done, it took me about two minutes to make these changes manually. I'm inclined to think it's not worth developing a tool for it --- we could probably manually fix the couple dozen files that need to be fixed in less time than that would take. Comments? That patch scares the daylights out of me? ;) Anyway, yeah, it does seem like a good way to do it. If we can produce a patch that we apply to the raw cvs repository before we do the migration, that's good - but I would like to avoid the manual steps in the *actual migration*. Once we do the final migration, it should just be a replay of the exact same steps we used for the final testing repository, which is hard to guarantee if we need to set this up manually each time. -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: Anyway, yeah, it does seem like a good way to do it. If we can produce a patch that we apply to the raw cvs repository before we do the migration, that's good - but I would like to avoid the manual steps in the *actual migration*. Once we do the final migration, it should just be a replay of the exact same steps we used for the final testing repository, which is hard to guarantee if we need to set this up manually each time. Absolutely. What I had in mind is that we have a predetermined patch to apply to the repository, and take care that we don't touch that particular file or files in CVS between making/testing the patch and the final migration. At the moment I'm thinking there are probably not going to be that many files affected. The technique I showed last night only seems to work if there is a dead revision on HEAD at the time the branch should sprout; which was the case for it.po, but it likely applies in only one or two other places. The more common case is that the file never existed at all before the time of the branch divergence. Possibly Max's technique will work better for those cases, but I've not had time to try it yet. Right at the moment, though, we have bigger problems. There's no point in expecting cvs2git to produce sane output from insane input, and I've now found at least three places where the tags in the CVS repository are flat out not sane. (The third is that the recently-added regression test files in contrib/xml2/ have REL8_0_23 tags. Which is not sane because they did not exist when that branch was tagged.) So I think the first order of business is to try to validate the CVS tags against the archived tarballs, and see what else turns up. regards, tom lane -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Fri, Sep 10, 2010 at 07:51, Tom Lane t...@sss.pgh.pa.us wrote: Hey Magnus, what exactly was your process for verifying the file contents of the various release tags in the git conversion? Did you check them against the published tarballs, or against what the CVS repository said they should be? Because I've just found that this odd-looking manufactured commit: I do: cvs -q -d /usr/local/cvsroot export -d /opt/compare_working/cvs -r $B pgsql I'm trying to check the tarballs here, and I've run into the problem that my local copy of cvs doesn't know to expand the $PostgreSQL$ keywords. Where does one set that? regards, tom lane -- 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] git: uh-oh
Excerpts from Tom Lane's message of vie sep 10 11:36:17 -0400 2010: I'm trying to check the tarballs here, and I've run into the problem that my local copy of cvs doesn't know to expand the $PostgreSQL$ keywords. Where does one set that? CVSROOT/options, add a line tag=PostgreSQL=CVSHeader I think older CVS versions used tagexpand=iPostgreSQL instead. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] git: uh-oh
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Tom Lane's message of vie sep 10 11:36:17 -0400 2010: I'm trying to check the tarballs here, and I've run into the problem that my local copy of cvs doesn't know to expand the $PostgreSQL$ keywords. Where does one set that? CVSROOT/options, add a line tag=PostgreSQL=CVSHeader [ scratches head... ] I have that file, because I copied the master repository verbatim. I think older CVS versions used tagexpand=iPostgreSQL instead. This is 1.11.23, so it's certainly not older than our server. Still confused :-( regards, tom lane -- 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] git: uh-oh
On Fri, Sep 10, 2010 at 18:17, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Tom Lane's message of vie sep 10 11:36:17 -0400 2010: I'm trying to check the tarballs here, and I've run into the problem that my local copy of cvs doesn't know to expand the $PostgreSQL$ keywords. Where does one set that? CVSROOT/options, add a line tag=PostgreSQL=CVSHeader [ scratches head... ] I have that file, because I copied the master repository verbatim. I think older CVS versions used tagexpand=iPostgreSQL instead. This is 1.11.23, so it's certainly not older than our server. Still confused :-( FWIW, I'm on 1.12.13 on the box I've been doing the migrations on. -- 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] git: uh-oh
Excerpts from Tom Lane's message of vie sep 10 12:17:30 -0400 2010: Alvaro Herrera alvhe...@commandprompt.com writes: I think older CVS versions used tagexpand=iPostgreSQL instead. This is 1.11.23, so it's certainly not older than our server. Hmm, I have 1.12.13 here and it works for me. I see that CVSROOT/config used to have the same lines: LocalKeyword=PostgreSQL=CVSHeader KeywordExpand=iPostgreSQL but now they are in the config.bak file. Maybe the options file is not used by your cvs command (I know mine is patched by Debian somehow) -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] git: uh-oh
Excerpts from Alvaro Herrera's message of vie sep 10 12:51:26 -0400 2010: Hmm, I have 1.12.13 here and it works for me. I see that CVSROOT/config used to have the same lines: LocalKeyword=PostgreSQL=CVSHeader KeywordExpand=iPostgreSQL but now they are in the config.bak file. Maybe the options file is not used by your cvs command (I know mine is patched by Debian somehow) Yeah, the README.Debian file says (and this probably explains why it works for Magnus as well): Control of Keyword Expansion Since version 1.12.2 CVS has supported, without external patches, custom keyword expansion options. Previously CVS required a patch to implement this, and users may know the feature as the options tag and tagexpand from the CVSROOT/options file. CVS now uses a similar method in CVSROOT/config. For more information see the CVS documentation(infobrowser (CVS)Configuring keyword expansion). The old CVSROOT/options patch is still present (and updated) to support users with old config for now, but will be removed soon. Update your config to use CVSROOT/config instead! -- James Rowe j...@jnrowe.ukfsn.org Sat, 03 Apr 2004 23:23:57 +0100 -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] git: uh-oh
Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Tom Lane's message of vie sep 10 12:17:30 -0400 2010: This is 1.11.23, so it's certainly not older than our server. Hmm, I have 1.12.13 here and it works for me. Yeah ... what we actually have on the master server is 1.11.17-FreeBSD, and it seems after some digging that the tag= capability was a BSD patch to start with. The CVS people adopted it into their 1.12 series, with a different name ... but Fedora is still on the 1.11.x series, bless their conservative little heads. Guess I gotta install 1.12. regards, tom lane -- 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] git: uh-oh
Hey Magnus, what exactly was your process for verifying the file contents of the various release tags in the git conversion? Did you check them against the published tarballs, or against what the CVS repository said they should be? Because I've just found that this odd-looking manufactured commit: commit 94b87adc86f5dce6ee5957af83c41fa1f8476c39 refs/tags/REL7_3_5 Author: PostgreSQL Daemon webmas...@postgresql.org Date: Tue Dec 2 16:26:01 2003 + This commit was manufactured by cvs2svn to create tag 'REL7_3_5'. Sprout from REL7_3_STABLE 2003-12-02 16:26:00 UTC Tom Lane t...@sss.pgh.pa.us 'Brand 7.3.5.' Delete: doc/src/graphics/catalogs.ag doc/src/graphics/catalogs.cgm doc/src/graphics/catalogs.gif doc/src/graphics/catalogs.ps doc/src/graphics/clientserver.ag doc/src/graphics/clientserver.gif doc/src/graphics/connections.ag doc/src/graphics/connections.gif src/data/charset.conf src/data/isocz-wincz.tab src/data/koi-alt.tab src/data/koi-iso.tab src/data/koi-koi.tab src/data/koi-mac.tab src/data/koi-win.tab src/interfaces/cli/example1.c src/interfaces/cli/example2.c src/interfaces/cli/sqlcli.h src/interfaces/ecpg/lib/Makefile src/interfaces/ecpg/lib/connect.c src/interfaces/ecpg/lib/data.c src/interfaces/ecpg/lib/descriptor.c src/interfaces/ecpg/lib/error.c src/interfaces/ecpg/lib/execute.c src/interfaces/ecpg/lib/extern.h src/interfaces/ecpg/lib/memory.c src/interfaces/ecpg/lib/misc.c src/interfaces/ecpg/lib/pg_type.h src/interfaces/ecpg/lib/prepare.c src/interfaces/ecpg/lib/typename.c src/interfaces/python/Announce src/interfaces/python/ChangeLog src/interfaces/python/GNUmakefile src/interfaces/python/PyGreSQL.spec src/interfaces/python/README src/interfaces/python/Setup.in.raw src/interfaces/python/pg.py src/interfaces/python/pgdb.py src/interfaces/python/pgmodule.c src/interfaces/python/setup.py src/interfaces/python/tutorial/advanced.py src/interfaces/python/tutorial/basics.py src/interfaces/python/tutorial/func.py src/interfaces/python/tutorial/syscat.py D doc/src/graphics/catalogs.ag D doc/src/graphics/catalogs.cgm D doc/src/graphics/catalogs.gif D doc/src/graphics/catalogs.ps D doc/src/graphics/clientserver.ag D doc/src/graphics/clientserver.gif D doc/src/graphics/connections.ag D doc/src/graphics/connections.gif D src/data/charset.conf D src/data/isocz-wincz.tab D src/data/koi-alt.tab D src/data/koi-iso.tab D src/data/koi-koi.tab D src/data/koi-mac.tab D src/data/koi-win.tab D src/interfaces/cli/example1.c D src/interfaces/cli/example2.c D src/interfaces/cli/sqlcli.h D src/interfaces/ecpg/lib/Makefile D src/interfaces/ecpg/lib/connect.c D src/interfaces/ecpg/lib/data.c D src/interfaces/ecpg/lib/descriptor.c D src/interfaces/ecpg/lib/error.c D src/interfaces/ecpg/lib/execute.c D src/interfaces/ecpg/lib/extern.h D src/interfaces/ecpg/lib/memory.c D src/interfaces/ecpg/lib/misc.c D src/interfaces/ecpg/lib/pg_type.h D src/interfaces/ecpg/lib/prepare.c D src/interfaces/ecpg/lib/typename.c D src/interfaces/python/Announce D src/interfaces/python/ChangeLog D src/interfaces/python/GNUmakefile D src/interfaces/python/PyGreSQL.spec D src/interfaces/python/README D src/interfaces/python/Setup.in.raw D src/interfaces/python/pg.py D src/interfaces/python/pgdb.py D src/interfaces/python/pgmodule.c D src/interfaces/python/setup.py D src/interfaces/python/tutorial/advanced.py D src/interfaces/python/tutorial/basics.py D src/interfaces/python/tutorial/func.py D src/interfaces/python/tutorial/syscat.py is there because these files have no REL7_3_5 tag according to CVS. Which is damn weird, because they all have tags for the preceding and following releases, *and they are there in the published tarball*. It looks to me like what didn't get tagged is a few complete directories, which means the most likely mechanism is the cvs tag operation being run in a checkout tree that lacked these subdirectories for some reason. But that's just a guess; we'll probably never know for sure. Anyway I am now thinking that we'd better compare published tarballs to the CVS tags and find out what other discrepancies there are. The checking we've done to verify releases in the past has always been that the tarballs were sane, not that the tagging was sane, so in case of any discrepancy I'd say the tarball should be considered authoritative. I've already found one other issue: the root HISTORY and
Re: [HACKERS] git: uh-oh
Tom Lane wrote: Well, even if the goal is to faithfully represent the bogus history shown by CVS, cvs2git isn't doing a good job of it. Them's fightin' words :-) In the case of src/bin/pg_dump/po/it.po, the CVS history claims that the version added to REL8_4_STABLE on 2010-05-13 is a child of the mainline version 1.7 committed on 2010-02-19. Therefore, according to CVS the file existed on the branch from 2010-02-19, not 2010-02-28 as claimed by the cvs2git translation. Incorrect. The CVS history implies three user-initiated events in this neighborhood: 2010.02.19: version 1.7 committed to trunk unknown date: file added to branch REL8_4_STABLE (1.7.6) 2010.05.13: file modified on branch REL8_4_STABLE to create 1.7.6.1 The CVS history gives no reason to assume that the middle event happened on 2010-02-19, or on 2010-05-13, or on any other particular date. *If* you trust the timestamps (which cvs2git treats sceptically because they are often wrong), then you can say with certainty that the intermediate event happened sometime between the two numbered commits. It is cvs2git policy to try to group add-branch-tag-to-file events together if such grouping is consistent with the nearby commit dates. The files contrib/xml2/expected/xml2.out and contrib/xml2/sql/xml2.sql have the following constraints: contrib/xml2/expected/xml2.out: 2010.02.28: 1.1 unknown date: file added to branch REL8_4_STABLE (1.1.2) 2010.03.01: 1.1.2.1 contrib/xml2/sql/xml2.sql 2010.02.28: 1.1 unknown date: file added to branch REL8_4_STABLE (1.1.2) 2010.03.01: 1.1.2.1 Since there is a date range (2010-02-28 - 2010-03-01) consistent with all of the constraints, cvs2git picks a date in that range for a commit that adds all three files to branch REL8_4_STABLE. I did some cvs co operations to check this and cvs does indeed retrieve the file between 02-19 and 02-28, but not before 02-19. So I don't think you can defend the cvs2git behavior by claiming that it's an exact translation. CVS is using the same incomplete data as cvs2svn and, just like cvs2git, it has to pick a date out of its hat. It happens to choose a different date than cvs2git. *Neither CVS nor cvs2git can be sure when the file was really added to the branch, and neither is more likely to be correct than the other.* (Actually, cvs2git is arguably more likely to be correct because it uses information from multiple files in its heuristic whereas CVS considers information for only the single file.) Robert Haas wrote: One thing I'm not quite clear on is how cvs2git thinks CVS should look given what we actually did vs. how it actually does look, The crux of the problem is that there is a plethora of hypothetical true histories that are consistent with the incomplete data recorded by CVS. cvs2svn/cvs2git picks a history that is 1. Correct, which I define to mean that the chosen history is not contradicted by the CVS data (with deviations allowed only when the CVS data is internally inconsistent). Any problems with this criterion are considered serious bugs. But (1) still leaves a vast number of possible histories. So a secondary goal is to choose a history that is 2. Plausible, meaning that it the history is believable given the way that people typically develop software in a typical CVS project. This is necessarily subjective and depends a lot on project culture and policies. (A cvs2git written from scratch for the pgsql project would undoubtedly be more mindful of your project's policies.) Improvements on this criterion are also constrained by performance requirements. Michael -- 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] git: uh-oh
Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: Well, even if the goal is to faithfully represent the bogus history shown by CVS, cvs2git isn't doing a good job of it. Them's fightin' words :-) Yeah ;-), but they were mainly directed at Robert, who AIUI was asserting that the behavior of cvs co -D ought to be taken as defining what the CVS history means. I don't particularly buy that, and clearly you don't either. Incorrect. The CVS history implies three user-initiated events in this neighborhood: 2010.02.19: version 1.7 committed to trunk unknown date: file added to branch REL8_4_STABLE (1.7.6) 2010.05.13: file modified on branch REL8_4_STABLE to create 1.7.6.1 Right. The problem I've got is that cvs2git takes unknown as meaning I can do whatever I want, the more random the better. It would seem to me to be good software engineering to recognize that you don't have enough information and to provide some way for cvs2git's users to modify its behavior on this point. Anyway I think the solution path for us is probably going to be to retroactively add the information, along the lines suggested by Max. I was hoping that somebody would have tried a conversion by now with the partial patch I suggested last night, but maybe I'm going to have to do it myself. Where can I find the version of cvs2git we're using? regards, tom lane -- 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] git: uh-oh
On Wed, Sep 8, 2010 at 16:21, Tom Lane t...@sss.pgh.pa.us wrote: Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: Well, even if the goal is to faithfully represent the bogus history shown by CVS, cvs2git isn't doing a good job of it. Them's fightin' words :-) Yeah ;-), but they were mainly directed at Robert, who AIUI was asserting that the behavior of cvs co -D ought to be taken as defining what the CVS history means. I don't particularly buy that, and clearly you don't either. Incorrect. The CVS history implies three user-initiated events in this neighborhood: 2010.02.19: version 1.7 committed to trunk unknown date: file added to branch REL8_4_STABLE (1.7.6) 2010.05.13: file modified on branch REL8_4_STABLE to create 1.7.6.1 Right. The problem I've got is that cvs2git takes unknown as meaning I can do whatever I want, the more random the better. It would seem to me to be good software engineering to recognize that you don't have enough information and to provide some way for cvs2git's users to modify its behavior on this point. Anyway I think the solution path for us is probably going to be to retroactively add the information, along the lines suggested by Max. I was hoping that somebody would have tried a conversion by now with the partial patch I suggested last night, but maybe I'm going to have to do it myself. Where can I find the version of cvs2git we're using? I'm using svn trunk revision 5244 from http://cvs2svn.tigris.org/svn/cvs2svn/trunk. -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Wed, Sep 8, 2010 at 16:21, Tom Lane t...@sss.pgh.pa.us wrote: Where can I find the version of cvs2git we're using? I'm using svn trunk revision 5244 from http://cvs2svn.tigris.org/svn/cvs2svn/trunk. [ blink... ] That URL seems to want a password. regards, tom lane -- 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] git: uh-oh
On Wed, Sep 8, 2010 at 16:44, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Wed, Sep 8, 2010 at 16:21, Tom Lane t...@sss.pgh.pa.us wrote: Where can I find the version of cvs2git we're using? I'm using svn trunk revision 5244 from http://cvs2svn.tigris.org/svn/cvs2svn/trunk. [ blink... ] That URL seems to want a password. Oh, right, it does. It'll tell you that on the website, but I forgot it :-) Username guest, blank password. -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: I'm using svn trunk revision 5244 from http://cvs2svn.tigris.org/svn/cvs2svn/trunk. Just to make sure everybody is on the same page: I've installed svn revision 5270, which is the version currently available from that URL, and is also what Max indicated he was using in his test conversion. Suggest you update too. regards, tom lane -- 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] git: uh-oh
On Wed, Sep 8, 2010 at 20:11, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: I'm using svn trunk revision 5244 from http://cvs2svn.tigris.org/svn/cvs2svn/trunk. Just to make sure everybody is on the same page: I've installed svn revision 5270, which is the version currently available from that URL, and is also what Max indicated he was using in his test conversion. Suggest you update too. Done, thanks for the reminder. -- 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] git: uh-oh
OK, so I tried a conversion with the it.po hack I showed before; not trying to fix any of the other instances yet, but just see what happens with the 8.4.3/8.4.4 case. It's definitely better: * Marc's 8.4.3 tag commit is now the last ancestor of REL8_4_3, and the previous commits in the branch are earlier ancestors. No more 8.4.3 as a stub branch. * it.po is shown as added, not modified, in Peter's 8.4-branch commit of 2010-05-13. * The cherrypick additions of xml2.out and xml2.sql no longer reference it.po too. But we're not quite there yet. What I find for it.po is these two commits, which immediately follow the addition of it.po on the main branch: commit fd0c9e8bbf50f65a6d03a5d5d59e19cf67c7bc94 refs/tags/REL8_4_3 Author: Peter Eisentraut pete...@gmx.net Date: Fri Feb 19 00:40:07 2010 + log addition on branch D src/bin/pg_dump/po/it.po commit f345298286359f666211c7555420d147222888bf refs/tags/REL8_4_3 Author: PostgreSQL Daemon webmas...@postgresql.org Date: Fri Feb 19 00:40:06 2010 + This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'. Cherrypick from master 2010-02-19 00:40:05 UTC Peter Eisentraut pete...@gmx.net 'Translation updates for 9.0alpha4': src/bin/pg_dump/po/it.po A src/bin/pg_dump/po/it.po The first of these is the made-up deletion commit that I patched into it.po,v. But why are we getting the manufactured commit anyway? Max, is this what you expected to happen? Can we do better? regards, tom lane -- 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] git: uh-oh
Tom Lane wrote: Michael Haggerty mhag...@alum.mit.edu writes: No, it is also possible to use cvs tag -b REL8_4_STABLE filename. In this case the file as it appears on the current branch is added to the specified branch, but CVS records no commit, author, or timestamp. So, if we're prepared to assert that we've never done that, could we have an option to cvs2git that is willing to use the first commit on a branch to represent the act of adding the file to the branch? I'm afraid this would be pretty far down on my long todo list. Somebody could use git filter-branch to make this change after the conversion, but I can't estimate how much work it would be. Michael -- 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] git: uh-oh
Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: So, if we're prepared to assert that we've never done that, could we have an option to cvs2git that is willing to use the first commit on a branch to represent the act of adding the file to the branch? I'm afraid this would be pretty far down on my long todo list. Fair enough. Somebody could use git filter-branch to make this change after the conversion, but I can't estimate how much work it would be. The conversion is already far better than I expected it would be when we were first discussing this switch, so my inclination is to just live with this one wart. I spent more time over the weekend comparing various branches' histories between cvs2cl and Max's repository. I found a lot of places where cvs2cl had problems :-(, but none where the git history could be blamed. I'm ready to sign off on this conversion process as being Good Enough, modulo two points: * Change the committer name assigned to manufactured commits, as already mentioned. * Please make the manufactured commits read cvs2git not cvs2svn. I don't want people wondering in future when it was we used SVN. AFAIK both of these are trivial configuration fixes. regards, tom lane -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 15:53, Tom Lane t...@sss.pgh.pa.us wrote: Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: So, if we're prepared to assert that we've never done that, could we have an option to cvs2git that is willing to use the first commit on a branch to represent the act of adding the file to the branch? I'm afraid this would be pretty far down on my long todo list. Fair enough. Somebody could use git filter-branch to make this change after the conversion, but I can't estimate how much work it would be. The conversion is already far better than I expected it would be when we were first discussing this switch, so my inclination is to just live with this one wart. I spent more time over the weekend comparing various branches' histories between cvs2cl and Max's repository. I found a lot of places where cvs2cl had problems :-(, but none where the git history could be blamed. I'm ready to sign off on this conversion process as being Good Enough, modulo two points: * Change the committer name assigned to manufactured commits, as already mentioned. * Please make the manufactured commits read cvs2git not cvs2svn. I don't want people wondering in future when it was we used SVN. AFAIK both of these are trivial configuration fixes. I'm actually re-running a migration right now with this - and with the change to use rcs instead of cvs, to see if I can reproduce Max's proper repository. You're saying you don't require a fix on the latest issue here? Or should we spend some time trying to figure out if we can fix it with git-filter-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] git: uh-oh
On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander mag...@hagander.net wrote: You're saying you don't require a fix on the latest issue here? Or should we spend some time trying to figure out if we can fix it with git-filter-branch? I think that the latest issue here is the issue of how files get added to branches, which we discussed before with pretty much the same set of conclusions. I'm not wild about the way that's getting converted, but I'm not sure I care enough about it to argue with Tom. However, I want to convince myself that the deletes we've done over the years have been properly handled. I need to look at Max's latest conversion and I'll look at yours as well. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 15:53, Tom Lane t...@sss.pgh.pa.us wrote: Michael Haggerty mhag...@alum.mit.edu writes: Somebody could use git filter-branch to make this change after the conversion, but I can't estimate how much work it would be. The conversion is already far better than I expected it would be when we were first discussing this switch, so my inclination is to just live with this one wart. You're saying you don't require a fix on the latest issue here? Or should we spend some time trying to figure out if we can fix it with git-filter-branch? If you want to try, and it doesn't take much time, go for it. I was just saying I wouldn't complain if we decide to live with it as-is. regards, tom lane -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 16:16, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 15:53, Tom Lane t...@sss.pgh.pa.us wrote: Michael Haggerty mhag...@alum.mit.edu writes: Somebody could use git filter-branch to make this change after the conversion, but I can't estimate how much work it would be. The conversion is already far better than I expected it would be when we were first discussing this switch, so my inclination is to just live with this one wart. You're saying you don't require a fix on the latest issue here? Or should we spend some time trying to figure out if we can fix it with git-filter-branch? If you want to try, and it doesn't take much time, go for it. I was just saying I wouldn't complain if we decide to live with it as-is. Ok. Do we have a way of identifying them - e.g. is it all the commits with a certain commit msg? -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 16:16, Tom Lane t...@sss.pgh.pa.us wrote: If you want to try, and it doesn't take much time, go for it. I was just saying I wouldn't complain if we decide to live with it as-is. Ok. Do we have a way of identifying them - e.g. is it all the commits with a certain commit msg? Look for This commit was manufactured by cvs2svn to create branch ... regards, tom lane -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 16:16, Tom Lane t...@sss.pgh.pa.us wrote: If you want to try, and it doesn't take much time, go for it. I was just saying I wouldn't complain if we decide to live with it as-is. Ok. Do we have a way of identifying them - e.g. is it all the commits with a certain commit msg? Look for This commit was manufactured by cvs2svn to create branch ... Ok, found a bunch of those (78 to be exact). And the issue with them is we want to change the commit author on them to be whomever made the first commit on the branch *after* that? -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us wrote: Look for This commit was manufactured by cvs2svn to create branch ... Ok, found a bunch of those (78 to be exact). And the issue with them is we want to change the commit author on them to be whomever made the first commit on the branch *after* that? What I'd like is for those commits to vanish from the git log entirely. In a practical sense, what you should probably do is for each file mentioned in such a commit, cause the file's addition to the branch to become part of the first regular commit on the branch that touched that file. In the CVS history, at least, there always is such a commit (since we never did the cvs tag -b thing). I am not sure though whether the converted git history includes a touch of the file in that commit, if the version committed into the branch is identical to what was on HEAD. Michael, can you comment on that point? regards, tom lane -- 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] git: uh-oh
On 07/09/10 16:21, Magnus Hagander wrote: On Tue, Sep 7, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 16:16, Tom Lane t...@sss.pgh.pa.us wrote: If you want to try, and it doesn't take much time, go for it. I was just saying I wouldn't complain if we decide to live with it as-is. Ok. Do we have a way of identifying them - e.g. is it all the commits with a certain commit msg? Look for This commit was manufactured by cvs2svn to create branch ... Ok, found a bunch of those (78 to be exact). And the issue with them is we want to change the commit author on them to be whomever made the first commit on the branch *after* that? I would say you emphatically don't want to do that, because they can contain more changes that were unrelated to that author. The logic, as I understand it from Michael's explanation of cvs2git's guts, is to flush out any pending add to branch because of implicit appearance of a branch tag operations when something other change is about to occur on the destination branch. So unrelated stuff can get batched together. Personally, the idea of trying to use git-filter-branch to make what cvs2git currently gives you more sensible scares me silly. I think the approach should be to use it as is, or improve cvs2git. Another glitch that might be worth fixing before you convert is the way that cvs2git says This commit was manufactured by cvs2svn to create branch, when it actually means manufactured to incrementally create the branch state as it appears in CVS - i.e. many of these commits actually update an existing branch. Just as soon as I can figure out how to cleanly fit that into cvs2git's structure, I want it to change the word create to update in most of those commits. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Max Bowsher m...@f2s.com writes: Personally, the idea of trying to use git-filter-branch to make what cvs2git currently gives you more sensible scares me silly. I'm not excited about it either --- but if Magnus wants to experiment, no harm trying. Another glitch that might be worth fixing before you convert is the way that cvs2git says This commit was manufactured by cvs2svn to create branch, when it actually means manufactured to incrementally create the branch state as it appears in CVS - i.e. many of these commits actually update an existing branch. Just as soon as I can figure out how to cleanly fit that into cvs2git's structure, I want it to change the word create to update in most of those commits. I thought all of those message texts were taken from the configuration file. regards, tom lane -- 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] git: uh-oh
I wrote: Magnus Hagander mag...@hagander.net writes: Ok, found a bunch of those (78 to be exact). What I'd like is for those commits to vanish from the git log entirely. In a practical sense, what you should probably do is for each file mentioned in such a commit, cause the file's addition to the branch to become part of the first regular commit on the branch that touched that file. In the CVS history, at least, there always is such a commit (since we never did the cvs tag -b thing). I am not sure though whether the converted git history includes a touch of the file in that commit, Given that there are only 78 such commits, it would not take too long to manually prepare a list of which commit each file addition should get moved into. Would that be a more sensible approach than trying to extract the information from the git log? regards, tom lane -- 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] git: uh-oh
On 07/09/10 16:47, Tom Lane wrote: Max Bowsher m...@f2s.com writes: Personally, the idea of trying to use git-filter-branch to make what cvs2git currently gives you more sensible scares me silly. I'm not excited about it either --- but if Magnus wants to experiment, no harm trying. Another glitch that might be worth fixing before you convert is the way that cvs2git says This commit was manufactured by cvs2svn to create branch, when it actually means manufactured to incrementally create the branch state as it appears in CVS - i.e. many of these commits actually update an existing branch. Just as soon as I can figure out how to cleanly fit that into cvs2git's structure, I want it to change the word create to update in most of those commits. I thought all of those message texts were taken from the configuration file. Yes, but currently these two cases both reference the same entry in the configuration file. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: On Tue, Sep 7, 2010 at 17:07, Tom Lane t...@sss.pgh.pa.us wrote: Look for This commit was manufactured by cvs2svn to create branch ... Ok, found a bunch of those (78 to be exact). And the issue with them is we want to change the commit author on them to be whomever made the first commit on the branch *after* that? What I'd like is for those commits to vanish from the git log entirely. In a practical sense, what you should probably do is for each file mentioned in such a commit, cause the file's addition to the branch to become part of the first regular commit on the branch that touched that file. In the CVS history, at least, there always is such a commit (since we never did the cvs tag -b thing). I am not sure though whether the converted git history includes a touch of the file in that commit, if the version committed into the branch is identical to what was on HEAD. Michael, can you comment on that point? If the situation is a file that had a branch tag added to it after the branch was first created, then there is a git commit corresponding to that event that consists of the addition of that file with no history. This commit might also include the addition of other files to the branch, but should not include any file content changes. It seems to me that in your case such commits could be grafted over: *---*---*---* \ A---B---C---D E.g., if C is one of these special manufactured commits, then you could use git grafts to change the parent of D from C to B, then bake in the change with git filter-branch. This would make C inaccessible and subject to garbage collection. But please check by hand to make sure that this makes sense; for example, it could be that other branches in the neighborhood make the excision impossible. Michael -- 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] git: uh-oh
Max Bowsher m...@f2s.com writes: On 07/09/10 16:47, Tom Lane wrote: Max Bowsher m...@f2s.com writes: ... Just as soon as I can figure out how to cleanly fit that into cvs2git's structure, I want it to change the word create to update in most of those commits. I thought all of those message texts were taken from the configuration file. Yes, but currently these two cases both reference the same entry in the configuration file. Oh, I misunderstood the most bit ;-) regards, tom lane -- 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] git: uh-oh
Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: What I'd like is for those commits to vanish from the git log entirely. It seems to me that in your case such commits could be grafted over: *---*---*---* \ A---B---C---D E.g., if C is one of these special manufactured commits, then you could use git grafts to change the parent of D from C to B, then bake in the change with git filter-branch. This would make C inaccessible and subject to garbage collection. Hmm, I see. This depends on the fact that git commits reference filesystem states and not deltas, correct? So it does actually make sense to just delete that commit from the history. I was concerned that it'd invalidate later commits, but I guess it doesn't. But please check by hand to make sure that this makes sense; for example, it could be that other branches in the neighborhood make the excision impossible. Since we weren't doing merging, nor branching off from back branches, I'm having a hard time seeing how there'd be any risk there. Is there a case I'm missing? regards, tom lane -- 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] git: uh-oh
On 07/09/10 18:16, Tom Lane wrote: Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: What I'd like is for those commits to vanish from the git log entirely. It seems to me that in your case such commits could be grafted over: *---*---*---* \ A---B---C---D E.g., if C is one of these special manufactured commits, then you could use git grafts to change the parent of D from C to B, then bake in the change with git filter-branch. This would make C inaccessible and subject to garbage collection. Hmm, I see. This depends on the fact that git commits reference filesystem states and not deltas, correct? So it does actually make sense to just delete that commit from the history. I was concerned that it'd invalidate later commits, but I guess it doesn't. It wouldn't - except for the fact that cvs2git batches such manufactured commits such that there is no guarantee that a single manufactured commit pertains only to files in the commit immediately afterwards. For example, consider the it.po file in the commit referenced in this thread yesterday: commit b36518cb880bb236496ec3e505ede4001ce56157 Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sun Feb 28 21:32:02 2010 + This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'. Cherrypick from master 2010-02-28 21:31:57 UTC Tom Lane t...@sss.pgh.pa.us 'Fix up memory management problems in contrib/xml2.': contrib/xml2/expected/xml2.out contrib/xml2/sql/xml2.sql src/bin/pg_dump/po/it.po Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Max Bowsher m...@f2s.com writes: On 07/09/10 18:16, Tom Lane wrote: Hmm, I see. This depends on the fact that git commits reference filesystem states and not deltas, correct? So it does actually make sense to just delete that commit from the history. I was concerned that it'd invalidate later commits, but I guess it doesn't. It wouldn't - except for the fact that cvs2git batches such manufactured commits such that there is no guarantee that a single manufactured commit pertains only to files in the commit immediately afterwards. Hmm ... so the consequence of that would be that (in this example) it.po would show up as being part of the REL8_4_STABLE file set as of that commit, rather than as of the later commit where it really got added. That's kind of annoying, but it is not a showstopper I think. Recall that the goals we set for this conversion in the first place were (1) duplicate the file set as of any back release tag and (2) duplicate the CVS log history as nearly as practical. We know we have met (1), because Magnus explicitly tested that. IMO we have met (2) adequately as well, with or without any fix for the manufactured-commit issue. On reflection it might be better to leave well enough alone, though. Anybody looking at the real commit in future might be confused by the fact that it added a seemingly unrelated file. It would be less confusing to have an obviously made-up commit adding some files, probably. A compromise might be to excise only those manufactured commits that added files directly related to the following real commit. I haven't looked to see how many there are that grouped unrelated files. regards, tom lane -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander mag...@hagander.net wrote: You're saying you don't require a fix on the latest issue here? Or should we spend some time trying to figure out if we can fix it with git-filter-branch? I think that the latest issue here is the issue of how files get added to branches, which we discussed before with pretty much the same set of conclusions. I'm not wild about the way that's getting converted, but I'm not sure I care enough about it to argue with Tom. However, I want to convince myself that the deletes we've done over the years have been properly handled. I need to look at Max's latest conversion and I'll look at yours as well. Magnus - I just looked at your latest conversion (based on what Max did) and it looks a lot better. I think, though, that we should re-remove these branches: origin/unlabeled-1.44.2 origin/unlabeled-1.51.2 origin/unlabeled-1.59.2 origin/unlabeled-1.87.2 origin/unlabeled-1.90.2 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
Robert Haas robertmh...@gmail.com writes: I just looked at your latest conversion (based on what Max did) and it looks a lot better. I think, though, that we should re-remove these branches: origin/unlabeled-1.44.2 origin/unlabeled-1.51.2 origin/unlabeled-1.59.2 origin/unlabeled-1.87.2 origin/unlabeled-1.90.2 I haven't looked at Magnus' latest iteration, but in Max's version this was showing as a branch: remotes/origin/REL8_0_0 AFAIK that was simply a mistake: it was intended to be a tag not a branch. If it's feasible to downgrade it to a tag during the conversion, that would be a good thing to do. regards, tom lane -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 22:06, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander mag...@hagander.net wrote: You're saying you don't require a fix on the latest issue here? Or should we spend some time trying to figure out if we can fix it with git-filter-branch? I think that the latest issue here is the issue of how files get added to branches, which we discussed before with pretty much the same set of conclusions. I'm not wild about the way that's getting converted, but I'm not sure I care enough about it to argue with Tom. However, I want to convince myself that the deletes we've done over the years have been properly handled. I need to look at Max's latest conversion and I'll look at yours as well. Magnus - I just looked at your latest conversion (based on what Max did) and it looks a lot better. I think, though, that we should re-remove these branches: origin/unlabeled-1.44.2 origin/unlabeled-1.51.2 origin/unlabeled-1.59.2 origin/unlabeled-1.87.2 origin/unlabeled-1.90.2 Oh yeah, I did the push before I ran that step of my script. Oops, sorry. -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 22:16, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: I just looked at your latest conversion (based on what Max did) and it looks a lot better. I think, though, that we should re-remove these branches: origin/unlabeled-1.44.2 origin/unlabeled-1.51.2 origin/unlabeled-1.59.2 origin/unlabeled-1.87.2 origin/unlabeled-1.90.2 I haven't looked at Magnus' latest iteration, but in Max's version this was showing as a branch: remotes/origin/REL8_0_0 AFAIK that was simply a mistake: it was intended to be a tag not a branch. If it's feasible to downgrade it to a tag during the conversion, that would be a good thing to do. Shold be doable with a simple: git tag REL8_0_0 REL8_0_0 git branch -D REL8_0_0 I'll try that and re-run my content-verification script on top of that. -- 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] git: uh-oh
Max Bowsher m...@f2s.com writes: It wouldn't - except for the fact that cvs2git batches such manufactured commits such that there is no guarantee that a single manufactured commit pertains only to files in the commit immediately afterwards. For example, consider the it.po file in the commit referenced in this thread yesterday: OK, I looked at this example, and I'm confused again. The actual 8.4 history of src/bin/pg_dump/po/it.po is that it was removed from HEAD on 2009-06-26, before the 8.4 branch was split off; and then re-added to the 8.4 branch on 2010-05-13, just before 8.4.4 was tagged. See http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/pg_dump/po/it.po Looking at Max's conversion with git log --all --source --name-status, this file is shown as modified in the latter commit: commit 575981a2fd6da5ccbf75c57580bf2d98b41f936e refs/tags/REL8_4_4 Author: Peter Eisentraut pete...@gmx.net Date: Thu May 13 10:50:20 2010 + Translation update ... M src/bin/pg_dump/po/it.po ... The deletion is correctly shown here: commit 4ade8dc6f7030b14306916b787fa8f75e4d49b2e refs/tags/REL8_4_0 Author: Peter Eisentraut pete...@gmx.net Date: Fri Jun 26 19:33:52 2009 + Translation updates for 8.4 release. File that are translated less than 80% have been removed, as per new translation team policy. ... D src/bin/pg_dump/po/it.po ... Now I can find two intermediate commits that touched this file: commit b78e79ec74fd4fac0c24753bbf8fa69fe7e6feb9 refs/tags/REL8_4_3 Author: PostgreSQL Daemon webmas...@postgresql.org Date: Fri Mar 12 03:23:24 2010 + This commit was manufactured by cvs2svn to create tag 'REL8_4_3'. Sprout from REL8_4_STABLE 2010-03-12 03:23:23 UTC Marc G. Fournier scra...@hub.org '' Delete: src/bin/pg_dump/po/it.po D src/bin/pg_dump/po/it.po commit b36518cb880bb236496ec3e505ede4001ce56157 refs/tags/REL8_4_4 Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sun Feb 28 21:32:02 2010 + This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'. Cherrypick from master 2010-02-28 21:31:57 UTC Tom Lane t...@sss.pgh.pa.us 'Fix up memory management problems in contrib/xml2.': contrib/xml2/expected/xml2.out contrib/xml2/sql/xml2.sql src/bin/pg_dump/po/it.po A contrib/xml2/expected/xml2.out A contrib/xml2/sql/xml2.sql A src/bin/pg_dump/po/it.po Now it seems to me that this is just totally wacko. In the first place, the commit manufactured by cvs2svn to create tag 'REL8_4_3' postdates the commit where Marc actually tagged 8.4.3: commit 3aa54912637319c516f59d3a0265cb7826ed125f refs/tags/REL8_4_4 Author: Marc G. Fournier scra...@hub.org Date: Fri Mar 12 03:23:23 2010 + tag 8.4.3 M configure M configure.in M doc/bug.template M src/include/pg_config.h.win32 M src/interfaces/libpq/libpq.rc.in M src/port/win32ver.rc BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4 and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps, but it sure looks wrong. (Magnus, did you check against the 8.4.3 tarball?) But the main gripe is: how can it be claimed to be sane to represent the revision history as being that it.po was added to 8.4.4 two weeks before it was deleted from 8.4.3? There is definitely *something* not kosher about the manufactured-commit logic. regards, tom lane -- 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] git: uh-oh
On 07/09/10 21:25, Magnus Hagander wrote: On Tue, Sep 7, 2010 at 22:06, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 10:08 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Sep 7, 2010 at 9:56 AM, Magnus Hagander mag...@hagander.net wrote: You're saying you don't require a fix on the latest issue here? Or should we spend some time trying to figure out if we can fix it with git-filter-branch? I think that the latest issue here is the issue of how files get added to branches, which we discussed before with pretty much the same set of conclusions. I'm not wild about the way that's getting converted, but I'm not sure I care enough about it to argue with Tom. However, I want to convince myself that the deletes we've done over the years have been properly handled. I need to look at Max's latest conversion and I'll look at yours as well. Magnus - I just looked at your latest conversion (based on what Max did) and it looks a lot better. I think, though, that we should re-remove these branches: origin/unlabeled-1.44.2 origin/unlabeled-1.51.2 origin/unlabeled-1.59.2 origin/unlabeled-1.87.2 origin/unlabeled-1.90.2 Oh yeah, I did the push before I ran that step of my script. Oops, sorry. Speaking of which, could you update the public copy of all the conversion documentation / machinery? Thanks, Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4 and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps, but it sure looks wrong. (Magnus, did you check against the 8.4.3 tarball?) I think this is another result of the same basic problem. Since cvs2git thinks it.po was added to REL8_4_STABLE on 2010-02-28 rather than 2010-05-13,the REL8_4_STABLE version that existed on to 2010-03-12, when 8.4.3 was tagged, includes that file. But cvs2git also knows that 8.4.3 does NOT include that file, so it picks the commit on the 8.4.3 branch that most closely matches the contents of the tag (namely, Marc's tag 8.4.3 commit) and then shoves a manufactured commit on top of that to make the contents of the 8.4.3 tag match what actually got tagged. But that manufactured commit is only there to make the tag contents match; it's not actually part of the branch. If the conversion correctly made it.po get added on 2010-05-13 rather than 2010-02-28 then Marc's tag 8.4.3 commit would match the tag contents exactly and no manufactured commit would be created. The effect of all of this is that if someone checks out a git commit between 2010-02-28 and 2010-05-13, it.po will be there, even though file didn't exist on that CVS branch at that time. Max's contention seems to be that this is a CVS problem rather than a cvs2git problem. Perhaps we can do something like cvs update -r REL8_4_STABLE -d SOME_INTERMEDIATE_DATE and see whether that file is there or not. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
On 07/09/10 23:15, Robert Haas wrote: On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4 and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps, but it sure looks wrong. (Magnus, did you check against the 8.4.3 tarball?) I think this is another result of the same basic problem. Since cvs2git thinks it.po was added to REL8_4_STABLE on 2010-02-28 rather than 2010-05-13,the REL8_4_STABLE version that existed on to 2010-03-12, when 8.4.3 was tagged, includes that file. But cvs2git also knows that 8.4.3 does NOT include that file, so it picks the commit on the 8.4.3 branch that most closely matches the contents of the tag (namely, Marc's tag 8.4.3 commit) and then shoves a manufactured commit on top of that to make the contents of the 8.4.3 tag match what actually got tagged. But that manufactured commit is only there to make the tag contents match; it's not actually part of the branch. If the conversion correctly made it.po get added on 2010-05-13 rather than 2010-02-28 then Marc's tag 8.4.3 commit would match the tag contents exactly and no manufactured commit would be created. Yes, this is the correct analysis. The effect of all of this is that if someone checks out a git commit between 2010-02-28 and 2010-05-13, it.po will be there, even though file didn't exist on that CVS branch at that time. Max's contention seems to be that this is a CVS problem rather than a cvs2git problem. Perhaps we can do something like cvs update -r REL8_4_STABLE -d SOME_INTERMEDIATE_DATE and see whether that file is there or not. $ cvs co -r REL8_4_STABLE -D 2010-04-01 pgsql ... $ ls -la pgsql/src/bin/pg_dump/po/it.po -rw-r--r-- 1 maxb maxb 67871 2010-02-19 00:40 pgsql/src/bin/pg_dump/po/it.po It's there. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Robert Haas robertmh...@gmail.com writes: On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4 and not refs/tags/REL8_4_3? I think this is another result of the same basic problem. Since cvs2git thinks it.po was added to REL8_4_STABLE on 2010-02-28 rather than 2010-05-13,the REL8_4_STABLE version that existed on to 2010-03-12, when 8.4.3 was tagged, includes that file. But cvs2git also knows that 8.4.3 does NOT include that file, so it picks the commit on the 8.4.3 branch that most closely matches the contents of the tag (namely, Marc's tag 8.4.3 commit) and then shoves a manufactured commit on top of that to make the contents of the 8.4.3 tag match what actually got tagged. But that manufactured commit is only there to make the tag contents match; it's not actually part of the branch. If the conversion correctly made it.po get added on 2010-05-13 rather than 2010-02-28 then Marc's tag 8.4.3 commit would match the tag contents exactly and no manufactured commit would be created. Hmm. Some further looking in the git log output shows that that manufactured commit is actually the ONLY commit shown as being a predecessor of REL8_4_3. Everything else after 8.4.2 was tagged is shown as reached from refs/tags/REL8_4_4. This is at the least pretty weird, and I have to suppose it's the manufactured commit causing it. It does appear to agree with your explanation: the 8.4.3 state is not part of the branch's main evolution, but is a little side branch all by itself. The effect of all of this is that if someone checks out a git commit between 2010-02-28 and 2010-05-13, it.po will be there, even though file didn't exist on that CVS branch at that time. Yeah, that's what it's doing for me. Max's contention seems to be that this is a CVS problem rather than a cvs2git problem. No doubt. However, the facts on the ground are that it.po is provably not there in REL8_4_0, REL8_4_1, REL8_4_2, or REL8_4_3, and is there in REL8_4_4, and that no commit on the branch touched it before 2010-05-13 (just before 8.4.4). I will be interested to see the argument why cvs2git should consider the sanest translation of these facts to involve adding it.po to the branch after 8.4.2 and removing it again before 8.4.3. regards, tom lane -- 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] git: uh-oh
On 07/09/10 23:20, Max Bowsher wrote: On 07/09/10 23:15, Robert Haas wrote: On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4 and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps, but it sure looks wrong. (Magnus, did you check against the 8.4.3 tarball?) I think this is another result of the same basic problem. Since cvs2git thinks it.po was added to REL8_4_STABLE on 2010-02-28 rather than 2010-05-13,the REL8_4_STABLE version that existed on to 2010-03-12, when 8.4.3 was tagged, includes that file. But cvs2git also knows that 8.4.3 does NOT include that file, so it picks the commit on the 8.4.3 branch that most closely matches the contents of the tag (namely, Marc's tag 8.4.3 commit) and then shoves a manufactured commit on top of that to make the contents of the 8.4.3 tag match what actually got tagged. But that manufactured commit is only there to make the tag contents match; it's not actually part of the branch. If the conversion correctly made it.po get added on 2010-05-13 rather than 2010-02-28 then Marc's tag 8.4.3 commit would match the tag contents exactly and no manufactured commit would be created. Yes, this is the correct analysis. The effect of all of this is that if someone checks out a git commit between 2010-02-28 and 2010-05-13, it.po will be there, even though file didn't exist on that CVS branch at that time. Max's contention seems to be that this is a CVS problem rather than a cvs2git problem. Perhaps we can do something like cvs update -r REL8_4_STABLE -d SOME_INTERMEDIATE_DATE and see whether that file is there or not. $ cvs co -r REL8_4_STABLE -D 2010-04-01 pgsql ... $ ls -la pgsql/src/bin/pg_dump/po/it.po -rw-r--r-- 1 maxb maxb 67871 2010-02-19 00:40 pgsql/src/bin/pg_dump/po/it.po It's there. And, I've just tracked down that this bug was apparently fixed in CVS 1.11.18, released November 2004. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
I wrote: Hmm. Some further looking in the git log output shows that that manufactured commit is actually the ONLY commit shown as being a predecessor of REL8_4_3. Everything else after 8.4.2 was tagged is shown as reached from refs/tags/REL8_4_4. This is at the least pretty weird, and I have to suppose it's the manufactured commit causing it. It does appear to agree with your explanation: the 8.4.3 state is not part of the branch's main evolution, but is a little side branch all by itself. This same pattern can be found repeated in at least ten earlier places in our project history, btw --- just look for commits using the phrase manufactured by cvs2svn to create tag instead of to create branch. The worst example is probably the one for tag REL7_1_BETA, which deletes 70-odd files. regards, tom lane -- 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] git: uh-oh
On 07/09/10 23:34, Tom Lane wrote: No doubt. However, the facts on the ground are that it.po is provably not there in REL8_4_0, REL8_4_1, REL8_4_2, or REL8_4_3, and is there in REL8_4_4, and that no commit on the branch touched it before 2010-05-13 (just before 8.4.4). I will be interested to see the argument why cvs2git should consider the sanest translation of these facts to involve adding it.po to the branch after 8.4.2 and removing it again before 8.4.3. Only that cvs2git isn't quite so smart as to take tags present on a branch as a guideline of when to introduce files that sprung into existence on a branch at an uncertain point. It merely operates by breaking cyclic dependencies between the various events it observes in the CVS repository. In this case, the create branch REL8_4_STABLE operation gets broken into several pieces to fit around the actual revisions involved. Hmm. Now I'm speculating vaguely about how the cycle breaker could be convinced to break branch update commits into as many pieces as possible, instead of as few. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Max Bowsher m...@f2s.com writes: Hmm. Now I'm speculating vaguely about how the cycle breaker could be convinced to break branch update commits into as many pieces as possible, instead of as few. That same thought occurred to me. If it simply didn't aggregate, but treated each such file separately, would we end up with a saner history? We would have more individual manufactured commits, but I think they might be less surprising. regards, tom lane -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 6:34 PM, Tom Lane t...@sss.pgh.pa.us wrote: Hmm. Some further looking in the git log output shows that that manufactured commit is actually the ONLY commit shown as being a predecessor of REL8_4_3. Everything else after 8.4.2 was tagged is shown as reached from refs/tags/REL8_4_4. This is at the least pretty weird, and I have to suppose it's the manufactured commit causing it. It does appear to agree with your explanation: the 8.4.3 state is not part of the branch's main evolution, but is a little side branch all by itself. Yep, that's what it is. The effect of all of this is that if someone checks out a git commit between 2010-02-28 and 2010-05-13, it.po will be there, even though file didn't exist on that CVS branch at that time. Yeah, that's what it's doing for me. Max's contention seems to be that this is a CVS problem rather than a cvs2git problem. No doubt. However, the facts on the ground are that it.po is provably not there in REL8_4_0, REL8_4_1, REL8_4_2, or REL8_4_3, and is there in REL8_4_4, and that no commit on the branch touched it before 2010-05-13 (just before 8.4.4). I will be interested to see the argument why cvs2git should consider the sanest translation of these facts to involve adding it.po to the branch after 8.4.2 and removing it again before 8.4.3. Well, as Max says downthread, cvs -r REL8_4_STABLE -d INTERMEDIATE_DATE apparently shows the file as being there, which is a fairly good argument for his position. I think it's pretty amusing that on this of all projects, where we regularly complain to people about not updating to the latest minor release, we are six minor releases out of date -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
Robert Haas robertmh...@gmail.com writes: Well, as Max says downthread, cvs -r REL8_4_STABLE -d INTERMEDIATE_DATE apparently shows the file as being there, which is a fairly good argument for his position. I haven't tested, but if I understand what Max and Michael are saying about CVS, that operation would probably show the file as being there on *every* date between REL8_4_STABLE splitting off and the actual addition of it.po to the branch. Because CVS isn't paying attention to the evidence of the intermediate tags not being there, either. Nonetheless, having the file pop into being and then disappear again between two observable points seems way too much like quantum physics for my taste. I think it has to be possible for cvs2git to produce a less surprising translation. regards, tom lane -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 7:18 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Well, as Max says downthread, cvs -r REL8_4_STABLE -d INTERMEDIATE_DATE apparently shows the file as being there, which is a fairly good argument for his position. I haven't tested, but if I understand what Max and Michael are saying about CVS, that operation would probably show the file as being there on *every* date between REL8_4_STABLE splitting off and the actual addition of it.po to the branch. Because CVS isn't paying attention to the evidence of the intermediate tags not being there, either. Nonetheless, having the file pop into being and then disappear again between two observable points seems way too much like quantum physics for my taste. I think it has to be possible for cvs2git to produce a less surprising translation. Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't see it in the NEWS file) and that a checkout-by-date shows the file present during the time cvs2git claims it is present, then a less surprising translation wouldn't be a faithful representation of the contents of our CVS repository. One thing I'm not quite clear on is how cvs2git thinks CVS should look given what we actually did vs. how it actually does look, but if our CVS repository is busted maybe we should be looking to fix that rather than complaining about cvs2git. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
Max Bowsher m...@f2s.com writes: And, I've just tracked down that this bug was apparently fixed in CVS 1.11.18, released November 2004. Hrm, what bug exactly? As far as I've gathered from the discussion, this is a fundamental design limitation of CVS, not a fixable bug. regards, tom lane -- 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] git: uh-oh
On 08/09/10 00:47, Tom Lane wrote: Max Bowsher m...@f2s.com writes: And, I've just tracked down that this bug was apparently fixed in CVS 1.11.18, released November 2004. Hrm, what bug exactly? As far as I've gathered from the discussion, this is a fundamental design limitation of CVS, not a fixable bug. The bug that CVS represented addition to a branch in a way which didn't record when it occurred. The way in which it was bludgeoned into the RCS file format was somewhat hacky, but was a successful fix. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
On 08/09/10 00:37, Robert Haas wrote: On Tue, Sep 7, 2010 at 7:18 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Well, as Max says downthread, cvs -r REL8_4_STABLE -d INTERMEDIATE_DATE apparently shows the file as being there, which is a fairly good argument for his position. I haven't tested, but if I understand what Max and Michael are saying about CVS, that operation would probably show the file as being there on *every* date between REL8_4_STABLE splitting off and the actual addition of it.po to the branch. Because CVS isn't paying attention to the evidence of the intermediate tags not being there, either. Nonetheless, having the file pop into being and then disappear again between two observable points seems way too much like quantum physics for my taste. I think it has to be possible for cvs2git to produce a less surprising translation. Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't see it in the NEWS file) and that a checkout-by-date shows the file present during the time cvs2git claims it is present, then a less surprising translation wouldn't be a faithful representation of the contents of our CVS repository. Correct. You'll have to decide whether you wish to represent your current cvs repository, or attempt to doctor things to fix the insanity CVS introduced. One thing I'm not quite clear on is how cvs2git thinks CVS should look given what we actually did vs. how it actually does look, CVS from 1.11.18 kludges things to work right by inserting a file revision on the branch in the dead (deleted) state with the same date as the revision it branched from. This marks identifiably that it didn't exist on the branch to start with, Then, a non-dead revision marks the true addition of the file to the branch. I'm attaching a sample RCS file. but if our CVS repository is busted maybe we should be looking to fix that rather than complaining about cvs2git. A possibility. We'd need a tool which would insert an extra node into the history graph of an RCS file. Unless we can bodge it by using x.y.z.0 as a revision id, it would also need to renumber all the revisions on the branch. Still, cvs2git has code to parse the RCS format, so it's probably achievable without too much work. Max. head1.1; access; symbols b1:1.1.0.2; locks; strict; comment @# @; 1.1 date2010.09.08.00.33.01;author maxb;state Exp; branches 1.1.2.1; next; commitidlO0BL09PCcYPwINu; 1.1.2.1 date2010.09.08.00.33.01;author maxb;state dead; branches; next1.1.2.2; commitidFuoVc28H18LVwINu; 1.1.2.2 date2010.09.08.00.33.17;author maxb;state Exp; branches; next; commitidFuoVc28H18LVwINu; desc @@ 1.1 log @Foo2. @ text @@ 1.1.2.1 log @file b was added on branch b1 on 2010-09-08 00:33:17 + @ text @@ 1.1.2.2 log @Merge. @ text @@ signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Max Bowsher m...@f2s.com writes: On 08/09/10 00:47, Tom Lane wrote: Max Bowsher m...@f2s.com writes: And, I've just tracked down that this bug was apparently fixed in CVS 1.11.18, released November 2004. Hrm, what bug exactly? As far as I've gathered from the discussion, this is a fundamental design limitation of CVS, not a fixable bug. The bug that CVS represented addition to a branch in a way which didn't record when it occurred. The way in which it was bludgeoned into the RCS file format was somewhat hacky, but was a successful fix. Well, good for them. But even if we had updated our server to this version of CVS instantly upon its release, we'd still be looking for a workaround for the problem in cvs2git, because at least half of the instances of this problem in our project history predate November 2004. Do you happen to know details of the format change? Because one possible solution path seems to be to manually patch the desired information into the CVS repository before we run cvs2git. regards, tom lane -- 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] git: uh-oh
Max Bowsher m...@f2s.com writes: On 08/09/10 00:37, Robert Haas wrote: Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't see it in the NEWS file) and that a checkout-by-date shows the file present during the time cvs2git claims it is present, then a less surprising translation wouldn't be a faithful representation of the contents of our CVS repository. Correct. You'll have to decide whether you wish to represent your current cvs repository, or attempt to doctor things to fix the insanity CVS introduced. Well, even if the goal is to faithfully represent the bogus history shown by CVS, cvs2git isn't doing a good job of it. In the case of src/bin/pg_dump/po/it.po, the CVS history claims that the version added to REL8_4_STABLE on 2010-05-13 is a child of the mainline version 1.7 committed on 2010-02-19. Therefore, according to CVS the file existed on the branch from 2010-02-19, not 2010-02-28 as claimed by the cvs2git translation. I did some cvs co operations to check this and cvs does indeed retrieve the file between 02-19 and 02-28, but not before 02-19. So I don't think you can defend the cvs2git behavior by claiming that it's an exact translation. Right at the moment, though, I'm more interested in the idea of patching the CVS repository to make the problem go away. regards, tom lane -- 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] git: uh-oh
On Tue, Sep 7, 2010 at 8:54 PM, Tom Lane t...@sss.pgh.pa.us wrote: Max Bowsher m...@f2s.com writes: On 08/09/10 00:37, Robert Haas wrote: Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't see it in the NEWS file) and that a checkout-by-date shows the file present during the time cvs2git claims it is present, then a less surprising translation wouldn't be a faithful representation of the contents of our CVS repository. Correct. You'll have to decide whether you wish to represent your current cvs repository, or attempt to doctor things to fix the insanity CVS introduced. Well, even if the goal is to faithfully represent the bogus history shown by CVS, cvs2git isn't doing a good job of it. In the case of src/bin/pg_dump/po/it.po, the CVS history claims that the version added to REL8_4_STABLE on 2010-05-13 is a child of the mainline version 1.7 committed on 2010-02-19. Therefore, according to CVS the file existed on the branch from 2010-02-19, not 2010-02-28 as claimed by the cvs2git translation. I did some cvs co operations to check this and cvs does indeed retrieve the file between 02-19 and 02-28, but not before 02-19. So I don't think you can defend the cvs2git behavior by claiming that it's an exact translation. Right at the moment, though, I'm more interested in the idea of patching the CVS repository to make the problem go away. If we decide we're actually going to fix this problem, then I think the definition of fixed should be that every tag of the form RELx_y_z is an ancestor of the branch RELx_y_STABLE. Maybe it would be worth writing a sanity check along those lines. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
Max Bowsher m...@f2s.com writes: On 08/09/10 00:37, Robert Haas wrote: but if our CVS repository is busted maybe we should be looking to fix that rather than complaining about cvs2git. A possibility. We'd need a tool which would insert an extra node into the history graph of an RCS file. Unless we can bodge it by using x.y.z.0 as a revision id, it would also need to renumber all the revisions on the branch. Still, cvs2git has code to parse the RCS format, so it's probably achievable without too much work. I did some experimentation with manual surgery on (a copy of ;-)) it.po,v and found that x.y.z.0 does seem to work; at least CVS isn't obviously unhappy with it. So transformations as simple as illustrated below might be enough to fix this. I do not have a copy of cvs2git at hand to see what it does with this, though. regards, tom lane *** ./it.po,v~ Tue Sep 7 22:56:48 2010 --- ./it.po,v Tue Sep 7 23:01:47 2010 *** *** 173,179 1.7 date 2010.02.19.00.40.04;author petere; state Exp; branches ! 1.7.6.1; next 1.6; 1.6 --- 173,179 1.7 date 2010.02.19.00.40.04;author petere; state Exp; branches ! 1.7.6.0; next 1.6; 1.6 *** *** 206,211 --- 206,216 branches; next ; + 1.7.6.0 + date 2010.02.19.00.40.04;author petere; state dead; + branches; + next 1.7.6.1; + 1.7.6.1 date 2010.05.13.10.50.03;author petere; state Exp; branches; *** *** 3636,3641 --- 3641,3654 @ + 1.7.6.0 + log + @log addition on branch + @ + text + @@ + + 1.7.6.1 log @Translation update -- 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] git: uh-oh
On Sun, Sep 5, 2010 at 10:43, Max Bowsher m...@f2s.com wrote: On 05/09/10 03:55, Robert Haas wrote: On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher m...@f2s.com wrote: Can you post the repo you ended up with somewhere? Well, it's a Bazaar repository at the moment :-) But, I'll re-run it targetting git, and push it somewhere. github? anywhere better? No, that's fine. I think we should start a git repository somewhere containing the precise conversion recipe - i.e.: * cvs2git options file * cvs2git invocation command line * all scripts that massage the CVS repository before conversion, or the Git repository afterwards Yeah, that would be great. For both, see http://github.com/maxb As I've previously posted, the stuff I've done is all on http://github.com/mhagander/pg_githooks/tree/master/migration/ But I have to confess I haven't put up the latest versions of the scripts I've been using yet - I wanted to narrow down the problems first.. -- 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] git: uh-oh
On Sun, Sep 5, 2010 at 04:55, Robert Haas robertmh...@gmail.com wrote: On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher m...@f2s.com wrote: and the result is that things are looking pretty clean :-) Hey, that's great. But I wonder why Magnus got a different result. This is the first time I've posted these incantations for excising the unwanted history, so he would not have been using them. Well, he did something fairly similar. Not sure if it was exactly the same. No. I used cvs admin, not rcs. The specific commands I ran were the following (and I'm pretty darn sure I posted this before): cd pgsql/src/backend/parser cvs admin -o 2.90.2.1:2.90.2.2 gram.c cvs admin -o 2.89: gram.c cd ../../interfaces/ecpg/preproc cvs admin -o 1.5.2.1:1.5.2.2 pgc.c cvs admin -o 1.3: pgc.c cvs admin -o 1.11.2.1:1.11.2.2 preproc.c cvs admin -o 1.7: preproc.c I would assume cvs just runs rcs commands behind the scenes, but I confess knowing way too little about that stuff to be sure ;) I'll be happy to re-run with the rcs commands instead. Can you post the repo you ended up with somewhere? Well, it's a Bazaar repository at the moment :-) But, I'll re-run it targetting git, and push it somewhere. github? anywhere better? No, that's fine. Yes, it's fine - just please be sure to remove the repository once we're done with the master conversion, so people don't end up accidentally cloning an incorrect one :D -- 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] git: uh-oh
On Mon, Sep 6, 2010 at 06:09, Tom Lane t...@sss.pgh.pa.us wrote: Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: I suspect what it's doing is attributing the branch creation to the user who makes the first commit on the branch for that file. In general I'd expect that to give a reasonable result --- better than choosing a guaranteed-to-be-wrong constant value anyway ;-) On the contrary, I prefer an obvious indication of I don't know to a value that might appear to be authoritative but is really just a guess. It could be that one user copied the file verbatim to the branch and a second user changed the file as part of an unrelated change. Hm, I see. The default default value for these commits is cvs2svn (in your case cvs2git would probably be more appropriate), which I like because it makes it clearer than pgsql that the commit was generated as part of a conversion. If we can set it to a value different from any actual committer name, that would be a good thing to do. I intentionally picked the pgsql user because AFAIK that's what we've been previously using for commits that aren't commits. I figured the repository would be cleaner with just one such pseudo-user rather than two. But it's a trivial change - it just needs a name and an email address (which doesn't have to actually work, of course) -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Mon, Sep 6, 2010 at 06:09, Tom Lane t...@sss.pgh.pa.us wrote: If we can set it to a value different from any actual committer name, that would be a good thing to do. I intentionally picked the pgsql user because AFAIK that's what we've been previously using for commits that aren't commits. Uh, no, not so. Marc used to use that ID for commits related to pushing new versions. It's been retired, but there's nothing un-real about the commits under that ID. Please pick something else. I thought the suggestion of cvs2git was a good one. regards, tom lane -- 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] git: uh-oh
On Mon, Sep 6, 2010 at 15:37, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Mon, Sep 6, 2010 at 06:09, Tom Lane t...@sss.pgh.pa.us wrote: If we can set it to a value different from any actual committer name, that would be a good thing to do. I intentionally picked the pgsql user because AFAIK that's what we've been previously using for commits that aren't commits. Uh, no, not so. Marc used to use that ID for commits related to pushing new versions. It's been retired, but there's nothing un-real about the commits under that ID. Please pick something else. I thought the suggestion of cvs2git was a good one. Ok, I'll switch to that - no problem. Should the name really be PostgreSQL Daemon then? (Because that's what it's called on the cvs box, but that's probably just a coincidence) -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Mon, Sep 6, 2010 at 15:37, Tom Lane t...@sss.pgh.pa.us wrote: Uh, no, not so. Marc used to use that ID for commits related to pushing new versions. It's been retired, but there's nothing un-real about the commits under that ID. Please pick something else. I thought the suggestion of cvs2git was a good one. Ok, I'll switch to that - no problem. Should the name really be PostgreSQL Daemon then? (Because that's what it's called on the cvs box, but that's probably just a coincidence) That seems to be the name that shows up in the pgsql-committers archives, so I'd say we should stick with it. We're not in the business of redefining history here. regards, tom lane -- 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] git: uh-oh
I wrote: Michael Haggerty mhag...@alum.mit.edu writes: On the contrary, I prefer an obvious indication of I don't know to a value that might appear to be authoritative but is really just a guess. It could be that one user copied the file verbatim to the branch and a second user changed the file as part of an unrelated change. Hm, I see. Actually, no I don't see. That sort of history might be possible in some SCMs, but how is it possible in CVS? The only way to get a file into a back branch is cvs add then cvs commit, and the commit is recorded, even if the file exactly matches what was in HEAD. There is an example in contrib/xml2/sql/xml2.sql. It was added to HEAD on 2010-02-28, and then the exact same file was back-patched into 8.4 on 2010-03-01, and the back-patch is visible as a separate action according to http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/contrib/xml2/sql/xml2.sql So I don't see why cvs2git has to produce a manufactured commit here. It's also a bit distressing that the manufactured commit bogusly includes a totally unrelated file: commit b36518cb880bb236496ec3e505ede4001ce56157 Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sun Feb 28 21:32:02 2010 + This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'. Cherrypick from master 2010-02-28 21:31:57 UTC Tom Lane t...@sss.pgh.pa.us 'Fix up memory management problems in contrib/xml2.': contrib/xml2/expected/xml2.out contrib/xml2/sql/xml2.sql src/bin/pg_dump/po/it.po (This is from the REL8_4_STABLE history in Max's repository.) The cherrypicked commit certainly did not include anything in pg_dump/po/it.po, so what happened here? regards, tom lane -- 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] git: uh-oh
Tom Lane wrote: I wrote: Michael Haggerty mhag...@alum.mit.edu writes: On the contrary, I prefer an obvious indication of I don't know to a value that might appear to be authoritative but is really just a guess. It could be that one user copied the file verbatim to the branch and a second user changed the file as part of an unrelated change. Hm, I see. Actually, no I don't see. That sort of history might be possible in some SCMs, but how is it possible in CVS? The only way to get a file into a back branch is cvs add then cvs commit, and the commit is recorded, even if the file exactly matches what was in HEAD. No, it is also possible to use cvs tag -b REL8_4_STABLE filename. In this case the file as it appears on the current branch is added to the specified branch, but CVS records no commit, author, or timestamp. It's also a bit distressing that the manufactured commit bogusly includes a totally unrelated file: commit b36518cb880bb236496ec3e505ede4001ce56157 Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sun Feb 28 21:32:02 2010 + This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'. Cherrypick from master 2010-02-28 21:31:57 UTC Tom Lane t...@sss.pgh.pa.us 'Fix up memory management problems in contrib/xml2.': contrib/xml2/expected/xml2.out contrib/xml2/sql/xml2.sql src/bin/pg_dump/po/it.po (This is from the REL8_4_STABLE history in Max's repository.) The cherrypicked commit certainly did not include anything in pg_dump/po/it.po, so what happened here? Given that adding a branch tag to a file leaves behind so little metainformation, cvs2svn has almost no information on which to base its decision of what file branchings to group together. So it groups as many as possible together consistent with the timestamps of the commits preceding and following the branching. Michael -- 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] git: uh-oh
Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: Actually, no I don't see. That sort of history might be possible in some SCMs, but how is it possible in CVS? The only way to get a file into a back branch is cvs add then cvs commit, and the commit is recorded, even if the file exactly matches what was in HEAD. No, it is also possible to use cvs tag -b REL8_4_STABLE filename. In this case the file as it appears on the current branch is added to the specified branch, but CVS records no commit, author, or timestamp. So, if we're prepared to assert that we've never done that, could we have an option to cvs2git that is willing to use the first commit on a branch to represent the act of adding the file to the branch? regards, tom lane -- 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] git: uh-oh
On Mon, Sep 06, 2010 at 05:41:06AM +0200, Michael Haggerty wrote: Tom Lane wrote: Michael Haggerty mhag...@alum.mit.edu writes: CVS does not record when a branch was created or by whom. If a git commit has to be created for such events, cvs2git attributes them to a configurable username, which Max has set to be pgsql. It chooses the latest possible timestamp that is consistent with other (timestamped) changesets that depend on it. Does cvs2cl do something better? If so, how? I suspect what it's doing is attributing the branch creation to the user who makes the first commit on the branch for that file. In general I'd expect that to give a reasonable result --- better than choosing a guaranteed-to-be-wrong constant value anyway ;-) On the contrary, I prefer an obvious indication of I don't know Surely you jest! Databases have no possible way of recording ignorance (other than NULL, that is ;) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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] git: uh-oh
On 05/09/10 03:55, Robert Haas wrote: On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher m...@f2s.com wrote: Can you post the repo you ended up with somewhere? Well, it's a Bazaar repository at the moment :-) But, I'll re-run it targetting git, and push it somewhere. github? anywhere better? No, that's fine. I think we should start a git repository somewhere containing the precise conversion recipe - i.e.: * cvs2git options file * cvs2git invocation command line * all scripts that massage the CVS repository before conversion, or the Git repository afterwards Yeah, that would be great. For both, see http://github.com/maxb Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Max Bowsher m...@f2s.com writes: On 05/09/10 03:55, Robert Haas wrote: Can you post the repo you ended up with somewhere? For both, see http://github.com/maxb I took the trouble to run through a mechanical diff of this version's REL8_3_STABLE log history versus what I get from cvs2cl. Several cvs2cl bug fixes later :-(, I have a pretty darn close match. There are some discrepancies in what the two tools choose to regard as a single commit versus successive commits with the same log message, but that's probably OK. The only real gripe I can find to make is that in the cases where a file is added to a back branch, the manufactured commit is invariably blamed on committer pgsql. Can't we arrange to blame it on the person who actually added the file? (I wonder whether this is related to the fact that the same commits have made-up timestamps, which we already griped about.) regards, tom lane -- 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] git: uh-oh
Tom Lane wrote: Max Bowsher m...@f2s.com writes: For both, see http://github.com/maxb [...] The only real gripe I can find to make is that in the cases where a file is added to a back branch, the manufactured commit is invariably blamed on committer pgsql. Can't we arrange to blame it on the person who actually added the file? (I wonder whether this is related to the fact that the same commits have made-up timestamps, which we already griped about.) CVS does not record when a branch was created or by whom. If a git commit has to be created for such events, cvs2git attributes them to a configurable username, which Max has set to be pgsql. It chooses the latest possible timestamp that is consistent with other (timestamped) changesets that depend on it. Does cvs2cl do something better? If so, how? Michael -- 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] git: uh-oh
Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: [...] The only real gripe I can find to make is that in the cases where a file is added to a back branch, the manufactured commit is invariably blamed on committer pgsql. Can't we arrange to blame it on the person who actually added the file? (I wonder whether this is related to the fact that the same commits have made-up timestamps, which we already griped about.) CVS does not record when a branch was created or by whom. If a git commit has to be created for such events, cvs2git attributes them to a configurable username, which Max has set to be pgsql. It chooses the latest possible timestamp that is consistent with other (timestamped) changesets that depend on it. Does cvs2cl do something better? If so, how? I suspect what it's doing is attributing the branch creation to the user who makes the first commit on the branch for that file. In general I'd expect that to give a reasonable result --- better than choosing a guaranteed-to-be-wrong constant value anyway ;-) regards, tom lane -- 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] git: uh-oh
Tom Lane wrote: Michael Haggerty mhag...@alum.mit.edu writes: CVS does not record when a branch was created or by whom. If a git commit has to be created for such events, cvs2git attributes them to a configurable username, which Max has set to be pgsql. It chooses the latest possible timestamp that is consistent with other (timestamped) changesets that depend on it. Does cvs2cl do something better? If so, how? I suspect what it's doing is attributing the branch creation to the user who makes the first commit on the branch for that file. In general I'd expect that to give a reasonable result --- better than choosing a guaranteed-to-be-wrong constant value anyway ;-) On the contrary, I prefer an obvious indication of I don't know to a value that might appear to be authoritative but is really just a guess. It could be that one user copied the file verbatim to the branch and a second user changed the file as part of an unrelated change. The default default value for these commits is cvs2svn (in your case cvs2git would probably be more appropriate), which I like because it makes it clearer than pgsql that the commit was generated as part of a conversion. Michael -- 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] git: uh-oh
Michael Haggerty mhag...@alum.mit.edu writes: Tom Lane wrote: I suspect what it's doing is attributing the branch creation to the user who makes the first commit on the branch for that file. In general I'd expect that to give a reasonable result --- better than choosing a guaranteed-to-be-wrong constant value anyway ;-) On the contrary, I prefer an obvious indication of I don't know to a value that might appear to be authoritative but is really just a guess. It could be that one user copied the file verbatim to the branch and a second user changed the file as part of an unrelated change. Hm, I see. The default default value for these commits is cvs2svn (in your case cvs2git would probably be more appropriate), which I like because it makes it clearer than pgsql that the commit was generated as part of a conversion. If we can set it to a value different from any actual committer name, that would be a good thing to do. regards, tom lane -- 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] git: uh-oh
On 03/09/10 03:34, Max Bowsher wrote: Robert Haas wrote: On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: What weirdness, exactly, are you discussing now? I've lost track of which problem(s) are still unresolved. Lots of commits that look like this: commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sat Dec 2 08:36:42 2006 + This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'. Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon webmas...@postgresql.org '' Delete: src/backend/parser/gram.c src/interfaces/ecpg/preproc/pgc.c src/interfaces/ecpg/preproc/preproc.c I have a test conversion running (well, a test conversion to bzr, because I like qbzr so much more than gitk) and will report back. OK, so I ran a conversion first run the following: for r in 2.89 2.90 2.91; do rcs -x,v -sdead:$r ./cvsroot/pgsql/src/backend/parser/Attic/gram.c ; done for r in 1.3 1.4 1.5 1.6; do rcs -x,v -sdead:$r ./cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c ; done for r in 1.7 1.8 1.9 1.10 1.11 1.12; do rcs -x,v -sdead:$r ./cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/preproc.c ; done (in essence pretend that these revisions deleted the file instead of changing it) The conversion looks nicer, but I notice we have a similar issue to those three with src/interfaces/ecpg/preproc/y.tab.h in release tags/branches up to and including 7.4. So, I'm going to try running another attempt additionally doing: for r in 1.3 1.4 1.5 1.6 1.7 1.8; do rcs -x,v -sdead:$r ./cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/y.tab.h ; done ... churn churn churn ... and the result is that things are looking pretty clean :-) You now need to decide if you can live with throwing away a little bit of history for those four files to get a cleaner conversion. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
On Sat, Sep 4, 2010 at 3:22 AM, Max Bowsher m...@f2s.com wrote: and the result is that things are looking pretty clean :-) Hey, that's great. But I wonder why Magnus got a different result. Can you post the repo you ended up with somewhere? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
On 04/09/10 12:24, Robert Haas wrote: On Sat, Sep 4, 2010 at 3:22 AM, Max Bowsher m...@f2s.com wrote: and the result is that things are looking pretty clean :-) Hey, that's great. But I wonder why Magnus got a different result. This is the first time I've posted these incantations for excising the unwanted history, so he would not have been using them. Can you post the repo you ended up with somewhere? Well, it's a Bazaar repository at the moment :-) But, I'll re-run it targetting git, and push it somewhere. github? anywhere better? I think we should start a git repository somewhere containing the precise conversion recipe - i.e.: * cvs2git options file * cvs2git invocation command line * all scripts that massage the CVS repository before conversion, or the Git repository afterwards Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Max Bowsher m...@f2s.com writes: I think we should start a git repository somewhere containing the precise conversion recipe - i.e.: * cvs2git options file * cvs2git invocation command line * all scripts that massage the CVS repository before conversion, or the Git repository afterwards I dunno if we need a git repository, but I definitely want to see the process spelled out with 100% clarity, both for archival purposes and to make sure there's a checklist for doing the live conversion when we next try to pull the trigger. regards, tom lane -- 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] git: uh-oh
On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher m...@f2s.com wrote: and the result is that things are looking pretty clean :-) Hey, that's great. But I wonder why Magnus got a different result. This is the first time I've posted these incantations for excising the unwanted history, so he would not have been using them. Well, he did something fairly similar. Not sure if it was exactly the same. Can you post the repo you ended up with somewhere? Well, it's a Bazaar repository at the moment :-) But, I'll re-run it targetting git, and push it somewhere. github? anywhere better? No, that's fine. I think we should start a git repository somewhere containing the precise conversion recipe - i.e.: * cvs2git options file * cvs2git invocation command line * all scripts that massage the CVS repository before conversion, or the Git repository afterwards Yeah, that would be great. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
On Thu, Sep 2, 2010 at 05:13, Robert Haas robertmh...@gmail.com wrote: On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander mag...@hagander.net wrote: That definitely didn't fix it, although I'm not quite sure why. Can you throw the modified CVS you ran this off of up somewhere I can rsync it? no rsync server on that box, but I put up a tarball for you at http://www.hagander.net/pgsql/cvsrepo.tgz OK, color me baffled. I looked at gram.c and I believe you obsoleted the right revs. The only difference I see between this and some other random deleted file is that it has a couple of tags pointing to revs that don't exist any more, but I can't see how that would cause the observed weirdness. Well, I can try removing those to see what happens and run again.. Which tags and where? (and how do I actually remove them :P) -- 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] git: uh-oh
Robert Haas wrote: On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander mag...@hagander.net wrote: That definitely didn't fix it, although I'm not quite sure why. Can you throw the modified CVS you ran this off of up somewhere I can rsync it? no rsync server on that box, but I put up a tarball for you at http://www.hagander.net/pgsql/cvsrepo.tgz OK, color me baffled. I looked at gram.c and I believe you obsoleted the right revs. The only difference I see between this and some other random deleted file is that it has a couple of tags pointing to revs that don't exist any more, but I can't see how that would cause the observed weirdness. What weirdness, exactly, are you discussing now? I've lost track of which problem(s) are still unresolved. Michael -- 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] git: uh-oh
On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: Robert Haas wrote: On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander mag...@hagander.net wrote: That definitely didn't fix it, although I'm not quite sure why. Can you throw the modified CVS you ran this off of up somewhere I can rsync it? no rsync server on that box, but I put up a tarball for you at http://www.hagander.net/pgsql/cvsrepo.tgz OK, color me baffled. I looked at gram.c and I believe you obsoleted the right revs. The only difference I see between this and some other random deleted file is that it has a couple of tags pointing to revs that don't exist any more, but I can't see how that would cause the observed weirdness. What weirdness, exactly, are you discussing now? I've lost track of which problem(s) are still unresolved. Lots of commits that look like this: commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sat Dec 2 08:36:42 2006 + This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'. Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon webmas...@postgresql.org '' Delete: src/backend/parser/gram.c src/interfaces/ecpg/preproc/pgc.c src/interfaces/ecpg/preproc/preproc.c It seems there's something that cvs(2svn) doesn't like about the history of those files. Magnus tried obsoleting the revisions that show up as modifications of the dead revision, which seems to make that history basically identical to the histories of other files that are handled properly, but evidently there's still something wonky going on. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
Robert Haas wrote: On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: What weirdness, exactly, are you discussing now? I've lost track of which problem(s) are still unresolved. Lots of commits that look like this: commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sat Dec 2 08:36:42 2006 + This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'. Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon webmas...@postgresql.org '' Delete: src/backend/parser/gram.c src/interfaces/ecpg/preproc/pgc.c src/interfaces/ecpg/preproc/preproc.c I addressed that problem in this email: http://archives.postgresql.org/pgsql-hackers/2010-08/msg01819.php Summary: it is caused by a known weakness in cvs2svn's branch-parent-choosing code that would be difficult to solve. But it just occurred to me--the script contrib/git-move-refs.py is supposed to fix problems like this. Have you run this script against your git repository? (Caveat: I am not very familiar with the script, which was contributed by a user. Please check the results carefully and let us know how it works for you.) Michael -- 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] git: uh-oh
On 02/09/10 14:40, Michael Haggerty wrote: Robert Haas wrote: On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: What weirdness, exactly, are you discussing now? I've lost track of which problem(s) are still unresolved. Lots of commits that look like this: commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sat Dec 2 08:36:42 2006 + This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'. Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon webmas...@postgresql.org '' Delete: src/backend/parser/gram.c src/interfaces/ecpg/preproc/pgc.c src/interfaces/ecpg/preproc/preproc.c I addressed that problem in this email: http://archives.postgresql.org/pgsql-hackers/2010-08/msg01819.php Summary: it is caused by a known weakness in cvs2svn's branch-parent-choosing code that would be difficult to solve. But it just occurred to me--the script contrib/git-move-refs.py is supposed to fix problems like this. Have you run this script against your git repository? (Caveat: I am not very familiar with the script, which was contributed by a user. Please check the results carefully and let us know how it works for you.) Moving refs can't possibly splice out branch creation commits. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Max Bowsher wrote: On 02/09/10 14:40, Michael Haggerty wrote: Robert Haas wrote: On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: What weirdness, exactly, are you discussing now? I've lost track of which problem(s) are still unresolved. Lots of commits that look like this: commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sat Dec 2 08:36:42 2006 + This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'. Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon webmas...@postgresql.org '' Delete: src/backend/parser/gram.c src/interfaces/ecpg/preproc/pgc.c src/interfaces/ecpg/preproc/preproc.c I addressed that problem in this email: http://archives.postgresql.org/pgsql-hackers/2010-08/msg01819.php Summary: it is caused by a known weakness in cvs2svn's branch-parent-choosing code that would be difficult to solve. But it just occurred to me--the script contrib/git-move-refs.py is supposed to fix problems like this. Have you run this script against your git repository? (Caveat: I am not very familiar with the script, which was contributed by a user. Please check the results carefully and let us know how it works for you.) Moving refs can't possibly splice out branch creation commits. Max, My understanding was that the problem is not that the branches are created, but that they are created from a non-optimal starting point, making it necessary for each of them to be doctored using a fixup commit. Since the tree contents following the first branch commit is identical to the tree contents on trunk one commit later, moving the branch tags will give the same branch contents without the need for branch fixup commits, and the old (branch-fixed) commits, no longer being referenced, will be garbage collected at the next git gc. Why don't you think this will work? Michael -- 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] git: uh-oh
On 02/09/10 16:44, Michael Haggerty wrote: Max Bowsher wrote: On 02/09/10 14:40, Michael Haggerty wrote: Robert Haas wrote: On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty mhag...@alum.mit.edu wrote: What weirdness, exactly, are you discussing now? I've lost track of which problem(s) are still unresolved. Lots of commits that look like this: commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb Author: PostgreSQL Daemon webmas...@postgresql.org Date: Sat Dec 2 08:36:42 2006 + This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'. Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon webmas...@postgresql.org '' Delete: src/backend/parser/gram.c src/interfaces/ecpg/preproc/pgc.c src/interfaces/ecpg/preproc/preproc.c I addressed that problem in this email: http://archives.postgresql.org/pgsql-hackers/2010-08/msg01819.php Summary: it is caused by a known weakness in cvs2svn's branch-parent-choosing code that would be difficult to solve. But it just occurred to me--the script contrib/git-move-refs.py is supposed to fix problems like this. Have you run this script against your git repository? (Caveat: I am not very familiar with the script, which was contributed by a user. Please check the results carefully and let us know how it works for you.) Moving refs can't possibly splice out branch creation commits. Max, My understanding was that the problem is not that the branches are created, but that they are created from a non-optimal starting point, making it necessary for each of them to be doctored using a fixup commit. Since the tree contents following the first branch commit is identical to the tree contents on trunk one commit later, moving the branch tags will give the same branch contents without the need for branch fixup commits, and the old (branch-fixed) commits, no longer being referenced, will be garbage collected at the next git gc. Why don't you think this will work? You can't move a branchpoint after there are commits on the branch. I'm pretty certain there will be commits on the REL8_2_STABLE branch :-) Also, IIUC, this isn't the one commit later version of the problem - it's a case of, for a period of *years*, the RCS files for these three files claim they exist on trunk but no branches branching off trunk during this period. I am exploring the option of setting the unwanted revisions of the files to the dead state (removing them outright doesn't work, since they have a branch from one of the revisions in question.) I have a test conversion running (well, a test conversion to bzr, because I like qbzr so much more than gitk) and will report back. Max. signature.asc Description: OpenPGP digital signature
Re: [HACKERS] git: uh-oh
Max Bowsher wrote: On 02/09/10 16:44, Michael Haggerty wrote: My understanding was that the problem is not that the branches are created, but that they are created from a non-optimal starting point, making it necessary for each of them to be doctored using a fixup commit. Since the tree contents following the first branch commit is identical to the tree contents on trunk one commit later, moving the branch tags will give the same branch contents without the need for branch fixup commits, and the old (branch-fixed) commits, no longer being referenced, will be garbage collected at the next git gc. Why don't you think this will work? You can't move a branchpoint after there are commits on the branch. I'm pretty certain there will be commits on the REL8_2_STABLE branch :-) Good point. In the case of git, the branchpoint for a branch with commits could be moved using grafts and then baked in using git filter-branch. But you are right that this is beyond the abilities of contrib/git-move-refs.py, harder to justify, and wouldn't help in the current case given your next point. Also, IIUC, this isn't the one commit later version of the problem - it's a case of, for a period of *years*, the RCS files for these three files claim they exist on trunk but no branches branching off trunk during this period. I didn't realize that the anomaly was so long-lived. I am exploring the option of setting the unwanted revisions of the files to the dead state (removing them outright doesn't work, since they have a branch from one of the revisions in question.) That sounds promising. If it doesn't work, perhaps manually changing the timestamps on the trunk revisions to an earlier date would help isolate the problem and allow the branches to sprout from the post-delete revision... Thanks for the explanation. Michael -- 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] git: uh-oh
On Wed, Sep 1, 2010 at 02:33, Robert Haas robertmh...@gmail.com wrote: On Tue, Aug 31, 2010 at 5:07 PM, Magnus Hagander mag...@hagander.net wrote: On Tue, Aug 31, 2010 at 19:46, Magnus Hagander mag...@hagander.net wrote: On Tue, Aug 31, 2010 at 19:44, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: Ok. I've got a new migration runinng. Here's the revisions removed: RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v deleting revision 2.88 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c,v deleting revision 1.2 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/preproc.c,v deleting revision 1.6 Hmm, it looks like you deleted the file deletion events (the versions cited above). Not sure this is the right thing. Check to see if the files are still there according to the converted git history ... Oh, drat. That's right. It shouldn't have been inclusive :S I'll abort the conversion and run it again :) Ok, I've pushed a clone of the new repository with these modifications to: http://git.postgresql.org/gitweb?p=git-migration-test.git;a=summary Haven't had the time to dig into it yet, so please go ahead anybody who wants to :-) That definitely didn't fix it, although I'm not quite sure why. Can you throw the modified CVS you ran this off of up somewhere I can rsync it? no rsync server on that box, but I put up a tarball for you at http://www.hagander.net/pgsql/cvsrepo.tgz -- 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] git: uh-oh
On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander mag...@hagander.net wrote: That definitely didn't fix it, although I'm not quite sure why. Can you throw the modified CVS you ran this off of up somewhere I can rsync it? no rsync server on that box, but I put up a tarball for you at http://www.hagander.net/pgsql/cvsrepo.tgz OK, color me baffled. I looked at gram.c and I believe you obsoleted the right revs. The only difference I see between this and some other random deleted file is that it has a couple of tags pointing to revs that don't exist any more, but I can't see how that would cause the observed weirdness. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
On Mon, Aug 30, 2010 at 05:03, Robert Haas robertmh...@gmail.com wrote: On Wed, Aug 25, 2010 at 2:39 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Aug 25, 2010 at 1:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: The fact that the file was modified twice after being removed at rev 2.88 seems really wacko. Are you sure that's not contributing to what we're seeing here? Yeah, that was discussed in the earlier git-conversion thread that I pointed to. We never did figure out how that happened, though I speculated it might have been due to weirdness in Vadim's local checkout. Is it possible to just delete those two revisions from the CVS repository, and if so would it help? We certainly don't need 'em. cvs admin -o ? Magnus, is this something that you can try? Prune those could of wonky revisions after the delete and before the re-add prior to running the conversion, and see how that comes out? Yes, definitely. Do we have list of exactly which revisions it is, or a good way to find it? Other than random browsing of the history? :-) -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: On Mon, Aug 30, 2010 at 05:03, Robert Haas robertmh...@gmail.com wrote: cvs admin -o ? Magnus, is this something that you can try? Prune those could of wonky revisions after the delete and before the re-add prior to running the conversion, and see how that comes out? Yes, definitely. Do we have list of exactly which revisions it is, or a good way to find it? Other than random browsing of the history? :-) I think the files in question are these: 2007-04-16 21:05 tgl * src/: backend/parser/gram.c, interfaces/ecpg/preproc/pgc.c, interfaces/ecpg/preproc/preproc.c: Temporarily re-add derived files, in hopes of straightening out their CVS status. 2007-04-16 21:06 tgl * src/: backend/parser/gram.c, interfaces/ecpg/preproc/pgc.c, interfaces/ecpg/preproc/preproc.c: And remove 'em again ... Look at the histories of these in cvsweb, and try to zap the versions that are later than the first FILE REMOVED event. regards, tom lane -- 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] git: uh-oh
On Tue, Aug 31, 2010 at 17:12, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: On Mon, Aug 30, 2010 at 05:03, Robert Haas robertmh...@gmail.com wrote: cvs admin -o ? Magnus, is this something that you can try? Prune those could of wonky revisions after the delete and before the re-add prior to running the conversion, and see how that comes out? Yes, definitely. Do we have list of exactly which revisions it is, or a good way to find it? Other than random browsing of the history? :-) I think the files in question are these: 2007-04-16 21:05 tgl * src/: backend/parser/gram.c, interfaces/ecpg/preproc/pgc.c, interfaces/ecpg/preproc/preproc.c: Temporarily re-add derived files, in hopes of straightening out their CVS status. 2007-04-16 21:06 tgl * src/: backend/parser/gram.c, interfaces/ecpg/preproc/pgc.c, interfaces/ecpg/preproc/preproc.c: And remove 'em again ... Look at the histories of these in cvsweb, and try to zap the versions that are later than the first FILE REMOVED event. Ok. I've got a new migration runinng. Here's the revisions removed: RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v deleting revision 2.90.2.1 deleting revision 2.90.2.2 done RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v deleting revision 2.92 deleting revision 2.91 deleting revision 2.90 deleting revision 2.89 deleting revision 2.88 done RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c,v deleting revision 1.5.2.1 deleting revision 1.5.2.2 done RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c,v deleting revision 1.7 deleting revision 1.6 deleting revision 1.5 deleting revision 1.4 deleting revision 1.3 deleting revision 1.2 done RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/preproc.c,v deleting revision 1.11.2.1 deleting revision 1.11.2.2 done RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/preproc.c,v deleting revision 1.13 deleting revision 1.12 deleting revision 1.11 deleting revision 1.10 deleting revision 1.9 deleting revision 1.8 deleting revision 1.7 deleting revision 1.6 done -- 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] git: uh-oh
Magnus Hagander mag...@hagander.net writes: Ok. I've got a new migration runinng. Here's the revisions removed: RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v deleting revision 2.88 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c,v deleting revision 1.2 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/preproc.c,v deleting revision 1.6 Hmm, it looks like you deleted the file deletion events (the versions cited above). Not sure this is the right thing. Check to see if the files are still there according to the converted git history ... regards, tom lane -- 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] git: uh-oh
On Tue, Aug 31, 2010 at 19:44, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: Ok. I've got a new migration runinng. Here's the revisions removed: RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v deleting revision 2.88 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c,v deleting revision 1.2 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/preproc.c,v deleting revision 1.6 Hmm, it looks like you deleted the file deletion events (the versions cited above). Not sure this is the right thing. Check to see if the files are still there according to the converted git history ... Oh, drat. That's right. It shouldn't have been inclusive :S I'll abort the conversion and run it again :) -- 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] git: uh-oh
On Tue, Aug 31, 2010 at 19:46, Magnus Hagander mag...@hagander.net wrote: On Tue, Aug 31, 2010 at 19:44, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: Ok. I've got a new migration runinng. Here's the revisions removed: RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v deleting revision 2.88 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c,v deleting revision 1.2 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/preproc.c,v deleting revision 1.6 Hmm, it looks like you deleted the file deletion events (the versions cited above). Not sure this is the right thing. Check to see if the files are still there according to the converted git history ... Oh, drat. That's right. It shouldn't have been inclusive :S I'll abort the conversion and run it again :) Ok, I've pushed a clone of the new repository with these modifications to: http://git.postgresql.org/gitweb?p=git-migration-test.git;a=summary Haven't had the time to dig into it yet, so please go ahead anybody who wants to :-) -- 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] git: uh-oh
On Tue, Aug 31, 2010 at 5:07 PM, Magnus Hagander mag...@hagander.net wrote: On Tue, Aug 31, 2010 at 19:46, Magnus Hagander mag...@hagander.net wrote: On Tue, Aug 31, 2010 at 19:44, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@hagander.net writes: Ok. I've got a new migration runinng. Here's the revisions removed: RCS file: /usr/local/cvsroot/pgsql/src/backend/parser/Attic/gram.c,v deleting revision 2.88 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/pgc.c,v deleting revision 1.2 RCS file: /usr/local/cvsroot/pgsql/src/interfaces/ecpg/preproc/Attic/preproc.c,v deleting revision 1.6 Hmm, it looks like you deleted the file deletion events (the versions cited above). Not sure this is the right thing. Check to see if the files are still there according to the converted git history ... Oh, drat. That's right. It shouldn't have been inclusive :S I'll abort the conversion and run it again :) Ok, I've pushed a clone of the new repository with these modifications to: http://git.postgresql.org/gitweb?p=git-migration-test.git;a=summary Haven't had the time to dig into it yet, so please go ahead anybody who wants to :-) That definitely didn't fix it, although I'm not quite sure why. Can you throw the modified CVS you ran this off of up somewhere I can rsync it? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
On Wed, Aug 25, 2010 at 2:39 PM, Robert Haas robertmh...@gmail.com wrote: On Wed, Aug 25, 2010 at 1:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: The fact that the file was modified twice after being removed at rev 2.88 seems really wacko. Are you sure that's not contributing to what we're seeing here? Yeah, that was discussed in the earlier git-conversion thread that I pointed to. We never did figure out how that happened, though I speculated it might have been due to weirdness in Vadim's local checkout. Is it possible to just delete those two revisions from the CVS repository, and if so would it help? We certainly don't need 'em. cvs admin -o ? Magnus, is this something that you can try? Prune those could of wonky revisions after the delete and before the re-add prior to running the conversion, and see how that comes out? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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] git: uh-oh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Aug 25, 2010 at 12:35:53PM -0400, Robert Haas wrote: On Wed, Aug 25, 2010 at 12:02 PM, Michael Haggerty mhag...@alum.mit.edu wrote: [...] I must say, it is refreshing to have users who actually care about their conversion, as opposed to the usual rabble who think that git-cvsimport is Just Fine :-) I guess if the postgresql project didn't care about data integrity then we would all have to worry :-) I laughed when I read this - yeah, we're kind of paranoid about that. Going a bit off-topic -- although I'm extremely strapped on time I have been following this thread with attention. The above reminds me why I appreciate git; it's not just the technical parts, but the culture behind it what convince me. Thanks for a very interesting thread - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMeLSNBcgs9XrR2kYRAoTUAJ9AnpqkVID3YO1l3RhwU1rRMMtIIwCfR9yW T4NsNX5Ju5BZQhbxIEmDIpg= =+u0H -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
