You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2008/04/07 23:16:04 UTC
1.5.0-rc1 up for signing/testing
Good afternoon,
I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
signing. The magic revision is r30419.
http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/
As usual, signatures from full committers back to me, and enthusiastic
tester feedback is welcome. At this point, this candidate is not yet
blessed for wide release, so please don't make it available to people
not interested in test-driving the new release.
Distro package maintainers, please to NOT include any pre-release
builds, even blessed, into operating system distros. The reasons for
not doing so were very eloquently outlined by Karl in a mail, which is
summarized at the above address.
The quick version is: we don't guarantee compatibility between the
pre-releases and the final release, so if people install the release
canditate, all their repositories and working copies might break
unrepairably when they upgrade to 1.5.0 proper. We don't want that kind
of bad publicity, and neither do you.
-Hyrum
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Apr 10, 2008 at 9:17 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Paul Burba wrote:
>
> > Given that we have found several serious problems with RC1, in
> > particular these items in STATUS:
> >
> [...]
>
>
> > Shouldn't we push to quickly backport those fixes and roll RC2?
> >
>
> I would suggest letting people continue testing RC1 for a while until the
> rate of finding serious bugs falls off, unless testing is being impeded by
> these bugs. If we just release RC2 right now, we would statistically expect
> serious bugs to be found in it at a similar rate, so what would be the
> point?
>
> (A while might be 1 or 2 weeks?)
I can't believe you would suggest this. We found these bugs by luck
and only because we were testing for the release. If we do not get
this out to the users, as I have been screaming for months, we are
never going to get this release done. Waiting another week is nuts.
What tests do you personally intend to run on this build in that time?
Since we have not released this, what users are testing this?
We need to get the new tarball out ASAP and ideally signed and
released. Obviously that depends on what we find.
-1 on waiting.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Julian Foad <ju...@btopenworld.com>.
Hyrum K. Wright wrote:
> C. Michael Pilato wrote:
>> Paul Burba wrote:
>> Julian Foad wrote:
>>>> I would suggest letting people continue testing RC1 for a while
[...]
>>>
>>> Hi Julian,
>>>
>>> It's probably obvious that I disagree with waiting, since I suggested
>>> RC2, but I'll come right out and say it: I disagree :-)
>>
>> Yeah, same here. It's pretty obvious that RC1 isn't likely to get
[...]
Sorry, I somehow got an impression that the bug reports were still coming in
steadily, but it seems I was wrong. You folks are of course right not to wait
if there's nothing in particular to wait for.
>> +1 on an RC2, shooting for, perhaps, Monday morning, first thing?
>
> I'd actually like to roll RC2 tomorrow morning some time (or even
> tonight if everything gets nominated and merged that needs it). I don't
> think that it is unreasonable to clear out STATUS before then.
[...]
> -Hyrum
Good, +1 then!
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
C. Michael Pilato wrote:
> Paul Burba wrote:
>>> I would suggest letting people continue testing RC1 for a while
>>> until the
>>> rate of finding serious bugs falls off, unless testing is being
>>> impeded by
>>> these bugs. If we just release RC2 right now, we would statistically
>>> expect
>>> serious bugs to be found in it at a similar rate, so what would be the
>>> point?
>>>
>>> (A while might be 1 or 2 weeks?)
>>
>> Hi Julian,
>>
>> It's probably obvious that I disagree with waiting, since I suggested
>> RC2, but I'll come right out and say it: I disagree :-)
>
> Yeah, same here. It's pretty obvious that RC1 isn't likely to get much
> more testing -- these things happen in bursts, and (as Paul noted
> elsewhere in his mail) RC1 isn't even publicly released yet. Most of
> the developer testing done to sign a release involves strict use of the
> test suite. This burst of additional issues at all was the result of
> adhoc testing. So, if the goal is ride the statistical wave of
> find-rates today, we need to actually get the code into more people's
> hands. And to do that requires actually releasing something. It ain't
> RC1 though, because we now know without a doubt that that snapshot is
> *not* a potential candidate for release.
>
> +1 on an RC2, shooting for, perhaps, Monday morning, first thing?
I'd actually like to roll RC2 tomorrow morning some time (or even
tonight if everything gets nominated and merged that needs it). I don't
think that it is unreasonable to clear out STATUS before then.
Aside from Dave's back-compat changes mentioned elsethread, are there
any other pending issues which need to be resolved before RC2?
-Hyrum
Re: 1.5.0-rc1 up for signing/testing
Posted by David Glasser <gl...@davidglasser.net>.
On Thu, Apr 10, 2008 at 7:09 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Thu, Apr 10, 2008 at 10:02 AM, C. Michael Pilato <cm...@collab.net> wrote:
> > Yeah, same here. It's pretty obvious that RC1 isn't likely to get much
> > more testing -- these things happen in bursts, and (as Paul noted elsewhere
> > in his mail) RC1 isn't even publicly released yet. Most of the developer
> > testing done to sign a release involves strict use of the test suite. This
> > burst of additional issues at all was the result of adhoc testing. So, if
> > the goal is ride the statistical wave of find-rates today, we need to
> > actually get the code into more people's hands. And to do that requires
> > actually releasing something. It ain't RC1 though, because we now know
> > without a doubt that that snapshot is *not* a potential candidate for
> > release.
> >
> > +1 on an RC2, shooting for, perhaps, Monday morning, first thing?
>
> If you mean have it signed and released to the public for then, +1.
>
> Otherwise, is there a specific reason to wait until then? Perhaps
> there is some fix activity going on that I am just not aware of.
I would like to nominate (probably requiring a backport branch, once I
get into work) the back-compat tests I fixed yesterday, so that people
can use them as a part of their testing. (And the stuff in STATUS
now, of course.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Thu, Apr 10, 2008 at 10:02 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> Yeah, same here. It's pretty obvious that RC1 isn't likely to get much
>> more testing -- these things happen in bursts, and (as Paul noted elsewhere
>> in his mail) RC1 isn't even publicly released yet. Most of the developer
>> testing done to sign a release involves strict use of the test suite. This
>> burst of additional issues at all was the result of adhoc testing. So, if
>> the goal is ride the statistical wave of find-rates today, we need to
>> actually get the code into more people's hands. And to do that requires
>> actually releasing something. It ain't RC1 though, because we now know
>> without a doubt that that snapshot is *not* a potential candidate for
>> release.
>>
>> +1 on an RC2, shooting for, perhaps, Monday morning, first thing?
>
> If you mean have it signed and released to the public for then, +1.
>
> Otherwise, is there a specific reason to wait until then? Perhaps
> there is some fix activity going on that I am just not aware of.
Oh, I would have said "Friday at noon" but for the distinct feeling that,
given the options of the weekend being used either finding and fixing bugs
or testing and signing tarballs, most folks would probably rather spend
their time finding and fixing bugs, and we'd all be signing tarballs on
Monday anyway. :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Apr 10, 2008 at 10:02 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Yeah, same here. It's pretty obvious that RC1 isn't likely to get much
> more testing -- these things happen in bursts, and (as Paul noted elsewhere
> in his mail) RC1 isn't even publicly released yet. Most of the developer
> testing done to sign a release involves strict use of the test suite. This
> burst of additional issues at all was the result of adhoc testing. So, if
> the goal is ride the statistical wave of find-rates today, we need to
> actually get the code into more people's hands. And to do that requires
> actually releasing something. It ain't RC1 though, because we now know
> without a doubt that that snapshot is *not* a potential candidate for
> release.
>
> +1 on an RC2, shooting for, perhaps, Monday morning, first thing?
If you mean have it signed and released to the public for then, +1.
Otherwise, is there a specific reason to wait until then? Perhaps
there is some fix activity going on that I am just not aware of.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Paul Burba wrote:
>> I would suggest letting people continue testing RC1 for a while until the
>> rate of finding serious bugs falls off, unless testing is being impeded by
>> these bugs. If we just release RC2 right now, we would statistically expect
>> serious bugs to be found in it at a similar rate, so what would be the
>> point?
>>
>> (A while might be 1 or 2 weeks?)
>
> Hi Julian,
>
> It's probably obvious that I disagree with waiting, since I suggested
> RC2, but I'll come right out and say it: I disagree :-)
Yeah, same here. It's pretty obvious that RC1 isn't likely to get much more
testing -- these things happen in bursts, and (as Paul noted elsewhere in
his mail) RC1 isn't even publicly released yet. Most of the developer
testing done to sign a release involves strict use of the test suite. This
burst of additional issues at all was the result of adhoc testing. So, if
the goal is ride the statistical wave of find-rates today, we need to
actually get the code into more people's hands. And to do that requires
actually releasing something. It ain't RC1 though, because we now know
without a doubt that that snapshot is *not* a potential candidate for release.
+1 on an RC2, shooting for, perhaps, Monday morning, first thing?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.0-rc1 up for signing/testing
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Apr 10, 2008 at 9:17 AM, Julian Foad <ju...@btopenworld.com> wrote:
> Paul Burba wrote:
>
> > Given that we have found several serious problems with RC1, in
> > particular these items in STATUS:
> >
> [...]
>
>
> > Shouldn't we push to quickly backport those fixes and roll RC2?
> >
>
> I would suggest letting people continue testing RC1 for a while until the
> rate of finding serious bugs falls off, unless testing is being impeded by
> these bugs. If we just release RC2 right now, we would statistically expect
> serious bugs to be found in it at a similar rate, so what would be the
> point?
>
> (A while might be 1 or 2 weeks?)
Hi Julian,
It's probably obvious that I disagree with waiting, since I suggested
RC2, but I'll come right out and say it: I disagree :-)
Keep in mind that RC1 *never* got enough votes to be made "officially"
public. I'm going on record as -1 for releasing it too, it's simply
broken.
If RC1 had been approved and released for wider testing then I might
agree with you. But it never got to that point.
And not that procedure is everything, but I just looked at HACKING
again and I don't see how quickly going to RC2 in any way violates our
own policies either.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Julian Foad <ju...@btopenworld.com>.
Paul Burba wrote:
> Given that we have found several serious problems with RC1, in
> particular these items in STATUS:
[...]
> Shouldn't we push to quickly backport those fixes and roll RC2?
I would suggest letting people continue testing RC1 for a while until the rate
of finding serious bugs falls off, unless testing is being impeded by these
bugs. If we just release RC2 right now, we would statistically expect serious
bugs to be found in it at a similar rate, so what would be the point?
(A while might be 1 or 2 weeks?)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>
> Hi All,
>
> Given that we have found several serious problems with RC1, in
> particular these items in STATUS:
>
> * r30455, r30460
> Use 1:PEG_REV instead of 1:HEAD as the default operative revision
> range when a peg revision is supplied to a single-URL merge command.
> Votes:
> +1: cmpilato
>
> * r30448, r30464
> r30448: XFail Testcase to showcase the bug.
> r30464: Fix reopened issue #2821. Fixes a bug where repeat merges can
> easily occur when merging into subtrees with differing mergeinfo from the
> merge target.
> See http://subversion.tigris.org/issues/show_bug.cgi?id=2821#desc22
> Votes:
> +1: pburba(r30464)
> +1: kameshj(r30448)
>
> * r30467
> Fix a bug which can corrupt mergeinfo when filtering self-referential
> mergeinfo.
> See http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=137036.
> Votes:
> +1: pburba
>
> * r30440, r30453, r30462, r30463
> Fix regression. Svnsync doesn't support 1.4 svnserve servers.
> Votes:
> +1: lgo
>
> Shouldn't we push to quickly backport those fixes and roll RC2?
>
+1.
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH/gzu3WHvyO0YTCwRAuYlAJ0cWSM9oLKUHGi068shr+JqdvPmfQCdEhDS
OQmvqopfCkoQD3YoY2WXEO8=
=Tieb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark Phippard wrote:
> On Thu, Apr 10, 2008 at 8:47 AM, Paul Burba <pt...@gmail.com> wrote:
>
>> Given that we have found several serious problems with RC1, in
>> particular these items in STATUS:
>>
>> * r30455, r30460
>> Use 1:PEG_REV instead of 1:HEAD as the default operative revision
>> range when a peg revision is supplied to a single-URL merge command.
>> Votes:
>> +1: cmpilato
>>
>> * r30448, r30464
>> r30448: XFail Testcase to showcase the bug.
>> r30464: Fix reopened issue #2821. Fixes a bug where repeat merges can
>> easily occur when merging into subtrees with differing mergeinfo from the
>> merge target.
>> See http://subversion.tigris.org/issues/show_bug.cgi?id=2821#desc22
>> Votes:
>> +1: pburba(r30464)
>> +1: kameshj(r30448)
>>
>> * r30467
>> Fix a bug which can corrupt mergeinfo when filtering self-referential
>> mergeinfo.
>> See http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=137036.
>> Votes:
>> +1: pburba
>>
>> * r30440, r30453, r30462, r30463
>> Fix regression. Svnsync doesn't support 1.4 svnserve servers.
>> Votes:
>> +1: lgo
>>
>> Shouldn't we push to quickly backport those fixes and roll RC2?
>
> +1
>
> There were also the problems with the Ruby bindings (looks like they
> have already been merged). And there was the failing update_test
> number 41 when ra_serf was used. Was a fix ever made for that
> problem? Personally, I would roll the release anyway, but just
> wondering as I did not see it in STATUS.
>
update_tests-41 is not fixed over ra_serf, will update the list once I
am done with it.
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH/g7/3WHvyO0YTCwRAlLkAKC0/al9k+xe/IgssfzjY2W9oFbNvQCeMq42
4cc3mnga6mmFWzq/mYhv+yw=
=hK6k
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Apr 10, 2008 at 8:47 AM, Paul Burba <pt...@gmail.com> wrote:
> Given that we have found several serious problems with RC1, in
> particular these items in STATUS:
>
> * r30455, r30460
> Use 1:PEG_REV instead of 1:HEAD as the default operative revision
> range when a peg revision is supplied to a single-URL merge command.
> Votes:
> +1: cmpilato
>
> * r30448, r30464
> r30448: XFail Testcase to showcase the bug.
> r30464: Fix reopened issue #2821. Fixes a bug where repeat merges can
> easily occur when merging into subtrees with differing mergeinfo from the
> merge target.
> See http://subversion.tigris.org/issues/show_bug.cgi?id=2821#desc22
> Votes:
> +1: pburba(r30464)
> +1: kameshj(r30448)
>
> * r30467
> Fix a bug which can corrupt mergeinfo when filtering self-referential
> mergeinfo.
> See http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=137036.
> Votes:
> +1: pburba
>
> * r30440, r30453, r30462, r30463
> Fix regression. Svnsync doesn't support 1.4 svnserve servers.
> Votes:
> +1: lgo
>
> Shouldn't we push to quickly backport those fixes and roll RC2?
+1
There were also the problems with the Ruby bindings (looks like they
have already been merged). And there was the failing update_test
number 41 when ra_serf was used. Was a fix ever made for that
problem? Personally, I would roll the release anyway, but just
wondering as I did not see it in STATUS.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Apr 7, 2008 at 7:16 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Good afternoon,
>
> I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> signing. The magic revision is r30419.
>
> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/
>
> As usual, signatures from full committers back to me, and enthusiastic
> tester feedback is welcome. At this point, this candidate is not yet
> blessed for wide release, so please don't make it available to people
> not interested in test-driving the new release.
>
> Distro package maintainers, please to NOT include any pre-release
> builds, even blessed, into operating system distros. The reasons for
> not doing so were very eloquently outlined by Karl in a mail, which is
> summarized at the above address.
>
> The quick version is: we don't guarantee compatibility between the
> pre-releases and the final release, so if people install the release
> canditate, all their repositories and working copies might break
> unrepairably when they upgrade to 1.5.0 proper. We don't want that kind
> of bad publicity, and neither do you.
>
> -Hyrum
Hi All,
Given that we have found several serious problems with RC1, in
particular these items in STATUS:
* r30455, r30460
Use 1:PEG_REV instead of 1:HEAD as the default operative revision
range when a peg revision is supplied to a single-URL merge command.
Votes:
+1: cmpilato
* r30448, r30464
r30448: XFail Testcase to showcase the bug.
r30464: Fix reopened issue #2821. Fixes a bug where repeat merges can
easily occur when merging into subtrees with differing mergeinfo from the
merge target.
See http://subversion.tigris.org/issues/show_bug.cgi?id=2821#desc22
Votes:
+1: pburba(r30464)
+1: kameshj(r30448)
* r30467
Fix a bug which can corrupt mergeinfo when filtering self-referential
mergeinfo.
See http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=137036.
Votes:
+1: pburba
* r30440, r30453, r30462, r30463
Fix regression. Svnsync doesn't support 1.4 svnserve servers.
Votes:
+1: lgo
Shouldn't we push to quickly backport those fixes and roll RC2?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Kouhei Sutou" <ko...@cozmixng.org> writes:
> > > Ah, sorry. We need to support
> > > svn_client_mergeinfo_log_merged() instead of
> > > svn_client_mergeinfo_get_merged().
> >
> > This doesn't seem to have happened on trunk; can you fix this and
> > nominate for backport?
>
> Done.
Thanks! Looks good to me; tomorrow I'll figure out how to get a
swig this stuff works with installed so I can test and vote...
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi,
2008/4/9 Eric Gillespie <ep...@pretzelnet.org>:
> "Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
>
> > I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> > signing. The magic revision is r30419.
> >
> > http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/
>
> -0 for release: ruby bindings are broken. See
> Message-Id: <20...@cozmixng.org>
> Subject: Re: Ruby Bindings test failures
>
> Kouhei Sutou <ko...@cozmixng.org> writes:
>
> > Hi,
> >
> > In <20...@cozmixng.org>
> > "Re: Ruby Bindings test failures" on Sun, 06 Apr 2008 10:59:57 +0900 (JST),
> > Kouhei Sutou <ko...@cozmixng.org> wrote:
> >
> > > In <47...@mail.utexas.edu>
> > > "Ruby Bindings test failures" on Sat, 05 Apr 2008 17:48:33 -0500,
>
> > > "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
> > >
> > > > Kou, et. al.,
> > > > I got the following ruby bindings test errors on the 1.5.x branch today:
> > > >
> > > > 1) Error:
> > > > test_merge(SvnClientTest):
> > > > NoMethodError: undefined method `mergeinfo_get_merged' for
> > > > Svn::Client:Module
> > > > /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/svn/client.rb:5
> > 95:in
> > > > `mergeinfo'
> > > > /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/test/test_clien
> > t.rb:873:in
> > > > `test_merge'
> > > >
> > > > 2) Error:
> > > > test_merge_peg(SvnClientTest):
> > > > NoMethodError: undefined method `mergeinfo_get_merged' for
> > > > Svn::Client:Module
> > > > /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/svn/client.rb:5
> > 95:in
> > > > `mergeinfo'
> > > > /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/test/test_clien
> > t.rb:933:in
> > > > `test_merge_peg'
> > > >
> > > > 211 tests, 1407 assertions, 0 failures, 2 errors
> > > >
> > > > I think it has to do with the API changes from the recently merged
> > > > mergeinfo improvements stuff (merged to the branch in r30349). I don't
> > > > think it is enough to hold RC1, but we may want to take care of this
> > > > before GA.
> > >
> > > I think r29420 is the fix of that. But it can't be merged
> > > into 1.5.x branch. We may need to create a branch to merge
> > > it.
> >
> > Ah, sorry. We need to support
> > svn_client_mergeinfo_log_merged() instead of
> > svn_client_mergeinfo_get_merged().
>
> This doesn't seem to have happened on trunk; can you fix this and
> nominate for backport?
Done.
Thanks,
--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Are the Ruby bindings themselves actually broken, or is it just that their
tests are out of date?
Eric Gillespie wrote:
> "Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
>
>> I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
>> signing. The magic revision is r30419.
>>
>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/
>
> -0 for release: ruby bindings are broken. See
> Message-Id: <20...@cozmixng.org>
> Subject: Re: Ruby Bindings test failures
>
> Kouhei Sutou <ko...@cozmixng.org> writes:
>
>> Hi,
>>
>> In <20...@cozmixng.org>
>> "Re: Ruby Bindings test failures" on Sun, 06 Apr 2008 10:59:57 +0900 (JST),
>> Kouhei Sutou <ko...@cozmixng.org> wrote:
>>
>>> In <47...@mail.utexas.edu>
>>> "Ruby Bindings test failures" on Sat, 05 Apr 2008 17:48:33 -0500,
>>> "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
>>>
>>>> Kou, et. al.,
>>>> I got the following ruby bindings test errors on the 1.5.x branch today:
>>>>
>>>> 1) Error:
>>>> test_merge(SvnClientTest):
>>>> NoMethodError: undefined method `mergeinfo_get_merged' for
>>>> Svn::Client:Module
>>>> /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/svn/client.rb:5
>> 95:in
>>>> `mergeinfo'
>>>> /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/test/test_clien
>> t.rb:873:in
>>>> `test_merge'
>>>>
>>>> 2) Error:
>>>> test_merge_peg(SvnClientTest):
>>>> NoMethodError: undefined method `mergeinfo_get_merged' for
>>>> Svn::Client:Module
>>>> /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/svn/client.rb:5
>> 95:in
>>>> `mergeinfo'
>>>> /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/test/test_clien
>> t.rb:933:in
>>>> `test_merge_peg'
>>>>
>>>> 211 tests, 1407 assertions, 0 failures, 2 errors
>>>>
>>>> I think it has to do with the API changes from the recently merged
>>>> mergeinfo improvements stuff (merged to the branch in r30349). I don't
>>>> think it is enough to hold RC1, but we may want to take care of this
>>>> before GA.
>>> I think r29420 is the fix of that. But it can't be merged
>>> into 1.5.x branch. We may need to create a branch to merge
>>> it.
>> Ah, sorry. We need to support
>> svn_client_mergeinfo_log_merged() instead of
>> svn_client_mergeinfo_get_merged().
>
> This doesn't seem to have happened on trunk; can you fix this and
> nominate for backport?
>
> --
> Eric Gillespie <*> epg@pretzelnet.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.0-rc1 up for signing/testing
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
> I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> signing. The magic revision is r30419.
>
> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/
-0 for release: ruby bindings are broken. See
Message-Id: <20...@cozmixng.org>
Subject: Re: Ruby Bindings test failures
Kouhei Sutou <ko...@cozmixng.org> writes:
> Hi,
>
> In <20...@cozmixng.org>
> "Re: Ruby Bindings test failures" on Sun, 06 Apr 2008 10:59:57 +0900 (JST),
> Kouhei Sutou <ko...@cozmixng.org> wrote:
>
> > In <47...@mail.utexas.edu>
> > "Ruby Bindings test failures" on Sat, 05 Apr 2008 17:48:33 -0500,
> > "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
> >
> > > Kou, et. al.,
> > > I got the following ruby bindings test errors on the 1.5.x branch today:
> > >
> > > 1) Error:
> > > test_merge(SvnClientTest):
> > > NoMethodError: undefined method `mergeinfo_get_merged' for
> > > Svn::Client:Module
> > > /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/svn/client.rb:5
> 95:in
> > > `mergeinfo'
> > > /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/test/test_clien
> t.rb:873:in
> > > `test_merge'
> > >
> > > 2) Error:
> > > test_merge_peg(SvnClientTest):
> > > NoMethodError: undefined method `mergeinfo_get_merged' for
> > > Svn::Client:Module
> > > /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/svn/client.rb:5
> 95:in
> > > `mergeinfo'
> > > /home/hwright/dev/svn-1.5.x/subversion/bindings/swig/ruby/test/test_clien
> t.rb:933:in
> > > `test_merge_peg'
> > >
> > > 211 tests, 1407 assertions, 0 failures, 2 errors
> > >
> > > I think it has to do with the API changes from the recently merged
> > > mergeinfo improvements stuff (merged to the branch in r30349). I don't
> > > think it is enough to hold RC1, but we may want to take care of this
> > > before GA.
> >
> > I think r29420 is the fix of that. But it can't be merged
> > into 1.5.x branch. We may need to create a branch to merge
> > it.
>
> Ah, sorry. We need to support
> svn_client_mergeinfo_log_merged() instead of
> svn_client_mergeinfo_get_merged().
This doesn't seem to have happened on trunk; can you fix this and
nominate for backport?
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hyrum K. Wright wrote:
> Kamesh Jayachandran wrote:
>> Hi All,
>>
>> I tested
>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-1.5.0-rc1.tar.bz2
>>
>> and
>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-deps-1.5.0-rc1.tar.bz2
>>
>> in the following scenarios,
>>
>> make check, svnserveautocheck over bdb and fsfs - No issues found.
>> make davautocheck (neon default) over bdb and fsfs - No issues found.
>> make davautocheck HTTP_LIBRARY=serf over bdb and fsfs - update_tests.py
>> 41 fails.
>>
>> As I mentioned in other email, VPATH build is failing which is tracked
>> via http://code.google.com/p/serf/issues/detail?id=32
>
> I'm assuming this was on a *nix platform. Is that correct?
>
> -Hyrum
>
Yes it is for *nix platform.
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH/F2c3WHvyO0YTCwRAm/sAKCc5YULQ2JMzwUcM8wLb1lm72ZZtgCfYAsR
ETK+9/zQ7lCSHF35VUZwyQw=
=A8Ur
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Kamesh Jayachandran wrote:
> Hi All,
>
> I tested
> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-1.5.0-rc1.tar.bz2
> and
> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-deps-1.5.0-rc1.tar.bz2
> in the following scenarios,
>
> make check, svnserveautocheck over bdb and fsfs - No issues found.
> make davautocheck (neon default) over bdb and fsfs - No issues found.
> make davautocheck HTTP_LIBRARY=serf over bdb and fsfs - update_tests.py
> 41 fails.
>
> As I mentioned in other email, VPATH build is failing which is tracked
> via http://code.google.com/p/serf/issues/detail?id=32
I'm assuming this was on a *nix platform. Is that correct?
-Hyrum
Re: 1.5.0-rc1 up for signing/testing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Tue, Apr 8, 2008 at 9:53 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> Hyrum K. Wright wrote:
>>
>>> C. Michael Pilato wrote:
>
>>> Is serf still considered "experimental"? If so, should we 1) be testing
>> it, and 2) block on test failures in ra_serf?
>> Yes, 1) yes, and 2) perhaps not, but there's not much point in being
>> experimental if all the experiments fail. :-)
>
> I thought he said one test, update_tests.py number 41 failed. Not 41
> tests failed.
Ohoh! I totally misread that. Sorry, Kamesh.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.0-rc1 up for signing/testing
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark Phippard wrote:
> On Tue, Apr 8, 2008 at 9:53 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> Hyrum K. Wright wrote:
>>
>>> C. Michael Pilato wrote:
>
>>> Is serf still considered "experimental"? If so, should we 1) be testing
>> it, and 2) block on test failures in ra_serf?
>> Yes, 1) yes, and 2) perhaps not, but there's not much point in being
>> experimental if all the experiments fail. :-)
>
> I thought he said one test, update_tests.py number 41 failed. Not 41
> tests failed.
>
>
Yes *only* one test 'update_tests-41' failed over ra_serf(on both FS layer)
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH+3pn3WHvyO0YTCwRAt/dAJwMGgMf2nJOjEr6iWoYgl/JpxvlvwCfVUag
sh5fQQ4JTqj9LIomHQ0rFZA=
=CnbA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Apr 8, 2008 at 9:53 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Hyrum K. Wright wrote:
>
> > C. Michael Pilato wrote:
> > Is serf still considered "experimental"? If so, should we 1) be testing
> it, and 2) block on test failures in ra_serf?
> >
>
> Yes, 1) yes, and 2) perhaps not, but there's not much point in being
> experimental if all the experiments fail. :-)
I thought he said one test, update_tests.py number 41 failed. Not 41
tests failed.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Hyrum K. Wright wrote:
> C. Michael Pilato wrote:
>> Kamesh Jayachandran wrote:
>>> Hi All,
>>>
>>> I tested
>>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-1.5.0-rc1.tar.bz2
>>>
>>> and
>>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-deps-1.5.0-rc1.tar.bz2
>>>
>>> in the following scenarios,
>>>
>>> make check, svnserveautocheck over bdb and fsfs - No issues found.
>>> make davautocheck (neon default) over bdb and fsfs - No issues found.
>>> make davautocheck HTTP_LIBRARY=serf over bdb and fsfs - update_tests.py
>>> 41 fails.
>>
>> Kamesh, your signature is your signature, of course, but does it not
>> bother you that 41 update tests are failing?
>
> Is serf still considered "experimental"? If so, should we 1) be testing
> it, and 2) block on test failures in ra_serf?
Yes, 1) yes, and 2) perhaps not, but there's not much point in being
experimental if all the experiments fail. :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.0-rc1 up for signing/testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
C. Michael Pilato wrote:
> Kamesh Jayachandran wrote:
>> Hi All,
>>
>> I tested
>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-1.5.0-rc1.tar.bz2
>>
>> and
>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-deps-1.5.0-rc1.tar.bz2
>>
>> in the following scenarios,
>>
>> make check, svnserveautocheck over bdb and fsfs - No issues found.
>> make davautocheck (neon default) over bdb and fsfs - No issues found.
>> make davautocheck HTTP_LIBRARY=serf over bdb and fsfs - update_tests.py
>> 41 fails.
>
> Kamesh, your signature is your signature, of course, but does it not
> bother you that 41 update tests are failing?
Is serf still considered "experimental"? If so, should we 1) be testing
it, and 2) block on test failures in ra_serf?
This isn't an argument for either, I just don't remember if we've
answered the question before.
-Hyrum
Re: 1.5.0-rc1 up for signing/testing
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
C. Michael Pilato wrote:
> Kamesh Jayachandran wrote:
>> Hi All,
>>
>> I tested
>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-1.5.0-rc1.tar.bz2
>>
>> and
>> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-deps-1.5.0-rc1.tar.bz2
>>
>> in the following scenarios,
>>
>> make check, svnserveautocheck over bdb and fsfs - No issues found.
>> make davautocheck (neon default) over bdb and fsfs - No issues found.
>> make davautocheck HTTP_LIBRARY=serf over bdb and fsfs - update_tests.py
>> 41 fails.
>
> Kamesh, your signature is your signature, of course, but does it not
> bother you that 41 update tests are failing?
>
I am looking at it....
With regards
Kamesh Jayachandran
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH+3n63WHvyO0YTCwRAkzdAJ4s0TKdhYwgp59ZAeAb2QED2WCrtwCfeqDu
+ZhualYImA12Prh50agUHeo=
=mFcI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Kamesh Jayachandran wrote:
> Hi All,
>
> I tested
> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-1.5.0-rc1.tar.bz2
> and
> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-deps-1.5.0-rc1.tar.bz2
> in the following scenarios,
>
> make check, svnserveautocheck over bdb and fsfs - No issues found.
> make davautocheck (neon default) over bdb and fsfs - No issues found.
> make davautocheck HTTP_LIBRARY=serf over bdb and fsfs - update_tests.py
> 41 fails.
Kamesh, your signature is your signature, of course, but does it not bother
you that 41 update tests are failing?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.0-rc1 up for signing/testing
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
I tested
http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-1.5.0-rc1.tar.bz2
and
http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/buda-oak/subversion-deps-1.5.0-rc1.tar.bz2
in the following scenarios,
make check, svnserveautocheck over bdb and fsfs - No issues found.
make davautocheck (neon default) over bdb and fsfs - No issues found.
make davautocheck HTTP_LIBRARY=serf over bdb and fsfs - update_tests.py
41 fails.
As I mentioned in other email, VPATH build is failing which is tracked
via http://code.google.com/p/serf/issues/detail?id=32
My signature is
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQBH+3Qs3WHvyO0YTCwRAjRRAJ9zLD27/ZZiCzxRdK+ftOTYgl5MKgCfWBHm
ygITStra3UaAsFmpVJPE83I=
=8ka+
- -----END PGP SIGNATURE-----
With regards
Kamesh Jayachandran
Hyrum K. Wright wrote:
> Good afternoon,
>
> I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> signing. The magic revision is r30419.
>
> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/
>
> As usual, signatures from full committers back to me, and enthusiastic
> tester feedback is welcome. At this point, this candidate is not yet
> blessed for wide release, so please don't make it available to people
> not interested in test-driving the new release.
>
> Distro package maintainers, please to NOT include any pre-release
> builds, even blessed, into operating system distros. The reasons for
> not doing so were very eloquently outlined by Karl in a mail, which is
> summarized at the above address.
>
> The quick version is: we don't guarantee compatibility between the
> pre-releases and the final release, so if people install the release
> canditate, all their repositories and working copies might break
> unrepairably when they upgrade to 1.5.0 proper. We don't want that kind
> of bad publicity, and neither do you.
>
> -Hyrum
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH+3Rr3WHvyO0YTCwRAqCjAKCvFuN2McIvg1/Ote7u8cfu7iCgrwCfWqyw
6vCqU2pPONjmGFcWfaamg8I=
=BakS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Apr 8, 2008 at 9:11 AM, Troy Bull <tb...@gmail.com> wrote:
> On Mon, Apr 7, 2008 at 6:16 PM, Hyrum K. Wright
>
> <hy...@mail.utexas.edu> wrote:
>
> > Good afternoon,
> >
> > I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> > signing. The magic revision is r30419.
> >
> This is great news. I will build for solaris but does anyone know if
> there are windows binaries of this anywhere?
Hopefully not before we have even released it. I believe in the past
we have posted Windows binaries for release candidates, but the
Windows binaries have always been a volunteer effort so there are no
guarantees.
CollabNet will be providing binaries as it has for the other beta and
alpha releases.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Troy Bull <tb...@gmail.com>.
On Mon, Apr 7, 2008 at 6:16 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Good afternoon,
>
> I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> signing. The magic revision is r30419.
>
This is great news. I will build for solaris but does anyone know if
there are windows binaries of this anywhere?
Thanks
Troy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Kamesh Jayachandran <ka...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi All,
'VPATH'(../configure builds) build fails while building serf which is
tracked via http://code.google.com/p/serf/issues/detail?id=32
Normal './configure' builds work fine.
With regards
Kamesh Jayachandran
Hyrum K. Wright wrote:
> Good afternoon,
>
> I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> signing. The magic revision is r30419.
>
> http://orac.ece.utexas.edu/pub/svn/1.5.0-rc1/
>
> As usual, signatures from full committers back to me, and enthusiastic
> tester feedback is welcome. At this point, this candidate is not yet
> blessed for wide release, so please don't make it available to people
> not interested in test-driving the new release.
>
> Distro package maintainers, please to NOT include any pre-release
> builds, even blessed, into operating system distros. The reasons for
> not doing so were very eloquently outlined by Karl in a mail, which is
> summarized at the above address.
>
> The quick version is: we don't guarantee compatibility between the
> pre-releases and the final release, so if people install the release
> canditate, all their repositories and working copies might break
> unrepairably when they upgrade to 1.5.0 proper. We don't want that kind
> of bad publicity, and neither do you.
>
> -Hyrum
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH+yGx3WHvyO0YTCwRAg49AJwKC1BNDoRgeR2R8YztLWVia0B0ogCfaRxz
zr64ppEqzKDfQr+uZoR46M4=
=OYrR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Tue, Apr 8, 2008 at 9:42 AM, Peter Samuelson <pe...@p12n.org> wrote:
>> [Hyrum K. Wright]
>>
>>> I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
>> > signing. The magic revision is r30419.
>>
>> Please revert to apr 0.9 and apr-util 0.9 in the deps tarball. See
>> Kamesh's note at http://svn.haxx.se/dev/archive-2008-03/0475.shtml .
>
> We talked about this last year and decided we were going to update to
> the latest APR. I do not see any reason to change that decision. No
> matter what we choose there will always be scenarios where people will
> have a problem. I would assume that regardless of what we include in
> our deps tarballs, distributions are going to choose the right
> dependencies for their distro. We ought to include the "best"
> versions of dependencies in our tarball.
+1.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.0-rc1 up for signing/testing
Posted by David Glasser <gl...@davidglasser.net>.
On Tue, Apr 8, 2008 at 10:07 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> Karl Fogel wrote:
>
> > "Ben Collins-Sussman" <su...@red-bean.com> writes:
> >
> > > Hold on, I think Mark and Peter are both correct.
> > >
> > > Mark is right in that we've made a policy change: we now distribute a
> > > deps tarball only for *convenience*, so that people who really want to
> > > bother to build subversion (and it's billion of dependencies) have a
> > > lower barrier to entry. Mark is right that 99.9% of all users will be
> > > using binary distributions anyway, and the 0.1% of people who build
> > > Subversion will probably be distro maintainers and understand the
> > > compatibility issues around svn's dependencies.
> > >
> > > However, Peter is also correct in that we've not changed our docs or
> > > behaviors to reflect this new policy. Our INSTALL doc still talks
> > > about the deps tarball as if it were some official thing that
> > > guarantees our ABI compatibility promise, and our release process
> > > still involves signing deps tarballs, as if they were sacred. We need
> > > to change these things to match the new reality, and do a better job
> > > of advertising the new policy.
> > >
> > > Rather than fighting about this, here's 3 simple action items:
> > >
> > > 1. Fix the INSTALL docs
> > > 2. Stop signing deps tarballs
> > > 3. Put clear docs surrounding the deps-download that make it clear
> > > that the deps are for *convenience* only... and perhaps include a link
> > > to some doc explaining the APR ABI issue.
> > >
> >
> > *Smooooooch*.
> >
> > (This must be why they pay Ben the big bucks.)
> >
> > I've attempted step (1) in r30436, but welcome further tweaks of course.
> > Step (2) is something we all do, and I'll try step (3) later tonight if
> > no one beats me to it.
> >
>
> Actually, the deps tarballs are already signed much less frequently than
> the source tarballs. (2) wouldn't be a very large deviation from current
> behavior.
If we're still officially publishing deps tarballs, we really ought to
at least have one non-RM signature to guard against publishing
something entirely broken.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Karl Fogel wrote:
> "Ben Collins-Sussman" <su...@red-bean.com> writes:
>> Hold on, I think Mark and Peter are both correct.
>>
>> Mark is right in that we've made a policy change: we now distribute a
>> deps tarball only for *convenience*, so that people who really want to
>> bother to build subversion (and it's billion of dependencies) have a
>> lower barrier to entry. Mark is right that 99.9% of all users will be
>> using binary distributions anyway, and the 0.1% of people who build
>> Subversion will probably be distro maintainers and understand the
>> compatibility issues around svn's dependencies.
>>
>> However, Peter is also correct in that we've not changed our docs or
>> behaviors to reflect this new policy. Our INSTALL doc still talks
>> about the deps tarball as if it were some official thing that
>> guarantees our ABI compatibility promise, and our release process
>> still involves signing deps tarballs, as if they were sacred. We need
>> to change these things to match the new reality, and do a better job
>> of advertising the new policy.
>>
>> Rather than fighting about this, here's 3 simple action items:
>>
>> 1. Fix the INSTALL docs
>> 2. Stop signing deps tarballs
>> 3. Put clear docs surrounding the deps-download that make it clear
>> that the deps are for *convenience* only... and perhaps include a link
>> to some doc explaining the APR ABI issue.
>
> *Smooooooch*.
>
> (This must be why they pay Ben the big bucks.)
>
> I've attempted step (1) in r30436, but welcome further tweaks of course.
> Step (2) is something we all do, and I'll try step (3) later tonight if
> no one beats me to it.
Actually, the deps tarballs are already signed much less frequently than
the source tarballs. (2) wouldn't be a very large deviation from
current behavior.
-Hyrum
Re: 1.5.0-rc1 up for signing/testing
Posted by Karl Fogel <kf...@red-bean.com>.
"Ben Collins-Sussman" <su...@red-bean.com> writes:
> Hold on, I think Mark and Peter are both correct.
>
> Mark is right in that we've made a policy change: we now distribute a
> deps tarball only for *convenience*, so that people who really want to
> bother to build subversion (and it's billion of dependencies) have a
> lower barrier to entry. Mark is right that 99.9% of all users will be
> using binary distributions anyway, and the 0.1% of people who build
> Subversion will probably be distro maintainers and understand the
> compatibility issues around svn's dependencies.
>
> However, Peter is also correct in that we've not changed our docs or
> behaviors to reflect this new policy. Our INSTALL doc still talks
> about the deps tarball as if it were some official thing that
> guarantees our ABI compatibility promise, and our release process
> still involves signing deps tarballs, as if they were sacred. We need
> to change these things to match the new reality, and do a better job
> of advertising the new policy.
>
> Rather than fighting about this, here's 3 simple action items:
>
> 1. Fix the INSTALL docs
> 2. Stop signing deps tarballs
> 3. Put clear docs surrounding the deps-download that make it clear
> that the deps are for *convenience* only... and perhaps include a link
> to some doc explaining the APR ABI issue.
*Smooooooch*.
(This must be why they pay Ben the big bucks.)
I've attempted step (1) in r30436, but welcome further tweaks of course.
Step (2) is something we all do, and I'll try step (3) later tonight if
no one beats me to it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Ben Collins-Sussman <su...@red-bean.com>.
Hold on, I think Mark and Peter are both correct.
Mark is right in that we've made a policy change: we now distribute a
deps tarball only for *convenience*, so that people who really want to
bother to build subversion (and it's billion of dependencies) have a
lower barrier to entry. Mark is right that 99.9% of all users will be
using binary distributions anyway, and the 0.1% of people who build
Subversion will probably be distro maintainers and understand the
compatibility issues around svn's dependencies.
However, Peter is also correct in that we've not changed our docs or
behaviors to reflect this new policy. Our INSTALL doc still talks
about the deps tarball as if it were some official thing that
guarantees our ABI compatibility promise, and our release process
still involves signing deps tarballs, as if they were sacred. We need
to change these things to match the new reality, and do a better job
of advertising the new policy.
Rather than fighting about this, here's 3 simple action items:
1. Fix the INSTALL docs
2. Stop signing deps tarballs
3. Put clear docs surrounding the deps-download that make it clear
that the deps are for *convenience* only... and perhaps include a link
to some doc explaining the APR ABI issue.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Document move to apr 1.2 in INSTALL
Posted by Peter Samuelson <pe...@p12n.org>.
[Peter Samuelson]
> [[[
> * INSTALL: update to document the move to apr 1.2.
>
> Patch by: Peter Samuelson <pe...@p12n.org>
> ]]]
Gah, I just noticed that part of that patch did indeed change the
Windows-specific build instructions. Someone please verify the details
as you're fixing the paragraph I FIXME'd.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Document move to apr 1.2 in INSTALL
Posted by Peter Samuelson <pe...@p12n.org>.
[Mark Phippard]
> So if Red Hat 6 ships with Apache 2.2 and builds Subversion
> accordingly should we be hiring lawyers to block their release
> because they are breaking our compatibility warranty? How far should
> we go with this?
Thanks to your liberal licensing, what other people do is pretty much
not your concern. The -deps tarball isn't someone else's decision,
though, it is an integral part of your own release process. If that
tarball is something you really only recommend in peculiar
circumstances (I'm fine with that, I don't use it myself), I think it's
best to actually say so.
> I thought the dependencies file was a convenience for people to grab
> the dependencies. 99.9% of whom could give a shit about ABI.
How about this patch, then? Note, I don't know anything about Windows
build issues, so I thought I should leave that one paragraph for
somebody else to fill in.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
[[[
* INSTALL: update to document the move to apr 1.2.
Patch by: Peter Samuelson <pe...@p12n.org>
]]]
Index: INSTALL
===================================================================
--- INSTALL (revisione 30118)
+++ INSTALL (copia locale)
@@ -202,26 +202,26 @@
| |
| - if you are already using Subversion with APR 0.9.X, and |
| then upgrade your libapr to 1.X without rebuilding |
- | Subversion, things will break and segfault. |
+ | Subversion and third-party Subversion apps, things will |
+ | break and segfault. |
| |
| - if your Subversion server libraries are linked to one |
| version of APR, but your Apache server is linked to a |
| different version, things will break and segfault. |
| |
- | Subversion 1.0 originally shipped with APR 0.9. Even |
- | though APR 1.X has been available for many years, we |
- | continue to ship APR 0.9 so as not to accidentally break |
- | binary compatibility in Subversion upgrades. |
+ | Subversion 1.0 through 1.4 shipped with APR 0.9; we |
+ | switched to APR 1.2 in Subversion 1.5. Thus if you use our |
+ | "subversion-deps" tarball, an upgrade to Subversion 1.5 is |
+ | not binary compatible. We recommend the "subversion-deps" |
+ | tarball only for new installs; for upgrades, you should use |
+ | the same library versions you used for the previous build, |
+ | unless you are prepared to recompile any third-party |
+ | Subversion applications as well. |
| |
- | However, it's *perfectly* safe to use APR 1.X from the |
- | beginning. In fact, we recommend it. If you're building |
- | Subversion for the first time, there's no compatibility |
- | issue to worry about, so grab the latest version of APR |
- | (rather than the 0.9.X version we distribute.) |
- | |
| If you already have a Subversion installation using APR |
| 0.9.x, it's still possible to move to APR 1.X safely. Just |
- | be sure to recompile Subversion after upgrading APR! |
+ | be sure to recompile Subversion and your third-party |
+ | Subversion applications after upgrading APR! |
|______________________________________________________________|
@@ -785,6 +785,7 @@
for building the client components. Neon is included in the zip file
distribution. (0.25.0+ compiles, but does not properly support all
HTTP auth types.)
+ * FIXME: next paragraph is out of date.
* Apache apr, apr-util, and apr-iconv libraries, version 0.9.12.
Included in both the Subversion dependencies ZIP file and the
Apache 2.058 source zip. If you are building from a Subversion
@@ -804,12 +805,8 @@
* [Optional] Apache 2 source, downloaded from
http://httpd.apache.org/download.cgi, these instructions assume
- version 2.0.58. This is only needed for building the Subversion
- server Apache modules. Note that although Subversion will compile
- against Apache 2.2.3 and APR 1.2.7, there is a bug that causes
- runtime failures with Subversion on Windows. The fix is included in
- APR 1.2.8 and will be bundled in the next HTTP Server release
- (likely to be 2.2.4).
+ version 2.2.8. This is only needed for building the Subversion
+ server Apache modules.
* [Optional] Apache 2 msi install file, also from
http://httpd.apache.org/download.cgi (required for running the
tests). Only needed for testing the server dso modules and if
@@ -983,12 +980,12 @@
Apache and Subversion will be running incompatible versions of apr.
C:>cd src-%DIR%
- C:>python gen-make.py -t dsp --with-httpd=..\httpd-2.0.58
+ C:>python gen-make.py -t dsp --with-httpd=..\httpd-2.2.8
--with-berkeley-db=db4-win32 --with-openssl=..\openssl-0.9.7f
--with-zlib=..\zlib --with-libintl=..\svn-win32-libintl
C:>cd ..
C:>set APACHEDIR=C:\Program Files\Apache Group\Apache2
- C:>msdev httpd-2.0.58\apache.dsw /MAKE "BuildBin - Win32 Release"
+ C:>msdev httpd-2.2.8\apache.dsw /MAKE "BuildBin - Win32 Release"
Subversion
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Apr 8, 2008 at 10:56 AM, Peter Samuelson <pe...@p12n.org> wrote:
>
> [trimming Cc, clearly you're all reading dev]
> [David Glasser]
> > I was always under the impression that the deps tarball was a way of
> > not scaring off people from installing Subversion back when it was a
> > brand new system nobody had ever heard of with a surprising number of
> > dependencies. Now that Subversion is dominant enough that no
> > self-respecting system makes it hard to get svn up and running (and
> > even major consumer operating systems ship with svn by default), the
> > deps tarball seems like a nice gesture, but hardly a source of
> > compatibility worries.
>
> I don't know if users would read your statements about libsvn binary
> compatibility until 2.0 and assume that it doesn't apply if you use the
> deps tarball. (The INSTALL file pretty much says otherwise.) Myself,
> I would have assumed that the deps tarball, which is signed and md5'd
> and everything, was an implicit part of the distribution and the QA
> process (including compatibility testing).
>
> Maybe the solution here is to make it clear that using the deps tarball
> voids your binary compatibility warranty, that warranty only being
> honored if you stick to the same external libraries for each new
> Subversion build. (In practice, I believe this only actually matters
> for apr (and apr-util and serf, which use apr). The other external
> ABIs are shielded from consumers of your API.)
This is quickly becoming pointless but I guess I cannot help myself.
So if Red Hat 6 ships with Apache 2.2 and builds Subversion
accordingly should we be hiring lawyers to block their release because
they are breaking our compatibility warranty? How far should we go
with this?
I thought the dependencies file was a convenience for people to grab
the dependencies. 99.9% of whom could give a shit about ABI. Aren't
we better off giving these people the best set of dependencies and let
the people that rightfully need to care about ABI pick the right set
of dependencies? I am not even clear why if you were using SVN 1.4 and
moved to 1.5 you would even build new versions of the dependencies.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Peter Samuelson <pe...@p12n.org>.
[trimming Cc, clearly you're all reading dev]
[David Glasser]
> I was always under the impression that the deps tarball was a way of
> not scaring off people from installing Subversion back when it was a
> brand new system nobody had ever heard of with a surprising number of
> dependencies. Now that Subversion is dominant enough that no
> self-respecting system makes it hard to get svn up and running (and
> even major consumer operating systems ship with svn by default), the
> deps tarball seems like a nice gesture, but hardly a source of
> compatibility worries.
I don't know if users would read your statements about libsvn binary
compatibility until 2.0 and assume that it doesn't apply if you use the
deps tarball. (The INSTALL file pretty much says otherwise.) Myself,
I would have assumed that the deps tarball, which is signed and md5'd
and everything, was an implicit part of the distribution and the QA
process (including compatibility testing).
Maybe the solution here is to make it clear that using the deps tarball
voids your binary compatibility warranty, that warranty only being
honored if you stick to the same external libraries for each new
Subversion build. (In practice, I believe this only actually matters
for apr (and apr-util and serf, which use apr). The other external
ABIs are shielded from consumers of your API.)
Also, as Kamesh noted, the INSTALL file needs to be updated to remove
the bit about how you're shipping apr 0.9 out of concern for binary
compatibility.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by David Glasser <gl...@davidglasser.net>.
On Tue, Apr 8, 2008 at 7:28 AM, Peter Samuelson <pe...@p12n.org> wrote:
>
> [Mark Phippard]
>
> > We talked about this last year and decided we were going to update to
> > the latest APR. I do not see any reason to change that decision.
>
> That is a fundamental policy change, then. In the past you have
> committed to binary compatibility for the Subversion library API until
> 2.0. Now you are breaking it, at least for those who use the deps
> tarball - which to me represents an official endorsement.
>
> I'm also disappointed because last time a related issue came up - I
> advocated allowing libsvn-with-apr-0.9 and libsvn-with-apr-1.x to be
> installed in parallel (so apps would automatically use whichever one
> they were compiled with) - my idea was shot down specifically because
> it would not honor the promise of binary compatibility until 2.0. Now
> your situation will be even worse: not only will libsvn be
> binary-incompatible, but third-party apps will _need_ to be recompiled
> or they will crash. Maybe I'm weird, but I'd much rather have an app
> use an older version of libsvn (or complain at startup that you deleted
> that older version) than try to use the latest libsvn and then
> misbehave or crash randomly at runtime.
>
> Justin in particular was pretty vocal in his belief that my proposal
> would break promises to the users. I hope he opposes this change at
> least as strenuously, for the same reason.
I was always under the impression that the deps tarball was a way of
not scaring off people from installing Subversion back when it was a
brand new system nobody had ever heard of with a surprising number of
dependencies. Now that Subversion is dominant enough that no
self-respecting system makes it hard to get svn up and running (and
even major consumer operating systems ship with svn by default), the
deps tarball seems like a nice gesture, but hardly a source of
compatibility worries.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by David Glasser <gl...@davidglasser.net>.
On Tue, Apr 8, 2008 at 7:34 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Tue, Apr 8, 2008 at 10:28 AM, Peter Samuelson <pe...@p12n.org> wrote:
> >
> > [Mark Phippard]
> > > We talked about this last year and decided we were going to update to
> > > the latest APR. I do not see any reason to change that decision.
> >
> > That is a fundamental policy change, then. In the past you have
> > committed to binary compatibility for the Subversion library API until
> > 2.0. Now you are breaking it, at least for those who use the deps
> > tarball - which to me represents an official endorsement.
>
> I am sorry but I think that is just a complete distortion. Is Debian
> or Red Hat or Ubuntu or any distribution going to build Subversion
> using our deps tarball? How is binary compatibility broken exactly?
>
> If you are a user building Subversion yourself you have complete
> control over the dependencies you use. BTW, you also probably could
> care less about binary compatibility. Why should we include old
> versions of things like APR and Neon when there are better versions
> available that fix bugs? The vast majority of users could care less
> about binary compat, and those that do are likely picking their own
> dependencies and unaffected by this. Please try to use a little
> perspective here.
Well, the underlying issue here is using mod_dav_svn with Apache 1.3, I think...
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Apr 8, 2008 at 10:28 AM, Peter Samuelson <pe...@p12n.org> wrote:
>
> [Mark Phippard]
> > We talked about this last year and decided we were going to update to
> > the latest APR. I do not see any reason to change that decision.
>
> That is a fundamental policy change, then. In the past you have
> committed to binary compatibility for the Subversion library API until
> 2.0. Now you are breaking it, at least for those who use the deps
> tarball - which to me represents an official endorsement.
I am sorry but I think that is just a complete distortion. Is Debian
or Red Hat or Ubuntu or any distribution going to build Subversion
using our deps tarball? How is binary compatibility broken exactly?
If you are a user building Subversion yourself you have complete
control over the dependencies you use. BTW, you also probably could
care less about binary compatibility. Why should we include old
versions of things like APR and Neon when there are better versions
available that fix bugs? The vast majority of users could care less
about binary compat, and those that do are likely picking their own
dependencies and unaffected by this. Please try to use a little
perspective here.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Peter Samuelson <pe...@p12n.org>.
[Mark Phippard]
> We talked about this last year and decided we were going to update to
> the latest APR. I do not see any reason to change that decision.
That is a fundamental policy change, then. In the past you have
committed to binary compatibility for the Subversion library API until
2.0. Now you are breaking it, at least for those who use the deps
tarball - which to me represents an official endorsement.
I'm also disappointed because last time a related issue came up - I
advocated allowing libsvn-with-apr-0.9 and libsvn-with-apr-1.x to be
installed in parallel (so apps would automatically use whichever one
they were compiled with) - my idea was shot down specifically because
it would not honor the promise of binary compatibility until 2.0. Now
your situation will be even worse: not only will libsvn be
binary-incompatible, but third-party apps will _need_ to be recompiled
or they will crash. Maybe I'm weird, but I'd much rather have an app
use an older version of libsvn (or complain at startup that you deleted
that older version) than try to use the latest libsvn and then
misbehave or crash randomly at runtime.
Justin in particular was pretty vocal in his belief that my proposal
would break promises to the users. I hope he opposes this change at
least as strenuously, for the same reason.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Apr 8, 2008 at 9:42 AM, Peter Samuelson <pe...@p12n.org> wrote:
>
> [Hyrum K. Wright]
>
> > I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> > signing. The magic revision is r30419.
>
> Please revert to apr 0.9 and apr-util 0.9 in the deps tarball. See
> Kamesh's note at http://svn.haxx.se/dev/archive-2008-03/0475.shtml .
We talked about this last year and decided we were going to update to
the latest APR. I do not see any reason to change that decision. No
matter what we choose there will always be scenarios where people will
have a problem. I would assume that regardless of what we include in
our deps tarballs, distributions are going to choose the right
dependencies for their distro. We ought to include the "best"
versions of dependencies in our tarball.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by Peter Samuelson <pe...@p12n.org>.
[Hyrum K. Wright]
> I'm pleased to announce that Subversion 1.5.0-rc1 is up for testing and
> signing. The magic revision is r30419.
Please revert to apr 0.9 and apr-util 0.9 in the deps tarball. See
Kamesh's note at http://svn.haxx.se/dev/archive-2008-03/0475.shtml .
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.0-rc1 up for signing/testing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Summary:
+1 to release.
Platform:
Ubunty Linux 7.10 gutsy
Tested:
1.5.0-rc1, serf (trunk), neon 0.28.2, apr from Apache 2.2.6
(fsfs, bdb) x (local, svn, neon, serf) + py + pl + rb + javahl
Results:
All tests passed except:
(fsfs, bdb) x (neon, serf): update_tests.py 41
rb: test_merge(SvnClientTest)
rb: test_merge_peg(SvnClientTest)
MD5 Checksums:
19f7816f9c1cf675f3e7cce89e256701 subversion-1.5.0-rc1.tar.bz2
997f4aace984906eb5923733abfa7bed subversion-1.5.0-rc1.tar.gz
Signatures:
subversion-1.5.0-rc1.tar.bz2.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBH+7C4okEGqRcG/W4RAmEJAJwOgsVRr8eD7tnN56rY2MQUP80AHQCfS5Dl
npukE8cfMcV0M2C8Q/m0/3A=
=B8az
-----END PGP SIGNATURE-----
subversion-1.5.0-rc1.tar.gz.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBH+7DuokEGqRcG/W4RAsABAJ9baflYW1VF+SLcTl1sWbG6OFRIxgCgpadH
f1zRzG86roh2CvkvHChoigo=
=euml
-----END PGP SIGNATURE-----
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.0-rc1 up for signing/testing
Posted by Mark Phippard <ma...@gmail.com>.
I tested on Windows XP and OSX Leopard. On each OS, I ran these tests:
ra_local + ra_svn X fsfs + bdb
JavaHL
I am +1 for release. Here are my signatures.
subversion-1.5.0-rc1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEABECAAYFAkf7dREACgkQJl34oANalqlbKgCgqbu1Ny+ZPdz8T+ceKoKIxwjC
WREAoI8ND921EcSgYLPlncFiXmBR6BxD
=pnWv
-----END PGP SIGNATURE-----
subversion-deps-1.5.0-rc1.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEABECAAYFAkf7dT4ACgkQJl34oANalqnvWQCfRL3d0SUr/x0VL9Lwyiy+Nn0C
5ZEAoJ0fceVjkJu2VKd7kPntdha0xVhc
=wf2J
-----END PGP SIGNATURE-----
subversion-1.5.0-rc1.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEABECAAYFAkf7dTAACgkQJl34oANalqlf+wCff4wQ/xB7aoNyjTfBiiTLYgJ8
t6AAoKp0YdZ1i8SZtLunKfRaQRXp96oI
=Gx+d
-----END PGP SIGNATURE-----
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org