Re: [HACKERS] missing file in git repo
On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan and...@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 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] missing file in git repo
Magnus Hagander wrote: On Fri, Apr 30, 2010 at 19:46, Andrew Dunstan and...@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 -- 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] missing file in git repo
* Andrew Dunstan and...@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, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] missing file in git repo
On Mon, May 3, 2010 at 16:03, Aidan Van Dyk ai...@highrise.ca wrote: * Andrew Dunstan and...@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 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] missing file in git repo
Aidan Van Dyk ai...@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 -- 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] missing file in git repo
On Mon, May 3, 2010 at 16:13, Tom Lane t...@sss.pgh.pa.us wrote: Aidan Van Dyk ai...@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 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] missing file in git repo
Magnus Hagander mag...@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 -- 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] missing file in git repo
On Mon, May 3, 2010 at 16:25, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@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 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] missing file in git repo
On Mon, May 3, 2010 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@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 -- 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] missing file in git repo
Aidan Van Dyk wrote: * Andrew Dunstan and...@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 -- 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] missing file in git repo
Magnus Hagander wrote: On Mon, May 3, 2010 at 16:03, Aidan Van Dyk ai...@highrise.ca wrote: * Andrew Dunstan and...@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 [and...@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 # Revision 1.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/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 will make moving this 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 # Revision 1.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 will make 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:01 2010: checking REL8_4_STABLE *** Mon May 3 10:05:32 2010: checking HEAD [and...@sophia groot]$ -- 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] missing file in git repo
* Andrew Dunstan and...@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, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] missing file in git repo
On Mon, May 3, 2010 at 10:03 AM, Aidan Van Dyk ai...@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 -- 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] missing file in git repo
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 -- 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] missing file in git repo
Andrew Dunstan and...@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 -- 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] missing file in git repo
On Mon, May 3, 2010 at 17:55, Andrew Dunstan and...@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 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] missing file in git repo
Tom Lane escribió: Andrew Dunstan and...@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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] missing file in git repo
On Mon, May 3, 2010 at 17:05, Andrew Dunstan and...@dunslane.net wrote: Magnus Hagander wrote: On Mon, May 3, 2010 at 16:03, Aidan Van Dyk ai...@highrise.ca wrote: * Andrew Dunstan and...@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 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] missing file in git repo
Magnus Hagander mag...@hagander.net writes: On Mon, May 3, 2010 at 17:05, Andrew Dunstan and...@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 -- 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] missing file in git repo
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 -- 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] missing file in git repo
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 Herrerahttp://www.CommandPrompt.com/ 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] missing file in git repo
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 -- 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] missing file in git repo
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 g...@2ndquadrant.com www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 touched by any commit since 2003. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc -- 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] missing file in git repo
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... Stefan -- 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] missing file in git repo
2010/4/30 Stefan Kaltenbrunner ste...@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 -- 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] missing file in git repo
Cédric Villemain wrote: 2010/4/30 Stefan Kaltenbrunner ste...@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 -- 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] missing file in git repo
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Cédric Villemain wrote: 2010/4/30 Stefan Kaltenbrunner ste...@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 -- 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] missing file in git repo
Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Cédric Villemain wrote: 2010/4/30 Stefan Kaltenbrunner ste...@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 -- 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] missing file in git repo
Andrew Dunstan and...@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 -- 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] missing file in git repo
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
