Thread: missing file in git repo
I think postgres git repo is broken. The compilation of REL7_4_STABLE from git fails on my system with: make -C src all make -C port all make[2]: *** No rule to make target `sprompt.o', needed by `libpgport.a'. Stop. There is no sprompt.c in src/port in the sources obtained from git. However, there is one in CVS: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/sprompt.c?only_with_tag=REL7_4 This looks like the initial synchronization issue, since this file is there for really long time and appears not to be touchedby any commit since 2003. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc
Alexey Klyukin wrote: > I think postgres git repo is broken. > > The compilation of REL7_4_STABLE from git fails on my system with: > > make -C src all > make -C port all > make[2]: *** No rule to make target `sprompt.o', needed by `libpgport.a'. Stop. > > There is no sprompt.c in src/port in the sources obtained from git. However, there is one in CVS: > http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/sprompt.c?only_with_tag=REL7_4 > > This looks like the initial synchronization issue, since this file is there for really long time and appears not to betouched by any commit since 2003. I don't think the git repo was ever considered working for the backbranches at all... Stefan
2010/4/30 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: > Alexey Klyukin wrote: >> >> I think postgres git repo is broken. >> >> The compilation of REL7_4_STABLE from git fails on my system with: >> >> make -C src all >> make -C port all >> make[2]: *** No rule to make target `sprompt.o', needed by `libpgport.a'. >> Stop. >> >> There is no sprompt.c in src/port in the sources obtained from git. >> However, there is one in CVS: >> >> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/port/sprompt.c?only_with_tag=REL7_4 >> >> This looks like the initial synchronization issue, since this file is >> there for really long time and appears not to be touched by any commit since >> 2003. > > I don't think the git repo was ever considered working for the backbranches > at all... Really ?! Then we have to remove the backbranches from the git. http://wiki.postgresql.org/wiki/Working_with_Git#Using_Back_Branches > > > Stefan > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain
Cédric Villemain wrote: > 2010/4/30 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: >> I don't think the git repo was ever considered working for the backbranches >> at all... > > Really ?! > Then we have to remove the backbranches from the git. > http://wiki.postgresql.org/wiki/Working_with_Git#Using_Back_Branches Yeah, or fix them. FWIW, REL8_4_STABLE and REL8_3_STABLE are working, I just compared them against CVS checkouts. REL8_2_STABLE is not, it's missing a security-related patch from December. I didn't check the other branches. I have nothing against dropping the older branches, but please keep at least REL8_4_STABLE, I use it frequently. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > C�dric Villemain wrote: >> 2010/4/30 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: >>> I don't think the git repo was ever considered working for the backbranches >>> at all... >> >> Really ?! >> Then we have to remove the backbranches from the git. >> http://wiki.postgresql.org/wiki/Working_with_Git#Using_Back_Branches > Yeah, or fix them. This thread isn't exactly leaving me with a warm fuzzy feeling about moving the master repository to git. *Why* is the mirror broken, and what assurances do we have that the problem won't recur in the proposed transition? regards, tom lane
Tom Lane wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > >> Cédric Villemain wrote: >> >>> 2010/4/30 Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>: >>> >>>> I don't think the git repo was ever considered working for the backbranches >>>> at all... >>>> >>> Really ?! >>> Then we have to remove the backbranches from the git. >>> http://wiki.postgresql.org/wiki/Working_with_Git#Using_Back_Branches >>> > > >> Yeah, or fix them. >> > > This thread isn't exactly leaving me with a warm fuzzy feeling about > moving the master repository to git. *Why* is the mirror broken, and > what assurances do we have that the problem won't recur in the proposed > transition? > > > AFAICT it is broken because the particular tool that is used, which is the only one that supports an incremental mode, is a bit broken. I am told that the non-incremental tools are more robust. That said, this is more than a little annoying. It means, for example, that I can't test out a Git mode for the buildfarm client on all the back branches. If any Ruby hacker feels like fixing it please speak up. The reported source of the software seems to have gone away. I can let you have my copy, which reliably reproduces the error, so we have a good failure test case. cheers andrew
Andrew Dunstan <andrew@dunslane.net> wrote: > If any Ruby hacker feels like fixing it please speak up. I can't take it on any time soon. If nobody else picks it up, I can get to it "eventually". Anyone taking it on might want to read through the thread which starts at: http://archives.postgresql.org/pgsql-hackers/2010-01/msg01679.php I reviewed the code enough to be pretty convinced that the problem could occur if a file was committed after a scan for changes had passed the file in question, and before it hit the end of the scan. > The reported source of the software seems to have gone away. I can > let you have my copy, which reliably reproduces the error, so we > have a good failure test case. If it's not as recent as this: http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/log/132 we might want to bring in (or at least review) what's been committed since we grabbed our copy. Some of the fixes mentioned sound like they might possibly be related. -Kevin
Kevin Grittner wrote: > >> The reported source of the software seems to have gone away. I can >> let you have my copy, which reliably reproduces the error, so we >> have a good failure test case. >> > > If it's not as recent as this: > > http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/log/132 > > we might want to bring in (or at least review) what's been committed > since we grabbed our copy. Some of the fixes mentioned sound like > they might possibly be related. > > > OK, there is good news on this front. When last I looked this repo was giving errors, so I worked from the copy of the code I already had. (So thanks to Kevin for prodding me to check again.) With the latest fromcvs and rcsparse packages downloaded from this site I can now make and run the 7.4 and 8.1 branches from the imported repository (I haven't checked other branches yet.) So we need to look at how hard it would be to upgrade the scripts on git.postgresql.org, and if by doing so we can fix its versions of the back branches. It would also be a good idea to have a script that regularly checks out the important branches from git and checks that they are identical to what is in CVS. That might help to increase Tom's confidence level. cheers andrew
On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan <andrew@dunslane.net> wrote: > > > Kevin Grittner wrote: >> >>> The reported source of the software seems to have gone away. I can >>> let you have my copy, which reliably reproduces the error, so we >>> have a good failure test case. >>> >> >> If it's not as recent as this: >> http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/log/132 >> we might want to bring in (or at least review) what's been committed >> since we grabbed our copy. Some of the fixes mentioned sound like >> they might possibly be related. >> >> > > OK, there is good news on this front. When last I looked this repo was > giving errors, so I worked from the copy of the code I already had. (So > thanks to Kevin for prodding me to check again.) With the latest fromcvs and > rcsparse packages downloaded from this site I can now make and run the 7.4 > and 8.1 branches from the imported repository (I haven't checked other > branches yet.) What exactly did you test? Did you run it from scratch, or did you run it on top of the existing git repo? Because AFAIK the bug isn't consisten in that if you just do a fresh migration, it often works - even with the current version we have deployed. I haven't checked that in detail though - was this included in your tests? > So we need to look at how hard it would be to upgrade the scripts on > git.postgresql.org, and if by doing so we can fix its versions of the back Upgrading the script is trivial. It's working off a git checkout with a specific hash,iirc, because there were no actualstable releases at the time, so if you can tell me which commit to check out, that's easy. Will this automatically fix the backbranches, or do we need to do something more than just upgrading it? > branches. It would also be a good idea to have a script that regularly > checks out the important branches from git and checks that they are > identical to what is in CVS. That might help to increase Tom's confidence > level. Yes, that would be very good. ISTR there's a script somewhere, but it didn't run without showing some issues? Particularly related to the keyword expansion stuff? If someone has such a script ready today, it should be easy to deploy it on the git server for regular checks. If not, volunteers are most welcome to write one :-) -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander wrote: > On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan <andrew@dunslane.net> wrote: > >> Kevin Grittner wrote: >> >>>> The reported source of the software seems to have gone away. I can >>>> let you have my copy, which reliably reproduces the error, so we >>>> have a good failure test case. >>>> >>>> >>> If it's not as recent as this: >>> http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/log/132 >>> we might want to bring in (or at least review) what's been committed >>> since we grabbed our copy. Some of the fixes mentioned sound like >>> they might possibly be related. >>> >>> >>> >> OK, there is good news on this front. When last I looked this repo was >> giving errors, so I worked from the copy of the code I already had. (So >> thanks to Kevin for prodding me to check again.) With the latest fromcvs and >> rcsparse packages downloaded from this site I can now make and run the 7.4 >> and 8.1 branches from the imported repository (I haven't checked other >> branches yet.) >> > > What exactly did you test? Did you run it from scratch, or did you run > it on top of the existing git repo? Because AFAIK the bug isn't > consisten in that if you just do a fresh migration, it often works - > even with the current version we have deployed. I haven't checked that > in detail though - was this included in your tests? > On the version of the code I was using was fetched from the Mercurial repo. The versions I originally tested with are rcsparse-1a3116e80c2e and fromcvs-186299486bdc. The versions I have had success with are rcsparse-75d93404707d and fromcvs-c31a1dd9cbb2 On the older versions I tested, the errors appeared each time I ran the initial imports on the CVS clone I was testing with. With the latest version it has not. > > >> So we need to look at how hard it would be to upgrade the scripts on >> git.postgresql.org, and if by doing so we can fix its versions of the back >> > > Upgrading the script is trivial. It's working off a git checkout with > a specific hash,iirc, because there were no actualstable releases at > the time, so if you can tell me which commit to check out, that's > easy. > > Will this automatically fix the backbranches, or do we need to do > something more than just upgrading it? > I think what we'd need to do is remove the back branches that are failing and let it reimport them completely. AFAIK this should work without disturbing the branches we didn't remove. But it should be tested rigorously before being tried. > > >> branches. It would also be a good idea to have a script that regularly >> checks out the important branches from git and checks that they are >> identical to what is in CVS. That might help to increase Tom's confidence >> level. >> > > Yes, that would be very good. ISTR there's a script somewhere, but it > didn't run without showing some issues? Particularly related to the > keyword expansion stuff? > > If someone has such a script ready today, it should be easy to deploy > it on the git server for regular checks. If not, volunteers are most > welcome to write one :-) > > What I have done is to set up my own mirror and I will be testing it on all the live branches with a git-ized buildfarm client. I can probably pull together a script that exports from both git and cvs and compares. cheers andrew
* Andrew Dunstan <andrew@dunslane.net> [100503 09:02]: > > I can probably pull together a script that exports from both git and cvs > and compares. HINT: It's all been done and posted to -hackers before too... Along with comparisons on on whte "one-time" conversions fare (parsecvs, cvs2svn/git), etc, as well as long discussion on which keyword you want expanded, and which you don't, etc. bla bla bla... Not to rain on anyone's git-parade, I'm a huge git fan, but until the busy committers, like Tom, Bruce, Heikki, Robert, Andrew, Simon, Alvaro, (and all the rest I'm missing or don't know how to spell of the top of my head) actually *all use* git (and by use, I really mean use, not just copy-n-paste from some "howto mimic CVS with git" guide), any "planned" switch is just asking for a huge backlash of "it doesn't work like it used to", and bitter complaints... So, for those of you trying to "plan" the conversion to git, I'ld really recommend you start working with the other committers, and get them "using" git... Show them how much it makes their current CVS committing easier even... Let them see what git can do *for* them (and for everyone else too). And then I suspect you'll find that this whole "switch" will suddenly not be a big issue... The whole "find the perfect conversion" isn't even needed... In fact, they might even realize why Linus's method for the switch to git for the linux kernel is often the best (if not right) approach... If you want, I know a guy in Ottawa that does really fantastic git presentations... He's done them to many of the local *UGs, Is there interest from the core committers in getting one done at PGcon? a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
On Mon, May 3, 2010 at 16:03, Aidan Van Dyk <aidan@highrise.ca> wrote: > * Andrew Dunstan <andrew@dunslane.net> [100503 09:02]: >> > >> I can probably pull together a script that exports from both git and cvs >> and compares. > > HINT: It's all been done and posted to -hackers before too... Along > with comparisons on on whte "one-time" conversions fare (parsecvs, > cvs2svn/git), etc, as well as long discussion on which keyword you want > expanded, and which you don't, etc. bla bla bla... Yeah, that's the one I was referring to in my earlier mail. > Not to rain on anyone's git-parade, I'm a huge git fan, but until the > busy committers, like Tom, Bruce, Heikki, Robert, Andrew, Simon, Alvaro, > (and all the rest I'm missing or don't know how to spell of the top of > my head) actually *all use* git (and by use, I really mean use, not just > copy-n-paste from some "howto mimic CVS with git" guide), any "planned" > switch is just asking for a huge backlash of "it doesn't work like it > used to", and bitter complaints... A lot of the people you just listed use git already. In fact, most of them do. (Not in commit volume though, since AFAIK Tom doesn't). > So, for those of you trying to "plan" the conversion to git, I'ld really > recommend you start working with the other committers, and get them > "using" git... Show them how much it makes their current CVS committing > easier even... Let them see what git can do *for* them (and for everyone > else too). And then I suspect you'll find that this whole "switch" will Been there, done that, with at least a few ;) The thing we've always agreed upon is to at least start by migrating something that's as close to our current workflow as possible to git, and *then* consider changing anything in the workflow. We're not going to change both at once. For example, we are *definitely* going to keep with posting patches on the mailinglist during any such switch, and not go to the whole pull-from-each-others-repositories method that git likes. Nor are we going to use that insane "let's send every single git revision as one email causing a single patch to be a whole bunch of sequentially numbered emails" method ;) > If you want, I know a guy in Ottawa that does really fantastic git > presentations... He's done them to many of the local *UGs, Is there > interest from the core committers in getting one done at PGcon? While I appreciate the offer, that's not really the problem, I think. In fact, people who really know git tend to talk a lot about the advanced workflows that git will let you do - something we specifically *don't* want (at this time), and often comes across as an oversell. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Aidan Van Dyk <aidan@highrise.ca> writes:
> If you want, I know a guy in Ottawa that does really fantastic git
> presentations... He's done them to many of the local *UGs, Is there
> interest from the core committers in getting one done at PGcon?
I'd be interested.
regards, tom lane
On Mon, May 3, 2010 at 16:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Aidan Van Dyk <aidan@highrise.ca> writes: >> If you want, I know a guy in Ottawa that does really fantastic git >> presentations... He's done them to many of the local *UGs, Is there >> interest from the core committers in getting one done at PGcon? > > I'd be interested. Hey, that comment alone is enough for me to retract my previous comment :) At least if it can be made to be focused around the PostgreSQL workflow, and not the linux kernel workflow (or whatever). -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> The thing we've always agreed upon is to at least start by migrating
> something that's as close to our current workflow as possible to git,
> and *then* consider changing anything in the workflow. We're not going
> to change both at once.
Yeah. One of the main constraints in my view is retaining our current
workflow for back-patching release branches. We're not going to stop
supporting those branches, and we're not going to deal with two separate
repositories. So if we're to convert to a git master, it has to be
able to deal with back-patches. Given that the "same" patch is usually
textually a bit different from branch to branch, I'm not convinced that
git is going to make my life easier in that respect.
regards, tom lane
On Mon, May 3, 2010 at 16:25, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> The thing we've always agreed upon is to at least start by migrating >> something that's as close to our current workflow as possible to git, >> and *then* consider changing anything in the workflow. We're not going >> to change both at once. > > Yeah. One of the main constraints in my view is retaining our current > workflow for back-patching release branches. We're not going to stop > supporting those branches, and we're not going to deal with two separate > repositories. So if we're to convert to a git master, it has to be > able to deal with back-patches. Given that the "same" patch is usually > textually a bit different from branch to branch, I'm not convinced that > git is going to make my life easier in that respect. I doubt it will - not the way that we work (and I like the way that we work with that). It might help a little in preparing them if they're complex - but we seldom backpatch really complex patches. I think we're more focused on making sure it doesn't make things *worse* for that use-case. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Mon, May 3, 2010 at 10:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> The thing we've always agreed upon is to at least start by migrating >> something that's as close to our current workflow as possible to git, >> and *then* consider changing anything in the workflow. We're not going >> to change both at once. > > Yeah. One of the main constraints in my view is retaining our current > workflow for back-patching release branches. We're not going to stop > supporting those branches, and we're not going to deal with two separate > repositories. So if we're to convert to a git master, it has to be > able to deal with back-patches. Given that the "same" patch is usually > textually a bit different from branch to branch, I'm not convinced that > git is going to make my life easier in that respect. Yeah, I don't think it is. Nor do I think it will make it any harder.The main benefits I see as a committer are: - It's faster; - I can work off-line; - I can "queue up" patches in a branch and then drop them all into the master branch at once (assuming no conflicts, of course). This might be useful for security updates, among other things; and of course - I won't have to switch back and forth between two systems. ...Robert
Aidan Van Dyk wrote: > * Andrew Dunstan <andrew@dunslane.net> [100503 09:02]: > > > >> I can probably pull together a script that exports from both git and cvs >> and compares. >> > > HINT: It's all been done and posted to -hackers before too... Along > with comparisons on on whte "one-time" conversions fare (parsecvs, > cvs2svn/git), etc, as well as long discussion on which keyword you want > expanded, and which you don't, etc. bla bla bla... > > Not to rain on anyone's git-parade, I'm a huge git fan, but until the > busy committers, like Tom, Bruce, Heikki, Robert, Andrew, Simon, Alvaro, > (and all the rest I'm missing or don't know how to spell of the top of > my head) actually *all use* git (and by use, I really mean use, not just > copy-n-paste from some "howto mimic CVS with git" guide), any "planned" > switch is just asking for a huge backlash of "it doesn't work like it > used to", and bitter complaints... > > So, for those of you trying to "plan" the conversion to git, I'ld really > recommend you start working with the other committers, and get them > "using" git... Show them how much it makes their current CVS committing > easier even... Let them see what git can do *for* them (and for everyone > else too). And then I suspect you'll find that this whole "switch" will > suddenly not be a big issue... The whole "find the perfect conversion" > isn't even needed... In fact, they might even realize why Linus's > method for the switch to git for the linux kernel is often the best (if > not right) approach... > > If you want, I know a guy in Ottawa that does really fantastic git > presentations... He's done them to many of the local *UGs, Is there > interest from the core committers in getting one done at PGcon? > > > I am giving a talk in Ottawa on using git with Postgres. Feel free to come and correct all my errors if you're going to be there. That is why I have been talking about it a lot, both here and on my blog. I am currently working on some stuff that would have been significantly easier if we actually had a working git repository for all the live back branches (something I do have now, I think - fingers crossed). I have also been working on making the buildfarm client work with git, one of the hurdles we need to jump over. The fact that we are being cautious about this annoys the heck out of some people. I'm sorry, but that's just the way we tend to work. If we hadn't been so cautious a year or two back when git was much less mature, we'd probably be using Subversion now and any move to git would probably not even be on the table. Pushing us on this probably won't help the cause. More likely it will get people's backs up. And I'm not sure about the wisdom of using the Linux Kernel as an example of good software practice either. And let it also be noted that git has some warts too. I've seen plenty of complaints about its command set and I've had one or two substantial complaints myself. If we were going on pure technical merit I'm not at all sure git would win the contest for a new SCM system for Postgres. I am not trying to start a debate on the relevant merits of various SCM systems, but just trying to keep things in perspective. Moving to something like git will help us a bit. Sometimes (not that often, I suspect) it will help more than a bit. None of that is to say we shouldn't move to git. Also, if you're working on features, you can use git now, and ignore CVS completely. As far as we know the existing git mirror is quite sane and reliable, on all branches from 8.2 up. That accounts for 99% of developers - the number of people doing anything on versions 7.4 to 8.1 is minuscule. cheers andrew
Magnus Hagander wrote: > On Mon, May 3, 2010 at 16:03, Aidan Van Dyk <aidan@highrise.ca> wrote: > >> * Andrew Dunstan <andrew@dunslane.net> [100503 09:02]: >> >>> I can probably pull together a script that exports from both git and cvs >>> and compares. >>> >> HINT: It's all been done and posted to -hackers before too... Along >> with comparisons on on whte "one-time" conversions fare (parsecvs, >> cvs2svn/git), etc, as well as long discussion on which keyword you want >> expanded, and which you don't, etc. bla bla bla... >> > > Yeah, that's the one I was referring to in my earlier mail. > If it has been done why isn't it being run? I pulled together a quick hack, and here is what I get from my mirrors. I'm not sure why we get those diffs - it's a bit odd, although fairly insignificant. cheers andrew [andrew@sophia groot]$ perl check_branches *** Mon May 3 10:00:36 2010: checking REL7_4_STABLE diff -r pg-check-cvs-REL7_4_STABLE/contrib/mysql/my2pg.pl pg-check-git-REL7_4_STABLE/contrib/mysql/my2pg.pl 43,45d42 < # Revision1.10 2003/01/07 22:18:43 momjian < # Upgrade to my2pg 1.9 < # *** Mon May 3 10:01:04 2010: checking REL8_0_STABLE diff -r pg-check-cvs-REL8_0_STABLE/contrib/mysql/my2pg.diff pg-check-git-REL8_0_STABLE/contrib/mysql/my2pg.diff 17,25c17 < # $Log: my2pg.diff,v $ < # Revision 1.1 2004/04/1923:18:12 momjian < # Update to my2pg version 1.28, add docs, update URL for newest version. < # < # Create diff of custom changes Tom made to the utility for CREATE < # FUNCTION. < # < # This will make movingthis utility out of CVS easier. < # --- > # $Log: my2pg.pl,v $ diff -r pg-check-cvs-REL8_0_STABLE/contrib/mysql/my2pg.pl pg-check-git-REL8_0_STABLE/contrib/mysql/my2pg.pl 50,57d49 < # Revision1.13 2004/04/19 23:18:12 momjian < # Update to my2pg version 1.28, add docs, update URL for newest version. < # < # Create diff of custom changes Tom made to the utility for CREATE < # FUNCTION. < # < # This willmake moving this utility out of CVS easier. < # *** Mon May 3 10:02:46 2010: checking REL8_1_STABLE *** Mon May 3 10:03:54 2010: checking REL8_2_STABLE *** Mon May 3 10:04:30 2010: checking REL8_3_STABLE *** Mon May 3 10:05:012010: checking REL8_4_STABLE *** Mon May 3 10:05:32 2010: checking HEAD [andrew@sophia groot]$
* Andrew Dunstan <andrew@dunslane.net> [100503 11:05]: > If it has been done why isn't it being run? I suspect (but can only speak for myself) it's simply because to most of us using git for development, it's irrelevant... We're using it to track/build/develop, and the "history" and keywords aren't relevant to us tracking branch tips and makeing sure our changes work. Every once in a while we notice a conversion glich, we fix it... We've posted the results, had the little bike-shed on keywords, hand-"fixed" RCS files, etc, and moved on ;-) But your case of trying to "automatically" build/track the branch heads for the buildfarm w/ git has a lot more strict requirements of the *incremental* *conversion* *of* *CVS* than any of us had/have... Of course, improvements in that conversion mean you actually have *better* reliability than the current CVS, because you can avoid the problem of broken CVS checkouts... Of course, if the repository was git, the buildfarm wouldn't need to "worry" if the git repository/commit it's fetching is "a good approximation of the CVS" ;-) a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
On Mon, May 3, 2010 at 10:03 AM, Aidan Van Dyk <aidan@highrise.ca> wrote: > Not to rain on anyone's git-parade, I'm a huge git fan, but until the > busy committers, like Tom, Bruce, Heikki, Robert, Andrew, Simon, Alvaro, > (and all the rest I'm missing or don't know how to spell of the top of > my head) actually *all use* git (and by use, I really mean use, not just > copy-n-paste from some "howto mimic CVS with git" guide), any "planned" > switch is just asking for a huge backlash of "it doesn't work like it > used to", and bitter complaints... Heikki and I are both BIG git users, and I think Andrew, Simon, and Alvaro all use it too, though I'm not sure to what extent. Tom and Bruce don't, AFAIK, but I don't believe that either of them are waving their arms and shouting "no, no, no". At least, Tom isn't: and if Bruce does, well, I know where he lives. A couple of random things I'm concerned about: - the buildfarm, obviously, has got to work - we've still got to be able to send out automatic emails to committers, and they need to not suck (I'm deliberately not specifying what exactly that means because I don't know and I don't in any case want to overspecify, but certainly suckage is imaginable) - we need to make sure that all the committers understand how to keep the history the way we want it - i.e. linear, without merges, and possibly even implement programmatic safeguards against doing anything else ...Robert
Robert Haas wrote: > Heikki and I are both BIG git users, and I think Andrew, Simon, and > Alvaro all use it too, though I'm not sure to what extent. > I am using it increasingly. Of course, I need to convert some of my customers .... > A couple of random things I'm concerned about: > > - the buildfarm, obviously, has got to work > That work is almost complete. My plan is to unveil it all in my talk at pgcon. > - we need to make sure that all the committers understand how to keep > the history the way we want it - i.e. linear, without merges, and > possibly even implement programmatic safeguards against doing anything > else > > > That too will be part of my talk. I'm not sure how you would implement such programmatic safeguards, though. We don't have such a huge population of committers that we can't manage this by education, I think. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Robert Haas wrote:
>> - we need to make sure that all the committers understand how to keep
>> the history the way we want it - i.e. linear, without merges, and
>> possibly even implement programmatic safeguards against doing anything
>> else
> That too will be part of my talk. I'm not sure how you would implement
> such programmatic safeguards, though. We don't have such a huge
> population of committers that we can't manage this by education, I think.
I agree that programmatic safeguards are probably overkill, as long as
we have some agreed-on, documented commit procedures. We've survived
fine without any such backstops for CVS commits.
regards, tom lane
On Mon, May 3, 2010 at 17:55, Andrew Dunstan <andrew@dunslane.net> wrote: > > Robert Haas wrote: >> - we need to make sure that all the committers understand how to keep >> the history the way we want it - i.e. linear, without merges, and >> possibly even implement programmatic safeguards against doing anything >> else >> >> >> > > That too will be part of my talk. I'm not sure how you would implement such > programmatic safeguards, though. We don't have such a huge population of > committers that we can't manage this by education, I think. It's pretty trivial to block some of the most error-prone things. I believe it's even in there as a sample somewhere. I thought you were the one supposed to teach us this :-P Anyway, I think it's worth putting in, at least the simple ones. It's easier than cleaning up after a single mistake, most likely... -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Tom Lane escribió: > Andrew Dunstan <andrew@dunslane.net> writes: > > Robert Haas wrote: > >> - we need to make sure that all the committers understand how to keep > >> the history the way we want it - i.e. linear, without merges, and > >> possibly even implement programmatic safeguards against doing anything > >> else > > > That too will be part of my talk. I'm not sure how you would implement > > such programmatic safeguards, though. We don't have such a huge > > population of committers that we can't manage this by education, I think. > > I agree that programmatic safeguards are probably overkill, as long as > we have some agreed-on, documented commit procedures. We've survived > fine without any such backstops for CVS commits. It would be great to have documented procedures for fixing fat-fingered commit messages and similar problems, though. Right now we have to live with redundant commits or replies on the pgsql-committers list. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Mon, May 3, 2010 at 17:05, Andrew Dunstan <andrew@dunslane.net> wrote: > > > Magnus Hagander wrote: >> >> On Mon, May 3, 2010 at 16:03, Aidan Van Dyk <aidan@highrise.ca> wrote: >> >>> >>> * Andrew Dunstan <andrew@dunslane.net> [100503 09:02]: >>> >>>> >>>> I can probably pull together a script that exports from both git and cvs >>>> and compares. >>>> >>> >>> HINT: It's all been done and posted to -hackers before too... Along >>> with comparisons on on whte "one-time" conversions fare (parsecvs, >>> cvs2svn/git), etc, as well as long discussion on which keyword you want >>> expanded, and which you don't, etc. bla bla bla... >>> >> >> Yeah, that's the one I was referring to in my earlier mail. >> > > If it has been done why isn't it being run? Because it was showing differences and there appeared to be no real drive to fix them - at least not until the cvs import scripts were fixed. > I pulled together a quick hack, and here is what I get from my mirrors. I'm > not sure why we get those diffs - it's a bit odd, although fairly > insignificant. I don't think we can call anything insignificant - if we want it to be identical, it needs to be identical. So we need to figure out why they're different, and correct it. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Mon, May 3, 2010 at 17:05, Andrew Dunstan <andrew@dunslane.net> wrote:
>> I pulled together a quick hack, and here is what I get from my mirrors. I'm
>> not sure why we get those diffs - it's a bit odd, although fairly
>> insignificant.
> I don't think we can call anything insignificant - if we want it to be
> identical, it needs to be identical. So we need to figure out why
> they're different, and correct it.
At the very least we need to understand what's causing the difference;
otherwise it could be a problem that will bite us in a more serious
fashion later. I agree with Andrew that this difference is not critical
in itself, so it might be reasonable to not bother fixing it after we
understand it.
regards, tom lane
Aidan Van Dyk wrote: > But your case of trying to "automatically" build/track the branch heads > for the buildfarm w/ git has a lot more strict requirements of the > *incremental* *conversion* *of* *CVS* than any of us had/have... > Actually, the thing that has recently annoyed me most has nothing to do with the buildfarm. I wanted to use git cherry-pick to backport something and the brokenness of the back branches in the git repo made that a non-starter. Saying "oh, well, if we really moved to git this wouldn't be an issue" doesn't help me much. cheers andrew
Andrew Dunstan escribió: > I pulled together a quick hack, and here is what I get from my > mirrors. I'm not sure why we get those diffs - it's a bit odd, > although fairly insignificant. Well, it's a $Log$ CVS keyword -- it's not surprising that it's failing to provide exactly identical output, because it's a fairly strange keyword. Note that it's the only $Log$ in the whole tree, and the reason you don't see it in 8.1 and beyond is because that contrib module was removed. Moreover, note that this particular file got imported from another CVS repo that had already expanded this Log keyword. It's not really surprising that moving it to git fails to provide a verbatim copy. If I were worried about this, I'd edit the file in all back branches and remove the changelog ... or maybe de-magicalize it by removing the first line. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Andrew Dunstan escribió: > > >> I pulled together a quick hack, and here is what I get from my >> mirrors. I'm not sure why we get those diffs - it's a bit odd, >> although fairly insignificant. >> > > Well, it's a $Log$ CVS keyword -- it's not surprising that it's failing > to provide exactly identical output, because it's a fairly strange > keyword. Note that it's the only $Log$ in the whole tree, and the > reason you don't see it in 8.1 and beyond is because that contrib module > was removed. > > Moreover, note that this particular file got imported from another CVS > repo that had already expanded this Log keyword. It's not really > surprising that moving it to git fails to provide a verbatim copy. > > If I were worried about this, I'd edit the file in all back branches and > remove the changelog ... or maybe de-magicalize it by removing the first > line. > Thanks for this analysis. Based in this, I'm going to exclude these two files from the test. There are other instances I can see of $Log$, but it looks like they are not affecting us. cheers andrew
Aidan Van Dyk wrote: > HINT: It's all been done and posted to -hackers before too... Along > with comparisons on on whte "one-time" conversions fare (parsecvs, > cvs2svn/git), etc, as well as long discussion on which keyword you want > expanded, and which you don't, etc. bla bla bla... > And in some cases, even indexed to make them easier to find again due to links at http://wiki.postgresql.org/wiki/Switching_PostgreSQL_from_CVS_to_Git There's an item on there that talks about Tom's specific requests related to git backbranch workflow, from the last time this came up. Given Andrew's breakthrough with the buildfarm today, and so many developers due to be in the same place here this month, that might be something worth working through the details of live during PGCon. Most of the other steps beyond that are on Peter's plate, which isn't as concerning to me because we at least know for sure he's on-board with pushing toward the conversion. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us