You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Shane Turner <sh...@newpace.ca> on 2011/12/06 14:47:20 UTC
Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
I was just taking a look at the differences between Subversion 1.7.1 and
1.7.2 and noticed a couple of diffs that look odd.
In subversion/bindings/swig/python/core.c and
subversion/bindings/swig/ruby/core.c, the value of SVN_VER_REVISION
changed from the numeric revision number (previously 1186859) to 0. I
think it's supposed to be 1207936.
Is this a bug, or intended? Be forewarned that I don't use this aspect
of Subversion. I just happened to notice.
The code I was examining was from
http://apache.sunsite.ualberta.ca/subversion/subversion-1.7.2.tar.bz2
I've included the diff below. I've filtered out all of the path
differences in the comments ("/*@SWIG:...").
Shane Turner
diff -rwB -I '.*@SWIG:.*'
subversion-1.7.4bed3649c532/subversion/bindings/swig/python/core.c
subversion-1.7/subversion/bindings/swig/python/core.c
30985,30986c30985,30986
< SWIG_Python_SetConstant(d, "SVN_VER_PATCH",SWIG_From_long((long)(1)));
< SWIG_Python_SetConstant(d, "SVN_VER_MICRO",SWIG_From_long((long)(1)));
---
> SWIG_Python_SetConstant(d, "SVN_VER_PATCH",SWIG_From_long((long)(2)));
> SWIG_Python_SetConstant(d, "SVN_VER_MICRO",SWIG_From_long((long)(2)));
30988c30988
< SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
(r1186859)"));
---
> SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
(r1207936)"));
30990,30993c30990,30993
*< SWIG_Python_SetConstant(d,
"SVN_VER_REVISION",SWIG_From_long((long)(1186859)));*
< SWIG_Python_SetConstant(d, "SVN_VER_NUM",SWIG_FromCharPtr("1.7.1"));
< SWIG_Python_SetConstant(d, "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.1"));
< SWIG_Python_SetConstant(d, "SVN_VERSION",SWIG_FromCharPtr("1.7.1
(r1186859)"));
---
*> SWIG_Python_SetConstant(d,
"SVN_VER_REVISION",SWIG_From_long((long)(0)));*
> SWIG_Python_SetConstant(d, "SVN_VER_NUM",SWIG_FromCharPtr("1.7.2"));
> SWIG_Python_SetConstant(d, "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.2"));
> SWIG_Python_SetConstant(d, "SVN_VERSION",SWIG_FromCharPtr("1.7.2
(r1207936)"));
diff -rwB -I '.*@SWIG:.*'
subversion-1.7.4bed3649c532/subversion/bindings/swig/ruby/core.c
subversion-1.7/subversion/bindings/swig/ruby/core.c
37529,37530c37529,37530
< rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(1)));
< rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(1)));
---
> rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(2)));
> rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(2)));
37532c37532
< rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr(" (r1186859)"));
---
> rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr(" (r1207936)"));
37534,37537c37534,37537
*< rb_define_const(mCore, "SVN_VER_REVISION",
SWIG_From_int((int)(1186859)));*
< rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.1"));
< rb_define_const(mCore, "SVN_VER_NUMBER", SWIG_FromCharPtr("1.7.1"));
< rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.1
(r1186859)"));
---
*> rb_define_const(mCore, "SVN_VER_REVISION", SWIG_From_int((int)(0)));*
> rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.2"));
> rb_define_const(mCore, "SVN_VER_NUMBER", SWIG_FromCharPtr("1.7.2"));
> rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.2
(r1207936)"));
--
Shane Turner
Senior Software Developer
phone +1 (902) 406--8375 x1008
email Shane.Turner@NewPace.ca <ma...@newpace.ca>
aim <ai...@newpace.ca>/msn
<ms...@newpace.ca> Shane.Turner@NewPace.ca
<ai...@newpace.ca>
skype saturnjct <skype:saturnjct>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings
for Python and Ruby?
Posted by Daniel Shahaf <da...@elego.de>.
Shane Turner wrote on Tue, Dec 06, 2011 at 12:28:51 -0400:
> subversion/include/svn_version.h is incorrect as well.
>
> I'm not sure that the associated comment is correct given it appears
> to be used for more than the Windows build?
>
The comment is fine, because it doesn't say "only". (The macro value is
exposed via 'svn --version | head -n2' on all platforms.)
> /** Revision number: The repository revision number of this release.
> *
> * This constant is used to generate the build number part of the
> Windows
> * file version. Its value remains 0 in the repository.
> *
> * When rolling a tarball, we automatically replace it with what we
> * guess to be the correct revision number.
> */
> #define SVN_VER_REVISION 0
>
>
> On December-06-11 12:19:42 PM, Hyrum K Wright wrote:
> >
> >On Tue, Dec 6, 2011 at 7:47 AM, Shane Turner
> ><shane.turner@newpace.ca <ma...@newpace.ca>> wrote:
> >
> > I was just taking a look at the differences between Subversion
> > 1.7.1 and 1.7.2 and noticed a couple of diffs that look odd.
> >
> > In subversion/bindings/swig/python/core.c and
> > subversion/bindings/swig/ruby/core.c, the value of
> > SVN_VER_REVISION changed from the numeric revision number
> > (previously 1186859) to 0. I think it's supposed to be 1207936.
> >
> > Is this a bug, or intended? Be forewarned that I don't use this
> > aspect of Subversion. I just happened to notice.
> >
> > The code I was examining was from
> > http://apache.sunsite.ualberta.ca/subversion/subversion-1.7.2.tar.bz2
> >
> > I've included the diff below. I've filtered out all of the path
> > differences in the comments ("/*@SWIG:..." <mailto:/*@SWIG:...>).
> >
> > Shane Turner
> >
> > diff -rwB -I '.*@SWIG:.*'
> > subversion-1.7.4bed3649c532/subversion/bindings/swig/python/core.c
> > subversion-1.7/subversion/bindings/swig/python/core.c
> > 30985,30986c30985,30986
> > < SWIG_Python_SetConstant(d,
> > "SVN_VER_PATCH",SWIG_From_long((long)(1)));
> > < SWIG_Python_SetConstant(d,
> > "SVN_VER_MICRO",SWIG_From_long((long)(1)));
> > ---
> > > SWIG_Python_SetConstant(d,
> > "SVN_VER_PATCH",SWIG_From_long((long)(2)));
> > > SWIG_Python_SetConstant(d,
> > "SVN_VER_MICRO",SWIG_From_long((long)(2)));
> > 30988c30988
> > < SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> > (r1186859)"));
> > ---
> > > SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> > (r1207936)"));
> > 30990,30993c30990,30993
> > *< SWIG_Python_SetConstant(d,
> > "SVN_VER_REVISION",SWIG_From_long((long)(1186859)));*
> > < SWIG_Python_SetConstant(d,
> > "SVN_VER_NUM",SWIG_FromCharPtr("1.7.1"));
> > < SWIG_Python_SetConstant(d,
> > "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.1"));
> > < SWIG_Python_SetConstant(d,
> > "SVN_VERSION",SWIG_FromCharPtr("1.7.1 (r1186859)"));
> > ---
> > *> SWIG_Python_SetConstant(d,
> > "SVN_VER_REVISION",SWIG_From_long((long)(0)));*
> > > SWIG_Python_SetConstant(d,
> > "SVN_VER_NUM",SWIG_FromCharPtr("1.7.2"));
> > > SWIG_Python_SetConstant(d,
> > "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.2"));
> > > SWIG_Python_SetConstant(d,
> > "SVN_VERSION",SWIG_FromCharPtr("1.7.2 (r1207936)"));
> > diff -rwB -I '.*@SWIG:.*'
> > subversion-1.7.4bed3649c532/subversion/bindings/swig/ruby/core.c
> > subversion-1.7/subversion/bindings/swig/ruby/core.c
> > 37529,37530c37529,37530
> > < rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(1)));
> > < rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(1)));
> > ---
> > > rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(2)));
> > > rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(2)));
> > 37532c37532
> > < rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
> > (r1186859)"));
> > ---
> > > rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
> > (r1207936)"));
> > 37534,37537c37534,37537
> > *< rb_define_const(mCore, "SVN_VER_REVISION",
> > SWIG_From_int((int)(1186859)));*
> > < rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.1"));
> > < rb_define_const(mCore, "SVN_VER_NUMBER",
> > SWIG_FromCharPtr("1.7.1"));
> > < rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.1
> > (r1186859)"));
> > ---
> > *> rb_define_const(mCore, "SVN_VER_REVISION",
> > SWIG_From_int((int)(0)));*
> > > rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.2"));
> > > rb_define_const(mCore, "SVN_VER_NUMBER",
> > SWIG_FromCharPtr("1.7.2"));
> > > rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.2
> > (r1207936)"));
> >
> >
> >Shane,
> >Thanks for letting us know about this. I'm guessing that these
> >values come from the standard Subversion header file
> >svn_version.h. When rolling the tarballs, I checked that the
> >revision number was in there properly in the separately-generated
> >file, but must confess that I'm not sure what the actual tarballs
> >contain. Could you check and see if SVN_VER_REVISION is set
> >appropriately in svn_version.h?
> >
> >Thanks,
> >-Hyrum
> >
> >
> >
> >--
> >
> >uberSVN: Apache Subversion Made Easy
> >http://www.uberSVN.com/
>
> --
> --
> Shane Turner
> Senior Software Developer
> phone +1 (902) 406–8375 x1008
> email Shane.Turner@NewPace.ca <ma...@newpace.ca>
> aim <ai...@newpace.ca>/msn
> <ms...@newpace.ca>
> Shane.Turner@NewPace.ca
> <ai...@newpace.ca>
> skype saturnjct <skype:saturnjct>
>
>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Wed, Dec 7, 2011, at 11:23, Shane Turner wrote:
> Should I open a bug report to have the packages regenerated, assuming
> that will fix the problem? I would take a look at the scripts to build
> the source archives if I knew where they were.
>
Short answer: tools/dist/release.py in trunk. See nightly.sh in the
same directory for its use.
I haven't used them myself in months so I don't recall the exact details, sorry.
> Shane
>
> On 06/12/2011 12:28 PM, Shane Turner wrote:
> > subversion/include/svn_version.h is incorrect as well.
> >
> > I'm not sure that the associated comment is correct given it appears
> > to be used for more than the Windows build?
> >
> > /** Revision number: The repository revision number of this release.
> > *
> > * This constant is used to generate the build number part of the Windows
> > * file version. Its value remains 0 in the repository.
> > *
> > * When rolling a tarball, we automatically replace it with what we
> > * guess to be the correct revision number.
> > */
> > #define SVN_VER_REVISION 0
> >
> >
> > On December-06-11 12:19:42 PM, Hyrum K Wright wrote:
> >>
> >> On Tue, Dec 6, 2011 at 7:47 AM, Shane Turner <shane.turner@newpace.ca
> >> <ma...@newpace.ca>> wrote:
> >>
> >> I was just taking a look at the differences between Subversion
> >> 1.7.1 and 1.7.2 and noticed a couple of diffs that look odd.
> >>
> >> In subversion/bindings/swig/python/core.c and
> >> subversion/bindings/swig/ruby/core.c, the value of
> >> SVN_VER_REVISION changed from the numeric revision number
> >> (previously 1186859) to 0. I think it's supposed to be 1207936.
> >>
> >> Is this a bug, or intended? Be forewarned that I don't use this
> >> aspect of Subversion. I just happened to notice.
> >>
> >> The code I was examining was from
> >>
> >> http://apache.sunsite.ualberta.ca/subversion/subversion-1.7.2.tar.bz2
> >>
> >> I've included the diff below. I've filtered out all of the path
> >> differences in the comments ("/*@SWIG:..." <mailto:/*@SWIG:...>).
> >>
> >> Shane Turner
> >>
> >> diff -rwB -I '.*@SWIG:.*'
> >> subversion-1.7.4bed3649c532/subversion/bindings/swig/python/core.c
> >> subversion-1.7/subversion/bindings/swig/python/core.c
> >> 30985,30986c30985,30986
> >> < SWIG_Python_SetConstant(d,
> >> "SVN_VER_PATCH",SWIG_From_long((long)(1)));
> >> < SWIG_Python_SetConstant(d,
> >> "SVN_VER_MICRO",SWIG_From_long((long)(1)));
> >> ---
> >> > SWIG_Python_SetConstant(d,
> >> "SVN_VER_PATCH",SWIG_From_long((long)(2)));
> >> > SWIG_Python_SetConstant(d,
> >> "SVN_VER_MICRO",SWIG_From_long((long)(2)));
> >> 30988c30988
> >> < SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> >> (r1186859)"));
> >> ---
> >> > SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> >> (r1207936)"));
> >> 30990,30993c30990,30993
> >> *< SWIG_Python_SetConstant(d,
> >> "SVN_VER_REVISION",SWIG_From_long((long)(1186859)));*
> >> < SWIG_Python_SetConstant(d,
> >> "SVN_VER_NUM",SWIG_FromCharPtr("1.7.1"));
> >> < SWIG_Python_SetConstant(d,
> >> "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.1"));
> >> < SWIG_Python_SetConstant(d,
> >> "SVN_VERSION",SWIG_FromCharPtr("1.7.1 (r1186859)"));
> >> ---
> >> *> SWIG_Python_SetConstant(d,
> >> "SVN_VER_REVISION",SWIG_From_long((long)(0)));*
> >> > SWIG_Python_SetConstant(d,
> >> "SVN_VER_NUM",SWIG_FromCharPtr("1.7.2"));
> >> > SWIG_Python_SetConstant(d,
> >> "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.2"));
> >> > SWIG_Python_SetConstant(d,
> >> "SVN_VERSION",SWIG_FromCharPtr("1.7.2 (r1207936)"));
> >> diff -rwB -I '.*@SWIG:.*'
> >> subversion-1.7.4bed3649c532/subversion/bindings/swig/ruby/core.c
> >> subversion-1.7/subversion/bindings/swig/ruby/core.c
> >> 37529,37530c37529,37530
> >> < rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(1)));
> >> < rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(1)));
> >> ---
> >> > rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(2)));
> >> > rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(2)));
> >> 37532c37532
> >> < rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
> >> (r1186859)"));
> >> ---
> >> > rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
> >> (r1207936)"));
> >> 37534,37537c37534,37537
> >> *< rb_define_const(mCore, "SVN_VER_REVISION",
> >> SWIG_From_int((int)(1186859)));*
> >> < rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.1"));
> >> < rb_define_const(mCore, "SVN_VER_NUMBER",
> >> SWIG_FromCharPtr("1.7.1"));
> >> < rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.1
> >> (r1186859)"));
> >> ---
> >> *> rb_define_const(mCore, "SVN_VER_REVISION",
> >> SWIG_From_int((int)(0)));*
> >> > rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.2"));
> >> > rb_define_const(mCore, "SVN_VER_NUMBER",
> >> SWIG_FromCharPtr("1.7.2"));
> >> > rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.2
> >> (r1207936)"));
> >>
> >>
> >> Shane,
> >> Thanks for letting us know about this. I'm guessing that these
> >> values come from the standard Subversion header file svn_version.h.
> >> When rolling the tarballs, I checked that the revision number was in
> >> there properly in the separately-generated file, but must confess
> >> that I'm not sure what the actual tarballs contain. Could you check
> >> and see if SVN_VER_REVISION is set appropriately in svn_version.h?
> >>
> >> Thanks,
> >> -Hyrum
> >>
> >>
> >>
> >> --
> >>
> >> uberSVN: Apache Subversion Made Easy
> >> http://www.uberSVN.com/
> >
>
> --
>
>
>
> Shane Turner
>
> Senior Software Developer
> phone +1 (902) 406–8375 x1008
> email Shane.Turner@NewPace.ca <ma...@newpace.ca>
> aim <ai...@newpace.ca>/msn
> <ms...@newpace.ca> Shane.Turner@NewPace.ca
> <ai...@newpace.ca>
> skype saturnjct <skype:saturnjct>
>
>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Wed, Dec 7, 2011, at 18:29, Stefan Sperling wrote:
> On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
> > Should I open a bug report to have the packages regenerated,
>
> No. Releases are never regenerated. That would invalidate signatures
> developers sent for the release.[*]
>
> We'll have to figure out the source of the problem and then try
> to avoid it in future releases.
>
> [*] These signatures are important to the release process because having
> multiple signatures proofs the release wasn't made by a single individual
> but by the Apache Subversion Project Member Committee which is legally
> part of the ASF. This protects individual developers from legal attacks
> because the ASF needs to be attacked instead.
It also allows consumers of the release to verify its authenticity.
>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings
for Python and Ruby?
Posted by Daniel Shahaf <da...@elego.de>.
Thanks for confirming the fix.
For the record, r1211582 did fix the issue you identified, but there was
a separate issue in the rolling of the nightly tarballs --- which
r1212350 fixes.
Shane Turner wrote on Fri, Dec 09, 2011 at 10:22:20 -0400:
> I didn't look carefully enough at the revision. I expected it to be
> corrected based on your comment that you expected it to be fixed in
> the next nightly build.
>
> In any case, it does appear to be fixed now in the nightly tar files
> found in
> http://ci.apache.org/projects/subversion/nightlies/dist/r1212357/
>
>
> Thanks for the fix, Daniel.
>
> $ grep SVN_VER_REVISION
> subversion-{1.7.1,1.7.2,nightly}/subversion/include/svn_version.h
> subversion-1.7.1/subversion/include/svn_version.h:#define
> SVN_VER_REVISION 1186859
> subversion-1.7.2/subversion/include/svn_version.h:#define
> SVN_VER_REVISION 0
> subversion-nightly/subversion/include/svn_version.h:#define
> SVN_VER_REVISION 1212357
>
> $ echo "1.7.1"; find subversion-1.7.1 -type f | xargs egrep 1186859
> ; echo; echo "NIGHTLY"; find subversion-nightly -type f | xargs
> egrep 1212357
> 1.7.1
> subversion-1.7.1/subversion/bindings/swig/perl/native/core.c:
> sv_setsv(sv, SWIG_FromCharPtr(" (r1186859)"));
> subversion-1.7.1/subversion/bindings/swig/perl/native/core.c:
> sv_setsv(sv, SWIG_From_int SWIG_PERL_CALL_ARGS_1((int)(1186859)));
> subversion-1.7.1/subversion/bindings/swig/perl/native/core.c:
> sv_setsv(sv, SWIG_FromCharPtr("1.7.1 (r1186859)"));
> subversion-1.7.1/subversion/bindings/swig/ruby/core.c:
> rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
> (r1186859)"));
> subversion-1.7.1/subversion/bindings/swig/ruby/core.c:
> rb_define_const(mCore, "SVN_VER_REVISION",
> SWIG_From_int((int)(1186859)));
> subversion-1.7.1/subversion/bindings/swig/ruby/core.c:
> rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.1
> (r1186859)"));
> subversion-1.7.1/subversion/bindings/swig/python/core.c:
> SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> (r1186859)"));
> subversion-1.7.1/subversion/bindings/swig/python/core.c:
> SWIG_Python_SetConstant(d,
> "SVN_VER_REVISION",SWIG_From_long((long)(1186859)));
> subversion-1.7.1/subversion/bindings/swig/python/core.c:
> SWIG_Python_SetConstant(d, "SVN_VERSION",SWIG_FromCharPtr("1.7.1
> (r1186859)"));
> subversion-1.7.1/subversion/include/svn_version.h:#define
> SVN_VER_TAG " (r1186859)"
> subversion-1.7.1/subversion/include/svn_version.h:#define
> SVN_VER_REVISION 1186859
>
> NIGHTLY
> subversion-nightly/subversion/bindings/swig/perl/native/core.c:
> sv_setsv(sv, SWIG_FromCharPtr(" (r1212357)"));
> subversion-nightly/subversion/bindings/swig/perl/native/core.c:
> sv_setsv(sv, SWIG_From_int SWIG_PERL_CALL_ARGS_1((int)(1212357)));
> subversion-nightly/subversion/bindings/swig/perl/native/core.c:
> sv_setsv(sv, SWIG_FromCharPtr("1.8.0 (r1212357)"));
> subversion-nightly/subversion/bindings/swig/ruby/core.c:
> rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
> (r1212357)"));
> subversion-nightly/subversion/bindings/swig/ruby/core.c:
> rb_define_const(mCore, "SVN_VER_REVISION",
> SWIG_From_int((int)(1212357)));
> subversion-nightly/subversion/bindings/swig/ruby/core.c:
> rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.8.0
> (r1212357)"));
> subversion-nightly/subversion/bindings/swig/python/core.c:
> SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> (r1212357)"));
> subversion-nightly/subversion/bindings/swig/python/core.c:
> SWIG_Python_SetConstant(d,
> "SVN_VER_REVISION",SWIG_From_long((long)(1212357)));
> subversion-nightly/subversion/bindings/swig/python/core.c:
> SWIG_Python_SetConstant(d, "SVN_VERSION",SWIG_FromCharPtr("1.8.0
> (r1212357)"));
> subversion-nightly/subversion/include/svn_version.h:#define
> SVN_VER_TAG " (r1212357)"
> subversion-nightly/subversion/include/svn_version.h:#define
> SVN_VER_REVISION 1212357
>
> Shane
>
> On December-08-11 2:52:31 PM, Daniel Shahaf wrote:
> >Thanks for checking, Shane. I note that you checked r1211287, which is
> >prior to my yesterday's fix (r1211582), so the bogus values are expected.
> >
> >Shane Turner wrote on Thu, Dec 08, 2011 at 14:39:03 -0400:
> >>Looks like the problem is still there:
> >>
> >>$ grep SVN_VER_REVISION
> >>subversion-{1.7.1,1.7.2,nightly}/subversion/include/svn_version.h
> >>subversion-1.7.1/subversion/include/svn_version.h:#define
> >>SVN_VER_REVISION 1186859
> >>subversion-1.7.2/subversion/include/svn_version.h:#define
> >>SVN_VER_REVISION 0
> >>subversion-nightly/subversion/include/svn_version.h:#define
> >>SVN_VER_REVISION 0
> >>
> >>The nightly is http://ci.apache.org/projects/subversion/nightlies/dist/r1211287/subversion-nightly.tar.bz2
> >>
> >>Shane
> >>
> >>On 07/12/2011 2:35 PM, Daniel Shahaf wrote:
> >>>r1211582 should make things better.
> >>>
> >>>I think the nightly releases were also affected by this bug, in which
> >>>case tonight's nightly roll should confirm the fix.
> >>>
> >>>http://subversion.apache.org/source-code.html#nightlies
> >>>
> >>>On Wed, Dec 7, 2011, at 19:56, Daniel Shahaf wrote:
> >>>>On Wed, Dec 7, 2011, at 19:53, Daniel Shahaf wrote:
> >>>>>On Wed, Dec 7, 2011, at 11:43, Hyrum K Wright wrote:
> >>>>>>On Wed, Dec 7, 2011 at 11:29 AM, Stefan Sperling<st...@elego.de> wrote:
> >>>>>>>On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
> >>>>>>>>Should I open a bug report to have the packages regenerated,
> >>>>>>>No. Releases are never regenerated. That would invalidate signatures
> >>>>>>>developers sent for the release.[*]
> >>>>>>>
> >>>>>>>We'll have to figure out the source of the problem and then try
> >>>>>>>to avoid it in future releases.
> >>>>>>It may be related to the sed problem we were having in the 1.7 RC
> >>>>>>series. Apparently one of scripts relied upon GNU sed which wasn't
> >>>>>>installed on people.apache.org. I had been using a custom install of
> >>>>>>it, but I thought Daniel had fixed the offending script to not require
> >>>>>>GNU sed. 1.7.2 represents the first release in which I relied upon
> >>>>>>the system sed, and not my custom one.
> >>>>>>
> >>>>>r1159741
> >>>>>
> >>>>>However, SVN_VER_REVISION on the 1.7.2 tag is wrong.
> >>>>... but SVN_VER_TAG, which incorporates the revnum, is right.
> >>>>
> >>>>Hmm.
> >>>>
> >>
> >>--
> >>
> >>
> >>
> >> Shane Turner
> >>
> >> Senior Software Developer
> >>phone +1 (902) 406–8375 x1008
> >>email Shane.Turner@NewPace.ca<ma...@newpace.ca>
> >>aim<ai...@newpace.ca>/msn
> >><ms...@newpace.ca>
> >> Shane.Turner@NewPace.ca
> >><ai...@newpace.ca>
> >>skype saturnjct<skype:saturnjct>
> >>
>
> --
> --
> Shane Turner
> Senior Software Developer
> phone +1 (902) 406–8375 x1008
> email Shane.Turner@NewPace.ca <ma...@newpace.ca>
> aim <ai...@newpace.ca>/msn
> <ms...@newpace.ca>
> Shane.Turner@NewPace.ca
> <ai...@newpace.ca>
> skype saturnjct <skype:saturnjct>
>
>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings
for Python and Ruby?
Posted by Shane Turner <sh...@newpace.ca>.
I didn't look carefully enough at the revision. I expected it to be
corrected based on your comment that you expected it to be fixed in the
next nightly build.
In any case, it does appear to be fixed now in the nightly tar files
found in
http://ci.apache.org/projects/subversion/nightlies/dist/r1212357/
Thanks for the fix, Daniel.
$ grep SVN_VER_REVISION
subversion-{1.7.1,1.7.2,nightly}/subversion/include/svn_version.h
subversion-1.7.1/subversion/include/svn_version.h:#define
SVN_VER_REVISION 1186859
subversion-1.7.2/subversion/include/svn_version.h:#define
SVN_VER_REVISION 0
subversion-nightly/subversion/include/svn_version.h:#define
SVN_VER_REVISION 1212357
$ echo "1.7.1"; find subversion-1.7.1 -type f | xargs egrep 1186859 ;
echo; echo "NIGHTLY"; find subversion-nightly -type f | xargs egrep
1212357
1.7.1
subversion-1.7.1/subversion/bindings/swig/perl/native/core.c:
sv_setsv(sv, SWIG_FromCharPtr(" (r1186859)"));
subversion-1.7.1/subversion/bindings/swig/perl/native/core.c:
sv_setsv(sv, SWIG_From_int SWIG_PERL_CALL_ARGS_1((int)(1186859)));
subversion-1.7.1/subversion/bindings/swig/perl/native/core.c:
sv_setsv(sv, SWIG_FromCharPtr("1.7.1 (r1186859)"));
subversion-1.7.1/subversion/bindings/swig/ruby/core.c:
rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr(" (r1186859)"));
subversion-1.7.1/subversion/bindings/swig/ruby/core.c:
rb_define_const(mCore, "SVN_VER_REVISION",
SWIG_From_int((int)(1186859)));
subversion-1.7.1/subversion/bindings/swig/ruby/core.c:
rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.1
(r1186859)"));
subversion-1.7.1/subversion/bindings/swig/python/core.c:
SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
(r1186859)"));
subversion-1.7.1/subversion/bindings/swig/python/core.c:
SWIG_Python_SetConstant(d,
"SVN_VER_REVISION",SWIG_From_long((long)(1186859)));
subversion-1.7.1/subversion/bindings/swig/python/core.c:
SWIG_Python_SetConstant(d, "SVN_VERSION",SWIG_FromCharPtr("1.7.1
(r1186859)"));
subversion-1.7.1/subversion/include/svn_version.h:#define SVN_VER_TAG
" (r1186859)"
subversion-1.7.1/subversion/include/svn_version.h:#define
SVN_VER_REVISION 1186859
NIGHTLY
subversion-nightly/subversion/bindings/swig/perl/native/core.c:
sv_setsv(sv, SWIG_FromCharPtr(" (r1212357)"));
subversion-nightly/subversion/bindings/swig/perl/native/core.c:
sv_setsv(sv, SWIG_From_int SWIG_PERL_CALL_ARGS_1((int)(1212357)));
subversion-nightly/subversion/bindings/swig/perl/native/core.c:
sv_setsv(sv, SWIG_FromCharPtr("1.8.0 (r1212357)"));
subversion-nightly/subversion/bindings/swig/ruby/core.c:
rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr(" (r1212357)"));
subversion-nightly/subversion/bindings/swig/ruby/core.c:
rb_define_const(mCore, "SVN_VER_REVISION",
SWIG_From_int((int)(1212357)));
subversion-nightly/subversion/bindings/swig/ruby/core.c:
rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.8.0
(r1212357)"));
subversion-nightly/subversion/bindings/swig/python/core.c:
SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
(r1212357)"));
subversion-nightly/subversion/bindings/swig/python/core.c:
SWIG_Python_SetConstant(d,
"SVN_VER_REVISION",SWIG_From_long((long)(1212357)));
subversion-nightly/subversion/bindings/swig/python/core.c:
SWIG_Python_SetConstant(d, "SVN_VERSION",SWIG_FromCharPtr("1.8.0
(r1212357)"));
subversion-nightly/subversion/include/svn_version.h:#define SVN_VER_TAG
" (r1212357)"
subversion-nightly/subversion/include/svn_version.h:#define
SVN_VER_REVISION 1212357
Shane
On December-08-11 2:52:31 PM, Daniel Shahaf wrote:
> Thanks for checking, Shane. I note that you checked r1211287, which is
> prior to my yesterday's fix (r1211582), so the bogus values are expected.
>
> Shane Turner wrote on Thu, Dec 08, 2011 at 14:39:03 -0400:
>> Looks like the problem is still there:
>>
>> $ grep SVN_VER_REVISION
>> subversion-{1.7.1,1.7.2,nightly}/subversion/include/svn_version.h
>> subversion-1.7.1/subversion/include/svn_version.h:#define
>> SVN_VER_REVISION 1186859
>> subversion-1.7.2/subversion/include/svn_version.h:#define
>> SVN_VER_REVISION 0
>> subversion-nightly/subversion/include/svn_version.h:#define
>> SVN_VER_REVISION 0
>>
>> The nightly is http://ci.apache.org/projects/subversion/nightlies/dist/r1211287/subversion-nightly.tar.bz2
>>
>> Shane
>>
>> On 07/12/2011 2:35 PM, Daniel Shahaf wrote:
>>> r1211582 should make things better.
>>>
>>> I think the nightly releases were also affected by this bug, in which
>>> case tonight's nightly roll should confirm the fix.
>>>
>>> http://subversion.apache.org/source-code.html#nightlies
>>>
>>> On Wed, Dec 7, 2011, at 19:56, Daniel Shahaf wrote:
>>>> On Wed, Dec 7, 2011, at 19:53, Daniel Shahaf wrote:
>>>>> On Wed, Dec 7, 2011, at 11:43, Hyrum K Wright wrote:
>>>>>> On Wed, Dec 7, 2011 at 11:29 AM, Stefan Sperling<st...@elego.de> wrote:
>>>>>>> On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
>>>>>>>> Should I open a bug report to have the packages regenerated,
>>>>>>> No. Releases are never regenerated. That would invalidate signatures
>>>>>>> developers sent for the release.[*]
>>>>>>>
>>>>>>> We'll have to figure out the source of the problem and then try
>>>>>>> to avoid it in future releases.
>>>>>> It may be related to the sed problem we were having in the 1.7 RC
>>>>>> series. Apparently one of scripts relied upon GNU sed which wasn't
>>>>>> installed on people.apache.org. I had been using a custom install of
>>>>>> it, but I thought Daniel had fixed the offending script to not require
>>>>>> GNU sed. 1.7.2 represents the first release in which I relied upon
>>>>>> the system sed, and not my custom one.
>>>>>>
>>>>> r1159741
>>>>>
>>>>> However, SVN_VER_REVISION on the 1.7.2 tag is wrong.
>>>> ... but SVN_VER_TAG, which incorporates the revnum, is right.
>>>>
>>>> Hmm.
>>>>
>>
>> --
>>
>>
>>
>> Shane Turner
>>
>> Senior Software Developer
>> phone +1 (902) 406–8375 x1008
>> email Shane.Turner@NewPace.ca<ma...@newpace.ca>
>> aim<ai...@newpace.ca>/msn
>> <ms...@newpace.ca>
>> Shane.Turner@NewPace.ca
>> <ai...@newpace.ca>
>> skype saturnjct<skype:saturnjct>
>>
--
--
Shane Turner
Senior Software Developer
phone +1 (902) 406–8375 x1008
email Shane.Turner@NewPace.ca <ma...@newpace.ca>
aim <ai...@newpace.ca>/msn
<ms...@newpace.ca> Shane.Turner@NewPace.ca
<ai...@newpace.ca>
skype saturnjct <skype:saturnjct>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings
for Python and Ruby?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Thanks for checking, Shane. I note that you checked r1211287, which is
prior to my yesterday's fix (r1211582), so the bogus values are expected.
Shane Turner wrote on Thu, Dec 08, 2011 at 14:39:03 -0400:
> Looks like the problem is still there:
>
> $ grep SVN_VER_REVISION
> subversion-{1.7.1,1.7.2,nightly}/subversion/include/svn_version.h
> subversion-1.7.1/subversion/include/svn_version.h:#define
> SVN_VER_REVISION 1186859
> subversion-1.7.2/subversion/include/svn_version.h:#define
> SVN_VER_REVISION 0
> subversion-nightly/subversion/include/svn_version.h:#define
> SVN_VER_REVISION 0
>
> The nightly is http://ci.apache.org/projects/subversion/nightlies/dist/r1211287/subversion-nightly.tar.bz2
>
> Shane
>
> On 07/12/2011 2:35 PM, Daniel Shahaf wrote:
> >r1211582 should make things better.
> >
> >I think the nightly releases were also affected by this bug, in which
> >case tonight's nightly roll should confirm the fix.
> >
> >http://subversion.apache.org/source-code.html#nightlies
> >
> >On Wed, Dec 7, 2011, at 19:56, Daniel Shahaf wrote:
> >>On Wed, Dec 7, 2011, at 19:53, Daniel Shahaf wrote:
> >>>On Wed, Dec 7, 2011, at 11:43, Hyrum K Wright wrote:
> >>>>On Wed, Dec 7, 2011 at 11:29 AM, Stefan Sperling<st...@elego.de> wrote:
> >>>>>On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
> >>>>>>Should I open a bug report to have the packages regenerated,
> >>>>>No. Releases are never regenerated. That would invalidate signatures
> >>>>>developers sent for the release.[*]
> >>>>>
> >>>>>We'll have to figure out the source of the problem and then try
> >>>>>to avoid it in future releases.
> >>>>It may be related to the sed problem we were having in the 1.7 RC
> >>>>series. Apparently one of scripts relied upon GNU sed which wasn't
> >>>>installed on people.apache.org. I had been using a custom install of
> >>>>it, but I thought Daniel had fixed the offending script to not require
> >>>>GNU sed. 1.7.2 represents the first release in which I relied upon
> >>>>the system sed, and not my custom one.
> >>>>
> >>>r1159741
> >>>
> >>>However, SVN_VER_REVISION on the 1.7.2 tag is wrong.
> >>... but SVN_VER_TAG, which incorporates the revnum, is right.
> >>
> >>Hmm.
> >>
>
> --
>
>
>
> Shane Turner
>
> Senior Software Developer
> phone +1 (902) 406–8375 x1008
> email Shane.Turner@NewPace.ca <ma...@newpace.ca>
> aim <ai...@newpace.ca>/msn
> <ms...@newpace.ca>
> Shane.Turner@NewPace.ca
> <ai...@newpace.ca>
> skype saturnjct <skype:saturnjct>
>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings
for Python and Ruby?
Posted by Shane Turner <sh...@newpace.ca>.
Looks like the problem is still there:
$ grep SVN_VER_REVISION
subversion-{1.7.1,1.7.2,nightly}/subversion/include/svn_version.h
subversion-1.7.1/subversion/include/svn_version.h:#define
SVN_VER_REVISION 1186859
subversion-1.7.2/subversion/include/svn_version.h:#define
SVN_VER_REVISION 0
subversion-nightly/subversion/include/svn_version.h:#define
SVN_VER_REVISION 0
The nightly is
http://ci.apache.org/projects/subversion/nightlies/dist/r1211287/subversion-nightly.tar.bz2
Shane
On 07/12/2011 2:35 PM, Daniel Shahaf wrote:
> r1211582 should make things better.
>
> I think the nightly releases were also affected by this bug, in which
> case tonight's nightly roll should confirm the fix.
>
> http://subversion.apache.org/source-code.html#nightlies
>
> On Wed, Dec 7, 2011, at 19:56, Daniel Shahaf wrote:
>> On Wed, Dec 7, 2011, at 19:53, Daniel Shahaf wrote:
>>> On Wed, Dec 7, 2011, at 11:43, Hyrum K Wright wrote:
>>>> On Wed, Dec 7, 2011 at 11:29 AM, Stefan Sperling<st...@elego.de> wrote:
>>>>> On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
>>>>>> Should I open a bug report to have the packages regenerated,
>>>>> No. Releases are never regenerated. That would invalidate signatures
>>>>> developers sent for the release.[*]
>>>>>
>>>>> We'll have to figure out the source of the problem and then try
>>>>> to avoid it in future releases.
>>>> It may be related to the sed problem we were having in the 1.7 RC
>>>> series. Apparently one of scripts relied upon GNU sed which wasn't
>>>> installed on people.apache.org. I had been using a custom install of
>>>> it, but I thought Daniel had fixed the offending script to not require
>>>> GNU sed. 1.7.2 represents the first release in which I relied upon
>>>> the system sed, and not my custom one.
>>>>
>>> r1159741
>>>
>>> However, SVN_VER_REVISION on the 1.7.2 tag is wrong.
>> ... but SVN_VER_TAG, which incorporates the revnum, is right.
>>
>> Hmm.
>>
--
Shane Turner
Senior Software Developer
phone +1 (902) 406–8375 x1008
email Shane.Turner@NewPace.ca <ma...@newpace.ca>
aim <ai...@newpace.ca>/msn
<ms...@newpace.ca> Shane.Turner@NewPace.ca
<ai...@newpace.ca>
skype saturnjct <skype:saturnjct>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
r1211582 should make things better.
I think the nightly releases were also affected by this bug, in which
case tonight's nightly roll should confirm the fix.
http://subversion.apache.org/source-code.html#nightlies
On Wed, Dec 7, 2011, at 19:56, Daniel Shahaf wrote:
> On Wed, Dec 7, 2011, at 19:53, Daniel Shahaf wrote:
> > On Wed, Dec 7, 2011, at 11:43, Hyrum K Wright wrote:
> > > On Wed, Dec 7, 2011 at 11:29 AM, Stefan Sperling <st...@elego.de> wrote:
> > > > On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
> > > >> Should I open a bug report to have the packages regenerated,
> > > >
> > > > No. Releases are never regenerated. That would invalidate signatures
> > > > developers sent for the release.[*]
> > > >
> > > > We'll have to figure out the source of the problem and then try
> > > > to avoid it in future releases.
> > >
> > > It may be related to the sed problem we were having in the 1.7 RC
> > > series. Apparently one of scripts relied upon GNU sed which wasn't
> > > installed on people.apache.org. I had been using a custom install of
> > > it, but I thought Daniel had fixed the offending script to not require
> > > GNU sed. 1.7.2 represents the first release in which I relied upon
> > > the system sed, and not my custom one.
> > >
> >
> > r1159741
> >
> > However, SVN_VER_REVISION on the 1.7.2 tag is wrong.
>
> ... but SVN_VER_TAG, which incorporates the revnum, is right.
>
> Hmm.
>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
Posted by Daniel Shahaf <da...@elego.de>.
On Wed, Dec 7, 2011, at 19:53, Daniel Shahaf wrote:
> On Wed, Dec 7, 2011, at 11:43, Hyrum K Wright wrote:
> > On Wed, Dec 7, 2011 at 11:29 AM, Stefan Sperling <st...@elego.de> wrote:
> > > On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
> > >> Should I open a bug report to have the packages regenerated,
> > >
> > > No. Releases are never regenerated. That would invalidate signatures
> > > developers sent for the release.[*]
> > >
> > > We'll have to figure out the source of the problem and then try
> > > to avoid it in future releases.
> >
> > It may be related to the sed problem we were having in the 1.7 RC
> > series. Apparently one of scripts relied upon GNU sed which wasn't
> > installed on people.apache.org. I had been using a custom install of
> > it, but I thought Daniel had fixed the offending script to not require
> > GNU sed. 1.7.2 represents the first release in which I relied upon
> > the system sed, and not my custom one.
> >
>
> r1159741
>
> However, SVN_VER_REVISION on the 1.7.2 tag is wrong.
... but SVN_VER_TAG, which incorporates the revnum, is right.
Hmm.
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Wed, Dec 7, 2011, at 11:43, Hyrum K Wright wrote:
> On Wed, Dec 7, 2011 at 11:29 AM, Stefan Sperling <st...@elego.de> wrote:
> > On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
> >> Should I open a bug report to have the packages regenerated,
> >
> > No. Releases are never regenerated. That would invalidate signatures
> > developers sent for the release.[*]
> >
> > We'll have to figure out the source of the problem and then try
> > to avoid it in future releases.
>
> It may be related to the sed problem we were having in the 1.7 RC
> series. Apparently one of scripts relied upon GNU sed which wasn't
> installed on people.apache.org. I had been using a custom install of
> it, but I thought Daniel had fixed the offending script to not require
> GNU sed. 1.7.2 represents the first release in which I relied upon
> the system sed, and not my custom one.
>
r1159741
However, SVN_VER_REVISION on the 1.7.2 tag is wrong.
> I *thought* I'd verified the header file prior to posting the release
> for signing, but apparently not. :(
>
> > [*] These signatures are important to the release process because having
> > multiple signatures proofs the release wasn't made by a single individual
> > but by the Apache Subversion Project Member Committee which is legally
> > part of the ASF. This protects individual developers from legal attacks
> > because the ASF needs to be attacked instead.
>
> "Project *Management* Committee" :)
>
> -Hyrum
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Wed, Dec 7, 2011 at 11:29 AM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
>> Should I open a bug report to have the packages regenerated,
>
> No. Releases are never regenerated. That would invalidate signatures
> developers sent for the release.[*]
>
> We'll have to figure out the source of the problem and then try
> to avoid it in future releases.
It may be related to the sed problem we were having in the 1.7 RC
series. Apparently one of scripts relied upon GNU sed which wasn't
installed on people.apache.org. I had been using a custom install of
it, but I thought Daniel had fixed the offending script to not require
GNU sed. 1.7.2 represents the first release in which I relied upon
the system sed, and not my custom one.
I *thought* I'd verified the header file prior to posting the release
for signing, but apparently not. :(
> [*] These signatures are important to the release process because having
> multiple signatures proofs the release wasn't made by a single individual
> but by the Apache Subversion Project Member Committee which is legally
> part of the ASF. This protects individual developers from legal attacks
> because the ASF needs to be attacked instead.
"Project *Management* Committee" :)
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Dec 07, 2011 at 11:23:30AM -0400, Shane Turner wrote:
> Should I open a bug report to have the packages regenerated,
No. Releases are never regenerated. That would invalidate signatures
developers sent for the release.[*]
We'll have to figure out the source of the problem and then try
to avoid it in future releases.
[*] These signatures are important to the release process because having
multiple signatures proofs the release wasn't made by a single individual
but by the Apache Subversion Project Member Committee which is legally
part of the ASF. This protects individual developers from legal attacks
because the ASF needs to be attacked instead.
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings
for Python and Ruby?
Posted by Shane Turner <sh...@newpace.ca>.
Should I open a bug report to have the packages regenerated, assuming
that will fix the problem? I would take a look at the scripts to build
the source archives if I knew where they were.
Shane
On 06/12/2011 12:28 PM, Shane Turner wrote:
> subversion/include/svn_version.h is incorrect as well.
>
> I'm not sure that the associated comment is correct given it appears
> to be used for more than the Windows build?
>
> /** Revision number: The repository revision number of this release.
> *
> * This constant is used to generate the build number part of the Windows
> * file version. Its value remains 0 in the repository.
> *
> * When rolling a tarball, we automatically replace it with what we
> * guess to be the correct revision number.
> */
> #define SVN_VER_REVISION 0
>
>
> On December-06-11 12:19:42 PM, Hyrum K Wright wrote:
>>
>> On Tue, Dec 6, 2011 at 7:47 AM, Shane Turner <shane.turner@newpace.ca
>> <ma...@newpace.ca>> wrote:
>>
>> I was just taking a look at the differences between Subversion
>> 1.7.1 and 1.7.2 and noticed a couple of diffs that look odd.
>>
>> In subversion/bindings/swig/python/core.c and
>> subversion/bindings/swig/ruby/core.c, the value of
>> SVN_VER_REVISION changed from the numeric revision number
>> (previously 1186859) to 0. I think it's supposed to be 1207936.
>>
>> Is this a bug, or intended? Be forewarned that I don't use this
>> aspect of Subversion. I just happened to notice.
>>
>> The code I was examining was from
>>
>> http://apache.sunsite.ualberta.ca/subversion/subversion-1.7.2.tar.bz2
>>
>> I've included the diff below. I've filtered out all of the path
>> differences in the comments ("/*@SWIG:..." <mailto:/*@SWIG:...>).
>>
>> Shane Turner
>>
>> diff -rwB -I '.*@SWIG:.*'
>> subversion-1.7.4bed3649c532/subversion/bindings/swig/python/core.c
>> subversion-1.7/subversion/bindings/swig/python/core.c
>> 30985,30986c30985,30986
>> < SWIG_Python_SetConstant(d,
>> "SVN_VER_PATCH",SWIG_From_long((long)(1)));
>> < SWIG_Python_SetConstant(d,
>> "SVN_VER_MICRO",SWIG_From_long((long)(1)));
>> ---
>> > SWIG_Python_SetConstant(d,
>> "SVN_VER_PATCH",SWIG_From_long((long)(2)));
>> > SWIG_Python_SetConstant(d,
>> "SVN_VER_MICRO",SWIG_From_long((long)(2)));
>> 30988c30988
>> < SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
>> (r1186859)"));
>> ---
>> > SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
>> (r1207936)"));
>> 30990,30993c30990,30993
>> *< SWIG_Python_SetConstant(d,
>> "SVN_VER_REVISION",SWIG_From_long((long)(1186859)));*
>> < SWIG_Python_SetConstant(d,
>> "SVN_VER_NUM",SWIG_FromCharPtr("1.7.1"));
>> < SWIG_Python_SetConstant(d,
>> "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.1"));
>> < SWIG_Python_SetConstant(d,
>> "SVN_VERSION",SWIG_FromCharPtr("1.7.1 (r1186859)"));
>> ---
>> *> SWIG_Python_SetConstant(d,
>> "SVN_VER_REVISION",SWIG_From_long((long)(0)));*
>> > SWIG_Python_SetConstant(d,
>> "SVN_VER_NUM",SWIG_FromCharPtr("1.7.2"));
>> > SWIG_Python_SetConstant(d,
>> "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.2"));
>> > SWIG_Python_SetConstant(d,
>> "SVN_VERSION",SWIG_FromCharPtr("1.7.2 (r1207936)"));
>> diff -rwB -I '.*@SWIG:.*'
>> subversion-1.7.4bed3649c532/subversion/bindings/swig/ruby/core.c
>> subversion-1.7/subversion/bindings/swig/ruby/core.c
>> 37529,37530c37529,37530
>> < rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(1)));
>> < rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(1)));
>> ---
>> > rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(2)));
>> > rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(2)));
>> 37532c37532
>> < rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
>> (r1186859)"));
>> ---
>> > rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
>> (r1207936)"));
>> 37534,37537c37534,37537
>> *< rb_define_const(mCore, "SVN_VER_REVISION",
>> SWIG_From_int((int)(1186859)));*
>> < rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.1"));
>> < rb_define_const(mCore, "SVN_VER_NUMBER",
>> SWIG_FromCharPtr("1.7.1"));
>> < rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.1
>> (r1186859)"));
>> ---
>> *> rb_define_const(mCore, "SVN_VER_REVISION",
>> SWIG_From_int((int)(0)));*
>> > rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.2"));
>> > rb_define_const(mCore, "SVN_VER_NUMBER",
>> SWIG_FromCharPtr("1.7.2"));
>> > rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.2
>> (r1207936)"));
>>
>>
>> Shane,
>> Thanks for letting us know about this. I'm guessing that these
>> values come from the standard Subversion header file svn_version.h.
>> When rolling the tarballs, I checked that the revision number was in
>> there properly in the separately-generated file, but must confess
>> that I'm not sure what the actual tarballs contain. Could you check
>> and see if SVN_VER_REVISION is set appropriately in svn_version.h?
>>
>> Thanks,
>> -Hyrum
>>
>>
>>
>> --
>>
>> uberSVN: Apache Subversion Made Easy
>> http://www.uberSVN.com/
>
--
Shane Turner
Senior Software Developer
phone +1 (902) 406–8375 x1008
email Shane.Turner@NewPace.ca <ma...@newpace.ca>
aim <ai...@newpace.ca>/msn
<ms...@newpace.ca> Shane.Turner@NewPace.ca
<ai...@newpace.ca>
skype saturnjct <skype:saturnjct>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings
for Python and Ruby?
Posted by Shane Turner <sh...@newpace.ca>.
subversion/include/svn_version.h is incorrect as well.
I'm not sure that the associated comment is correct given it appears to
be used for more than the Windows build?
/** Revision number: The repository revision number of this release.
*
* This constant is used to generate the build number part of the
Windows
* file version. Its value remains 0 in the repository.
*
* When rolling a tarball, we automatically replace it with what we
* guess to be the correct revision number.
*/
#define SVN_VER_REVISION 0
On December-06-11 12:19:42 PM, Hyrum K Wright wrote:
>
> On Tue, Dec 6, 2011 at 7:47 AM, Shane Turner <shane.turner@newpace.ca
> <ma...@newpace.ca>> wrote:
>
> I was just taking a look at the differences between Subversion
> 1.7.1 and 1.7.2 and noticed a couple of diffs that look odd.
>
> In subversion/bindings/swig/python/core.c and
> subversion/bindings/swig/ruby/core.c, the value of
> SVN_VER_REVISION changed from the numeric revision number
> (previously 1186859) to 0. I think it's supposed to be 1207936.
>
> Is this a bug, or intended? Be forewarned that I don't use this
> aspect of Subversion. I just happened to notice.
>
> The code I was examining was from
> http://apache.sunsite.ualberta.ca/subversion/subversion-1.7.2.tar.bz2
>
> I've included the diff below. I've filtered out all of the path
> differences in the comments ("/*@SWIG:..." <mailto:/*@SWIG:...>).
>
> Shane Turner
>
> diff -rwB -I '.*@SWIG:.*'
> subversion-1.7.4bed3649c532/subversion/bindings/swig/python/core.c
> subversion-1.7/subversion/bindings/swig/python/core.c
> 30985,30986c30985,30986
> < SWIG_Python_SetConstant(d,
> "SVN_VER_PATCH",SWIG_From_long((long)(1)));
> < SWIG_Python_SetConstant(d,
> "SVN_VER_MICRO",SWIG_From_long((long)(1)));
> ---
> > SWIG_Python_SetConstant(d,
> "SVN_VER_PATCH",SWIG_From_long((long)(2)));
> > SWIG_Python_SetConstant(d,
> "SVN_VER_MICRO",SWIG_From_long((long)(2)));
> 30988c30988
> < SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> (r1186859)"));
> ---
> > SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> (r1207936)"));
> 30990,30993c30990,30993
> *< SWIG_Python_SetConstant(d,
> "SVN_VER_REVISION",SWIG_From_long((long)(1186859)));*
> < SWIG_Python_SetConstant(d,
> "SVN_VER_NUM",SWIG_FromCharPtr("1.7.1"));
> < SWIG_Python_SetConstant(d,
> "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.1"));
> < SWIG_Python_SetConstant(d,
> "SVN_VERSION",SWIG_FromCharPtr("1.7.1 (r1186859)"));
> ---
> *> SWIG_Python_SetConstant(d,
> "SVN_VER_REVISION",SWIG_From_long((long)(0)));*
> > SWIG_Python_SetConstant(d,
> "SVN_VER_NUM",SWIG_FromCharPtr("1.7.2"));
> > SWIG_Python_SetConstant(d,
> "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.2"));
> > SWIG_Python_SetConstant(d,
> "SVN_VERSION",SWIG_FromCharPtr("1.7.2 (r1207936)"));
> diff -rwB -I '.*@SWIG:.*'
> subversion-1.7.4bed3649c532/subversion/bindings/swig/ruby/core.c
> subversion-1.7/subversion/bindings/swig/ruby/core.c
> 37529,37530c37529,37530
> < rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(1)));
> < rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(1)));
> ---
> > rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(2)));
> > rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(2)));
> 37532c37532
> < rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
> (r1186859)"));
> ---
> > rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr("
> (r1207936)"));
> 37534,37537c37534,37537
> *< rb_define_const(mCore, "SVN_VER_REVISION",
> SWIG_From_int((int)(1186859)));*
> < rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.1"));
> < rb_define_const(mCore, "SVN_VER_NUMBER",
> SWIG_FromCharPtr("1.7.1"));
> < rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.1
> (r1186859)"));
> ---
> *> rb_define_const(mCore, "SVN_VER_REVISION",
> SWIG_From_int((int)(0)));*
> > rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.2"));
> > rb_define_const(mCore, "SVN_VER_NUMBER",
> SWIG_FromCharPtr("1.7.2"));
> > rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.2
> (r1207936)"));
>
>
> Shane,
> Thanks for letting us know about this. I'm guessing that these values
> come from the standard Subversion header file svn_version.h. When
> rolling the tarballs, I checked that the revision number was in there
> properly in the separately-generated file, but must confess that I'm
> not sure what the actual tarballs contain. Could you check and see if
> SVN_VER_REVISION is set appropriately in svn_version.h?
>
> Thanks,
> -Hyrum
>
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
--
--
Shane Turner
Senior Software Developer
phone +1 (902) 406–8375 x1008
email Shane.Turner@NewPace.ca <ma...@newpace.ca>
aim <ai...@newpace.ca>/msn
<ms...@newpace.ca> Shane.Turner@NewPace.ca
<ai...@newpace.ca>
skype saturnjct <skype:saturnjct>
Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for
Python and Ruby?
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Dec 6, 2011 at 7:47 AM, Shane Turner <sh...@newpace.ca>wrote:
> I was just taking a look at the differences between Subversion 1.7.1 and
> 1.7.2 and noticed a couple of diffs that look odd.
>
> In subversion/bindings/swig/python/core.c and
> subversion/bindings/swig/ruby/core.c, the value of SVN_VER_REVISION changed
> from the numeric revision number (previously 1186859) to 0. I think it's
> supposed to be 1207936.
>
> Is this a bug, or intended? Be forewarned that I don't use this aspect of
> Subversion. I just happened to notice.
>
> The code I was examining was from
> http://apache.sunsite.ualberta.ca/subversion/subversion-1.7.2.tar.bz2
>
> I've included the diff below. I've filtered out all of the path
> differences in the comments ("/*@SWIG:..." </*@SWIG:...>).
>
> Shane Turner
>
> diff -rwB -I '.*@SWIG:.*'
> subversion-1.7.4bed3649c532/subversion/bindings/swig/python/core.c
> subversion-1.7/subversion/bindings/swig/python/core.c
> 30985,30986c30985,30986
> < SWIG_Python_SetConstant(d, "SVN_VER_PATCH",SWIG_From_long((long)(1)));
> < SWIG_Python_SetConstant(d, "SVN_VER_MICRO",SWIG_From_long((long)(1)));
> ---
> > SWIG_Python_SetConstant(d, "SVN_VER_PATCH",SWIG_From_long((long)(2)));
> > SWIG_Python_SetConstant(d, "SVN_VER_MICRO",SWIG_From_long((long)(2)));
> 30988c30988
> < SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> (r1186859)"));
> ---
> > SWIG_Python_SetConstant(d, "SVN_VER_TAG",SWIG_FromCharPtr("
> (r1207936)"));
> 30990,30993c30990,30993
> *< SWIG_Python_SetConstant(d,
> "SVN_VER_REVISION",SWIG_From_long((long)(1186859)));*
> < SWIG_Python_SetConstant(d, "SVN_VER_NUM",SWIG_FromCharPtr("1.7.1"));
> < SWIG_Python_SetConstant(d, "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.1"));
> < SWIG_Python_SetConstant(d, "SVN_VERSION",SWIG_FromCharPtr("1.7.1
> (r1186859)"));
> ---
> *> SWIG_Python_SetConstant(d,
> "SVN_VER_REVISION",SWIG_From_long((long)(0)));*
> > SWIG_Python_SetConstant(d, "SVN_VER_NUM",SWIG_FromCharPtr("1.7.2"));
> > SWIG_Python_SetConstant(d, "SVN_VER_NUMBER",SWIG_FromCharPtr("1.7.2"));
> > SWIG_Python_SetConstant(d, "SVN_VERSION",SWIG_FromCharPtr("1.7.2
> (r1207936)"));
> diff -rwB -I '.*@SWIG:.*'
> subversion-1.7.4bed3649c532/subversion/bindings/swig/ruby/core.c
> subversion-1.7/subversion/bindings/swig/ruby/core.c
> 37529,37530c37529,37530
> < rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(1)));
> < rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(1)));
> ---
> > rb_define_const(mCore, "SVN_VER_PATCH", SWIG_From_int((int)(2)));
> > rb_define_const(mCore, "SVN_VER_MICRO", SWIG_From_int((int)(2)));
> 37532c37532
> < rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr(" (r1186859)"));
> ---
> > rb_define_const(mCore, "SVN_VER_TAG", SWIG_FromCharPtr(" (r1207936)"));
> 37534,37537c37534,37537
> *< rb_define_const(mCore, "SVN_VER_REVISION",
> SWIG_From_int((int)(1186859)));*
> < rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.1"));
> < rb_define_const(mCore, "SVN_VER_NUMBER", SWIG_FromCharPtr("1.7.1"));
> < rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.1
> (r1186859)"));
> ---
> *> rb_define_const(mCore, "SVN_VER_REVISION", SWIG_From_int((int)(0)));*
> > rb_define_const(mCore, "SVN_VER_NUM", SWIG_FromCharPtr("1.7.2"));
> > rb_define_const(mCore, "SVN_VER_NUMBER", SWIG_FromCharPtr("1.7.2"));
> > rb_define_const(mCore, "SVN_VERSION", SWIG_FromCharPtr("1.7.2
> (r1207936)"));
>
Shane,
Thanks for letting us know about this. I'm guessing that these values come
from the standard Subversion header file svn_version.h. When rolling the
tarballs, I checked that the revision number was in there properly in the
separately-generated file, but must confess that I'm not sure what the
actual tarballs contain. Could you check and see if SVN_VER_REVISION is
set appropriately in svn_version.h?
Thanks,
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/