Thread: strict version of version_stamp.pl
Hello, Here is a diff of version_stamp.pl. It is not quite done as I can't actually get it to run. No matter what I do it doesn't appear to be able to open configure.in. If someone could help me figure out where I am being stupid I would appreciate it. Joshua D. Drake -- PostgreSQL - XMPP: jdrake@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
Attachment
"Joshua D. Drake" <jd@commandprompt.com> writes: > Here is a diff of version_stamp.pl. ... and nearly a megabyte of irrelevant junk. Please take a closer look at what you're sending before you send it ... regards, tom lane
On Fri, 2009-05-08 at 14:16 -0700, Joshua D. Drake wrote: > Hello, > > Here is a diff of version_stamp.pl. It is not quite done as I can't > actually get it to run. No matter what I do it doesn't appear to be able > to open configure.in. > > If someone could help me figure out where I am being stupid I would > appreciate it. Well you can all start by pointing out that I included a patch to configure (which was wholly unintended). Sorry about that. Here is the straight perl patch. Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdrake@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
Attachment
On Fri, 2009-05-08 at 17:44 -0400, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > Here is a diff of version_stamp.pl. > > ... and nearly a megabyte of irrelevant junk. Please take a closer look at > what you're sending before you send it ... Yes I apologize for that. Git reacted differently than I expected to a "git diff". I have since reposted a proper patch. /me walks away in shame Sincerely, Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdrake@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
On Fri, 2009-05-08 at 17:44 -0400, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > Here is a diff of version_stamp.pl. > > ... and nearly a megabyte of irrelevant junk. Please take a closer look at > what you're sending before you send it ... Never mind on this. I have obviously not re-honed my perl skills enough to handle this. Sorry for the noise. Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdrake@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
"Joshua D. Drake" <jd@commandprompt.com> writes: > Yes I apologize for that. Git reacted differently than I expected to a > "git diff". I have since reposted a proper patch. mmm ... I've recently been forced into using git for another project, and I find myself mystified as to why anyone would want to use it. Seems like baroqueness and unexpected behaviors are all over the thing. regards, tom lane
On Saturday 09 May 2009 00:50:28 Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > Yes I apologize for that. Git reacted differently than I expected to a > > "git diff". I have since reposted a proper patch. > > mmm ... I've recently been forced into using git for another project, > and I find myself mystified as to why anyone would want to use it. > Seems like baroqueness and unexpected behaviors are all over the thing. Obviously, an unchecked cvs diff would have produced the same garbage. Any other problems?
On Sat, 2009-05-09 at 01:18 +0300, Peter Eisentraut wrote: > On Saturday 09 May 2009 00:50:28 Tom Lane wrote: > > "Joshua D. Drake" <jd@commandprompt.com> writes: > > > Yes I apologize for that. Git reacted differently than I expected to a > > > "git diff". I have since reposted a proper patch. > > > > mmm ... I've recently been forced into using git for another project, > > and I find myself mystified as to why anyone would want to use it. > > Seems like baroqueness and unexpected behaviors are all over the thing. > > Obviously, an unchecked cvs diff would have produced the same garbage. Any > other problems? There are a number of conceptual differences. For example as a majority svn user, svn diff does not act the way git diff does. In that svn diff will only give me the difference within the current working directory. It will not go to the beginning of the tree and give me a diff. Perhaps a more difficult problem is that there is no easy way to update a single file within a git repo. In cvs or svn, if I blow something up on a particular file and I just want to take a fresh look, I just rm;svn update. Those are two things I can think of from my own working perspective that have been an adjustment. I would be curious to Tom's differences as well. Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdrake@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
Joshua D. Drake wrote: > Perhaps a more difficult problem is that there is no easy way to update > a single file within a git repo. In cvs or svn, if I blow something up > on a particular file and I just want to take a fresh look, I just rm;svn > update. Hmm, you should use "git revert" for that (same with SVN actually). -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hi Joshua, On 05/09/2009 12:22 AM, Joshua D. Drake wrote: >> Obviously, an unchecked cvs diff would have produced the same garbage. Any >> other problems? > There are a number of conceptual differences. For example as a majority > svn user, svn diff does not act the way git diff does. In that svn diff > will only give me the difference within the current working directory. > It will not go to the beginning of the tree and give me a diff. git diff . Although admittedly that takes some time getting used to. > Perhaps a more difficult problem is that there is no easy way to update > a single file within a git repo. In cvs or svn, if I blow something up > on a particular file and I just want to take a fresh look, I just rm;svn > update. git checkout HEAD [--] your_file Andres
Hi Alvaro, On 05/09/2009 12:26 AM, Alvaro Herrera wrote: >> Perhaps a more difficult problem is that there is no easy way to update >> a single file within a git repo. In cvs or svn, if I blow something up >> on a particular file and I just want to take a fresh look, I just rm;svn >> update. > Hmm, you should use "git revert" for that (same with SVN actually). Uh. Unfortunately not. git revert is for reverting the effects of an earlier commit, not a working copy difference. Andres
Andres Freund wrote: > Hi Alvaro, > > On 05/09/2009 12:26 AM, Alvaro Herrera wrote: >>> Perhaps a more difficult problem is that there is no easy way to update >>> a single file within a git repo. In cvs or svn, if I blow something up >>> on a particular file and I just want to take a fresh look, I just rm;svn >>> update. >> Hmm, you should use "git revert" for that (same with SVN actually). > Uh. Unfortunately not. git revert is for reverting the effects of an > earlier commit, not a working copy difference. Thanks for the clarification :-) So how do you revert WC changes? At least I got the SVN part right -- which is not surprising because that's the one I actually use. Oh, and monotone uses 'revert' for the WC meaning too (the other one does not really make much sense to me, but so does git as a whole) (You can't be serious that for reverting a WC file to the repository state you use "git checkout"?) -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Saturday 09 May 2009 01:41:20 Alvaro Herrera wrote: > (You can't be serious that for reverting a WC file to the repository > state you use "git checkout"?) Why not? The purpose of the operation is to get a file from the repository. It's not much different whether you do it the first or the second time.
On Fri, May 8, 2009 at 6:41 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Andres Freund wrote: >> Hi Alvaro, >> >> On 05/09/2009 12:26 AM, Alvaro Herrera wrote: >>>> Perhaps a more difficult problem is that there is no easy way to update >>>> a single file within a git repo. In cvs or svn, if I blow something up >>>> on a particular file and I just want to take a fresh look, I just rm;svn >>>> update. >>> Hmm, you should use "git revert" for that (same with SVN actually). >> Uh. Unfortunately not. git revert is for reverting the effects of an >> earlier commit, not a working copy difference. > > Thanks for the clarification :-) > > So how do you revert WC changes? At least I got the SVN part right -- > which is not surprising because that's the one I actually use. Oh, and > monotone uses 'revert' for the WC meaning too (the other one does not > really make much sense to me, but so does git as a whole) > > (You can't be serious that for reverting a WC file to the repository > state you use "git checkout"?) Yes, that's right. I found that a bit odd too, but it's really not bad once you get used to it. If you want to blow away ALL your changes, you can use "git reset --hard". If you want to remove all the untracked files from your working tree, you can use "git clean". ...Robert
On Fri, May 8, 2009 at 5:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> Yes I apologize for that. Git reacted differently than I expected to a >> "git diff". I have since reposted a proper patch. > > mmm ... I've recently been forced into using git for another project, > and I find myself mystified as to why anyone would want to use it. > Seems like baroqueness and unexpected behaviors are all over the thing. I had that same reaction at first. It is definitely different than cvs or svn. The first time I tried to use it, I gave up. The second time I tried to use it, I gave up. The third time I tried to use it, I almost gave up. But now I love it. A couple of really nice things: In CVS or SVN, there is no easy way (AFAIK) to get the entire history of all changes to the repository. You can get the history of changes to a FILE, but not the history of changes, period. In git, you just run "git log". (Of course if you want to restrict the output to changes that modified a certain file, you just do "git log filename".) If you are trying to find the last time something related to mumble was changed, you can run "git log -Smumble", and it shows you every commit that adds or removes a line containing the string "mumble". This is pretty useful when trying to familiarize yourself with the history of a certain bit of code. There are also options to search by regex, etc. The branching and merging stuff is incredibly good and useful. It takes a bit of getting used to the commands, but it is so much easier than cvs or svn. Actually, svn isn't bad for MAKING branches (which was what initially persuaded me to use it), but it @$# sucks for merging them. It is just terrible. It may even be worse than CVS. Don't get me wrong: I used CVS very happily for more than 10 years, and it does what it does just fine, but git is so much more powerful that it's not even funny. I can't get over how much faster I can do things now that used to be a major headache. ...Robert
On May 8, 2009, at 4:00 PM, Peter Eisentraut wrote: >> (You can't be serious that for reverting a WC file to the repository >> state you use "git checkout"?) > > Why not? The purpose of the operation is to get a file from the > repository. > It's not much different whether you do it the first or the second > time. Yeah, this makes it difficult for me to remember, too. I'm constantly asking how to do this on #git. Best, David
Joshua D. Drake wrote: > Hello, > > Here is a diff of version_stamp.pl. It is not quite done as I can't > actually get it to run. No matter what I do it doesn't appear to be able > to open configure.in. > > If someone could help me figure out where I am being stupid I would > appreciate it. > > Maybe you aren't running it in the right directory (i.e. the directory where configure.in exists)? Anyway, I think what you want to achieve (without all the git crap) is the attached. cheers andrew Index: version_stamp.pl =================================================================== RCS file: /cvsroot/pgsql/src/tools/version_stamp.pl,v retrieving revision 1.2 diff -c -u -r1.2 version_stamp.pl --- version_stamp.pl 1 Jan 2009 17:24:04 -0000 1.2 +++ version_stamp.pl 9 May 2009 01:02:48 -0000 @@ -20,15 +20,18 @@ # "devel", "betaN", "rcN". # +use strict; + # Major version is hard-wired into the script. We update it when we branch # a new development version. -$major1 = 8; -$major2 = 4; +my $major1 = 8; +my $major2 = 4; # Validate argument and compute derived variables -$minor = shift; +my $minor = shift; defined($minor) || die "$0: missing required argument: minor-version\n"; +my ($dotneeded,$numericminor); if ($minor =~ m/^\d+$/) { $dotneeded = 1; $numericminor = $minor; @@ -46,19 +49,20 @@ } # Create various required forms of the version number -$majorversion = $major1 . "." . $major2; +my $majorversion = $major1 . "." . $major2; +my $fullversion; if ($dotneeded) { $fullversion = $majorversion . "." . $minor; } else { $fullversion = $majorversion . $minor; } -$numericversion = $majorversion . "." . $numericminor; -$padnumericversion = sprintf("%d%02d%02d", $major1, $major2, $numericminor); +my $numericversion = $majorversion . "." . $numericminor; +my $padnumericversion = sprintf("%d%02d%02d", $major1, $major2, $numericminor); # Get the autoconf version number for eventual nag message # (this also ensures we're in the right directory) -$aconfver = ""; +my $aconfver = ""; open(FILE, "configure.in") || die "could not read configure.in: $!\n"; while (<FILE>) { if (m/^m4_if\(m4_defn\(\[m4_PACKAGE_VERSION\]\), \[(.*)\], \[\], \[m4_fatal/) { @@ -71,7 +75,7 @@ # Update configure.in and other files that contain version numbers -$fixedfiles = ""; +my $fixedfiles = ""; sed_file("configure.in", "-e 's/AC_INIT(\\[PostgreSQL\\], \\[[0-9a-z.]*\\]/AC_INIT([PostgreSQL], [$fullversion]/'");
Hi, Le 8 mai 09 à 23:50, Tom Lane a écrit : > mmm ... I've recently been forced into using git for another project, > and I find myself mystified as to why anyone would want to use it. > Seems like baroqueness and unexpected behaviors are all over the > thing. As a user of darcs I've been reacting in the same way for a long time, and trying to avoid to have to try out git. It turns out that a tutorial style video for an emacs mode for git made me change my mind (what I dislike about git is its user interface): http://vimeo.com/2871241 Maybe this would have some positive effect on your way to appreciate git too? :) Regards, -- dim
On Fri, May 08, 2009 at 09:04:18PM -0400, Andrew Dunstan wrote: > > > Joshua D. Drake wrote: >> Hello, >> >> Here is a diff of version_stamp.pl. It is not quite done as I can't >> actually get it to run. No matter what I do it doesn't appear to be able >> to open configure.in. >> >> If someone could help me figure out where I am being stupid I would >> appreciate it. > > > Maybe you aren't running it in the right directory (i.e. the directory > where configure.in exists)? > > Anyway, I think what you want to achieve (without all the git crap) is > the attached. Here's some git crap, but it makes all the .pl programs strict-clean. Many are still horrendous, though. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
David, I am sorry this didn't get applied, and the code has drifted too much to apply it now. Would you be able to make a new patch to make our Perl files strict? --------------------------------------------------------------------------- David Fetter wrote: > On Fri, May 08, 2009 at 09:04:18PM -0400, Andrew Dunstan wrote: > > > > > > Joshua D. Drake wrote: > >> Hello, > >> > >> Here is a diff of version_stamp.pl. It is not quite done as I can't > >> actually get it to run. No matter what I do it doesn't appear to be able > >> to open configure.in. > >> > >> If someone could help me figure out where I am being stupid I would > >> appreciate it. > > > > > > Maybe you aren't running it in the right directory (i.e. the directory > > where configure.in exists)? > > > > Anyway, I think what you want to achieve (without all the git crap) is > > the attached. > > Here's some git crap, but it makes all the .pl programs strict-clean. > Many are still horrendous, though. > > Cheers, > David. > -- > David Fetter <david@fetter.org> http://fetter.org/ > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter > Skype: davidfetter XMPP: david.fetter@gmail.com > > Remember to vote! > Consider donating to Postgres: http://www.postgresql.org/about/donate [ Attachment, skipping... ] > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard drive,Christ can be your backup. +
On Thu, Feb 25, 2010 at 05:39:10PM -0500, Bruce Momjian wrote: > > David, I am sorry this didn't get applied, and the code has drifted too > much to apply it now. Would you be able to make a new patch to make our > Perl files strict? Please find updated patch attached. It passes strict, warnings, and perlcritic -4 Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Attachment
David Fetter <david@fetter.org> writes: > -} elsif ($minor eq "devel") { > - $dotneeded = 0; > - $numericminor = 0; > -} elsif ($minor =~ m/^alpha\d+$/) { > - $dotneeded = 0; > - $numericminor = 0; > -} elsif ($minor =~ m/^beta\d+$/) { > - $dotneeded = 0; > - $numericminor = 0; > -} elsif ($minor =~ m/^rc\d+$/) { > +} elsif ($minor =~ m/ > + ^ > + ( > + devel | > + alpha\d+ | > + beta\d+ | > + rc\d+ > + ) > + $/x) { FWIW, I don't care for the above part of the patch. It doesn't seem to me to improve readability one iota, if anything the reverse; and it makes the logic less amenable to modification. If we wanted to make the behavior at all different for alpha/beta/rc cases, we'd have to undo it anyway. regards, tom lane