Re: [HACKERS] Policy decisions and cosmetic issues remaining for the git conversion
Magnus Hagander writes: > Yeah, let's not touch the CVS side, but definitely +1 for dropping > them from git (in fact, my script does this automatically if I just > let it run through all the steps, which I've repeatedly not done which > is why they've sometimes shown up and sometimes not in the ones I've > pushed) Could we see your full script and options file? I'm busy running test conversions myself, and would like to be sure that I'm on the same page as you are. BTW, the conversion I'm getting at the moment (using the fixup script I posted last night) does not have the weird "unlabeled" branches that were complained of earlier. I think that nuking the WIN32_DEV derived files probably was what stopped 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] Policy decisions and cosmetic issues remaining for the git conversion
On Mon, Sep 13, 2010 at 18:31, Tom Lane wrote: > This is an attempt to sum up the open issues remaining before we can > make another try at converting our source code to git. > * The REL8_0_0 branch needs to be downgraded to a tag, as previously > discussed. Yeah, and that's easily done. > * There are several things we should do to make the manufactured commits > less ugly, assuming we can't get rid of them entirely: > ** Blame them on a nonexistent committer, probably "cvs2git" itself. I've set the script onthe prod box up to blame it on cvs2git (same email address as the pgsql user, but different name) > ** If we do that, I'm inclined to also blame the inserted dead .0 > revisions on cvs2git. Right now I copied-and-pasted the committer info > from the mainline commit they inherit from, which is not very relevant. +1 > ** Make the manufactured-commit log messages say cvs2git not cvs2svn. Done in my options file - it's just a couple of settings. -- 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] Policy decisions and cosmetic issues remaining for the git conversion
On Mon, Sep 13, 2010 at 19:14, Robert Haas wrote: > On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera > wrote: >> Excerpts from Tom Lane's message of lun sep 13 12:31:53 -0400 2010: >> >>> * As I noted previously, up till about 2003 we were quite haphazard about >>> applying CVS tags to identify the points where releases were made. Should >>> we try to clean that up? I think there is a stronger case for moving the >>> three existing misleading tags than for creating new tags matching the >>> releases that have none. Maybe nobody will ever care about any of them, >>> but if we are trying to create a good historical record it might be >>> appropriate to do it now while we have the information in mind. >> >> +1 on both -- fixing the broken tags, and creating the missing tags, >> particularly since you already seem to have found out the necessary >> dates for the missing tags. > > +1 from me, too. I don't agree with statements upthread that this > will be "easier" to do in git. I think we should fix the CVS history. > The git conversion is a one-time event. Once it's done, history is > set in stone. We don't want to set the wrong thing in stone. Yeah, +1 on fixing it there if it needs fixing. As noted downstream, we need to make sure it's *fixable* anyway, and that's the larger part of the work I imagine. >>> * There are a number of partial tags (tags applied to just a subset of >>> files) in the CVS repository: "MANUAL_1_0" and "SUPPORT" seem to have been >>> applied to only documentation-related files, and "creation" and >>> "Release-1-6-0" were applied only to src/interfaces/perl5/. I find the >>> latter two particularly misleading since they have nothing to do with >>> either creation of the whole project or a "release 1.6" of the whole >>> project. These partial tags don't translate very well to git, either. >>> I'm inclined to propose dropping all four. >> >> +1 on dropping these. > > Yeah. I would leave these in CVS (why not?) but drop them from the > git conversion, which is easily done. Yeah, let's not touch the CVS side, but definitely +1 for dropping them from git (in fact, my script does this automatically if I just let it run through all the steps, which I've repeatedly not done which is why they've sometimes shown up and sometimes not in the ones I've pushed) >>> * There are a couple of manufactured commits that we could just delete, >>> I think: the ones to create the Release_2_0 and Release_2_0_0 tags. The >>> tags should be reapplied to the chronologically preceding mainline commits >>> instead. This is just cosmetic but we may as well do it. I still think >>> there's a cvs2git bug underlying those. >> >> +1 > > +1. +1. -- 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] Policy decisions and cosmetic issues remaining for the git conversion
Robert Haas writes: > On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane wrote: >> Well, the other side of that argument is that changing these things in >> the CVS repository will be overwriting the available evidence, in case >> any questions come up later. On the git side, applying the tag to the >> appropriate commit is an easy --- and easily changeable --- thing, isn't >> it? > You can apply the tag to any commit that you want easily enough, but > you can't change even the least detail of the commit contents. So if > it turns out that there's no commit that exactly matches the desired > tag contents, then things get sticky. That's why we need to make sure > that the reconstructed series of commits exactly matches what really > happened as closely as possible the first time through. If it > doesn't, we're pretty hosed. I've already found the commits on the CVS side that I think ought to get the tags --- that's what that "matches" file is about. If cvs2git can't be trusted to duplicate those tree states then we have bigger problems. Of course, now that I've got the tarballs I will be rechecking them against git checkouts as part of the acceptance tests for the final conversion, but right now I don't foresee a problem 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] Policy decisions and cosmetic issues remaining for the git conversion
On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera >> wrote: >>> +1 on both -- fixing the broken tags, and creating the missing tags, >>> particularly since you already seem to have found out the necessary >>> dates for the missing tags. > >> +1 from me, too. I don't agree with statements upthread that this >> will be "easier" to do in git. I think we should fix the CVS history. >> The git conversion is a one-time event. Once it's done, history is >> set in stone. We don't want to set the wrong thing in stone. > > Well, the other side of that argument is that changing these things in > the CVS repository will be overwriting the available evidence, in case > any questions come up later. On the git side, applying the tag to the > appropriate commit is an easy --- and easily changeable --- thing, isn't > it? You can apply the tag to any commit that you want easily enough, but you can't change even the least detail of the commit contents. So if it turns out that there's no commit that exactly matches the desired tag contents, then things get sticky. That's why we need to make sure that the reconstructed series of commits exactly matches what really happened as closely as possible the first time through. If it doesn't, we're pretty hosed. -- 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] Policy decisions and cosmetic issues remaining for the git conversion
Robert Haas writes: > On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera > wrote: >> +1 on both -- fixing the broken tags, and creating the missing tags, >> particularly since you already seem to have found out the necessary >> dates for the missing tags. > +1 from me, too. I don't agree with statements upthread that this > will be "easier" to do in git. I think we should fix the CVS history. > The git conversion is a one-time event. Once it's done, history is > set in stone. We don't want to set the wrong thing in stone. Well, the other side of that argument is that changing these things in the CVS repository will be overwriting the available evidence, in case any questions come up later. On the git side, applying the tag to the appropriate commit is an easy --- and easily changeable --- thing, isn't it? 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] Policy decisions and cosmetic issues remaining for the git conversion
On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera wrote: > Excerpts from Tom Lane's message of lun sep 13 12:31:53 -0400 2010: > >> * As I noted previously, up till about 2003 we were quite haphazard about >> applying CVS tags to identify the points where releases were made. Should >> we try to clean that up? I think there is a stronger case for moving the >> three existing misleading tags than for creating new tags matching the >> releases that have none. Maybe nobody will ever care about any of them, >> but if we are trying to create a good historical record it might be >> appropriate to do it now while we have the information in mind. > > +1 on both -- fixing the broken tags, and creating the missing tags, > particularly since you already seem to have found out the necessary > dates for the missing tags. +1 from me, too. I don't agree with statements upthread that this will be "easier" to do in git. I think we should fix the CVS history. The git conversion is a one-time event. Once it's done, history is set in stone. We don't want to set the wrong thing in stone. >> * There are a number of partial tags (tags applied to just a subset of >> files) in the CVS repository: "MANUAL_1_0" and "SUPPORT" seem to have been >> applied to only documentation-related files, and "creation" and >> "Release-1-6-0" were applied only to src/interfaces/perl5/. I find the >> latter two particularly misleading since they have nothing to do with >> either creation of the whole project or a "release 1.6" of the whole >> project. These partial tags don't translate very well to git, either. >> I'm inclined to propose dropping all four. > > +1 on dropping these. Yeah. I would leave these in CVS (why not?) but drop them from the git conversion, which is easily done. >> * There are a couple of manufactured commits that we could just delete, >> I think: the ones to create the Release_2_0 and Release_2_0_0 tags. The >> tags should be reapplied to the chronologically preceding mainline commits >> instead. This is just cosmetic but we may as well do it. I still think >> there's a cvs2git bug underlying those. > > +1 +1. -- 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] Policy decisions and cosmetic issues remaining for the git conversion
Excerpts from Tom Lane's message of lun sep 13 12:31:53 -0400 2010: > * As I noted previously, up till about 2003 we were quite haphazard about > applying CVS tags to identify the points where releases were made. Should > we try to clean that up? I think there is a stronger case for moving the > three existing misleading tags than for creating new tags matching the > releases that have none. Maybe nobody will ever care about any of them, > but if we are trying to create a good historical record it might be > appropriate to do it now while we have the information in mind. +1 on both -- fixing the broken tags, and creating the missing tags, particularly since you already seem to have found out the necessary dates for the missing tags. > * There are a number of partial tags (tags applied to just a subset of > files) in the CVS repository: "MANUAL_1_0" and "SUPPORT" seem to have been > applied to only documentation-related files, and "creation" and > "Release-1-6-0" were applied only to src/interfaces/perl5/. I find the > latter two particularly misleading since they have nothing to do with > either creation of the whole project or a "release 1.6" of the whole > project. These partial tags don't translate very well to git, either. > I'm inclined to propose dropping all four. +1 on dropping these. > * There are a couple of manufactured commits that we could just delete, > I think: the ones to create the Release_2_0 and Release_2_0_0 tags. The > tags should be reapplied to the chronologically preceding mainline commits > instead. This is just cosmetic but we may as well do it. I still think > there's a cvs2git bug underlying those. +1 -- Álvaro Herrera 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] Policy decisions and cosmetic issues remaining for the git conversion
On 13/09/10 19:31, Tom Lane wrote: * If we do the above, should it be done in the existing CVS repository or just as part of the conversion to git? (I suspect it'd be a lot easier in git.) Similarly, ought we to fix the now-known tagging inconsistencies in the CVS repository, or just leave it for the conversion to deal with? Let's leave the CVS repository as it is. I don't want to destroy the evidence. * There are a number of partial tags (tags applied to just a subset of files) in the CVS repository: "MANUAL_1_0" and "SUPPORT" seem to have been applied to only documentation-related files, and "creation" and "Release-1-6-0" were applied only to src/interfaces/perl5/. I find the latter two particularly misleading since they have nothing to do with either creation of the whole project or a "release 1.6" of the whole project. These partial tags don't translate very well to git, either. I'm inclined to propose dropping all four. What was the purpose of these tags anyway? They don't seem useful, +1 for dropping all four. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] Policy decisions and cosmetic issues remaining for the git conversion
On Mon, 2010-09-13 at 12:31 -0400, Tom Lane wrote: > This is an attempt to sum up the open issues remaining before we can > make another try at converting our source code to git. > > * As I noted previously, up till about 2003 we were quite haphazard about > applying CVS tags to identify the points where releases were made. Should > we try to clean that up? I think there is a stronger case for moving the > three existing misleading tags than for creating new tags matching the > releases that have none. Maybe nobody will ever care about any of them, > but if we are trying to create a good historical record it might be > appropriate to do it now while we have the information in mind. It is obnoxious but I think it is a good idea. > > * If we do the above, should it be done in the existing CVS repository > or just as part of the conversion to git? (I suspect it'd be a lot easier > in git.) Similarly, ought we to fix the now-known tagging inconsistencies > in the CVS repository, or just leave it for the conversion to deal with? IMO eventually the CVS repo will get deleted. We should do it where it is going to have he longest life, which would be git (or the conversion as it was) at this point (for at least another 15 years). Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
