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/05/15 04:05:03 UTC
1.5.x, RC 6 and 1.5.0
Hi all. We're almost halfway through the 4-week soak period for rc5.
There have been several minor items merged to the 1.5.x branch, but
overall, it looks like we're on track for release during the first week
of June (*knock on wood*).
I just wanted to remind everybody about the following paragraph from
HACKING:
"At the beginning of the final week of the stabilization period, a new
release candidate tarball should be made if there are any changes
pending since the last one. The final week of the stabilization period
is reserved for critical bugfixes; fixes for minor bugs should be
deferred to the A.B.1 release. A critical bug is a non-edge-case crash,
a data corruption problem, a major security hole, or something equally
serious." [http://subversion.tigris.org/hacking.html#release-stabilization]
RC 5 was released on May 5, so I plan on rolling and posting the next
(and hopefully final!) release candidate on May 23-24. If all goes
well, whatever makes it into that RC will be in 1.5.0-final; they will
share the same magic revision. Fixes which don't make it into RC 6 will
be postponed to 1.5.1, which I anticipate releases 1-2 months after
1.5.0, pending demand.
Over the next week, please continue testing RC 5, and be sure to
nominate any additional fixes to STATUS. Thanks again to everybody for
the hard work -- I'm starting to think that the light at the end of the
tunnel isn't a train!
-Hyrum
Re: 1.5.x, RC 6 and 1.5.0
Posted by Blair Zajac <bl...@orcaware.com>.
Mark Phippard wrote:
> On Mon, May 19, 2008 at 4:55 PM, Karl Fogel <kf...@red-bean.com> wrote:
>> "Mark Phippard" <ma...@gmail.com> writes:
> Then I guess I'd be in favor of releasing 1.5.0 based off RC5 and get
> the 1.5.1 queued up to be ready to go shortly thereafter (say 3-4
> weeks later).
I don't see what the large rush is to get it out. I would rather not put out a
release that distributers are just going to put in patches that will be in
1.5.1. Also, I would not want to see a release based off rc5.
These are the changes that were merged in that I would like to see in a release.
Some are pretty minor. The most important ones for me are the improvements to
svnmerge-migrate-history.py and the Python bindings memory leak fix. Some of
these just seem like they should be in a top notch release. I don't want to be
like Oracle, as our DBA says, always wait for the .1 release.
r31114 | hwright | 2008-05-09 07:47:36 -0700 (Fri, 09 May 2008) | 7 lines
Merge r31107 from trunk:
* r31107
ra_serf: Fix API bug when fetched_rev is non-NULL and revision is invalid.
Votes:
+1: epg, jerenkrantz, kfogel
r31147 | hwright | 2008-05-12 21:50:16 -0700 (Mon, 12 May 2008) | 12 lines
Merge r31055, r31066 from trunk:
* r31055 (subversion/bindings/swig), r31066
Make svn_wc_diff_callbacks2_t work in Python (not a new interface,
it was just broken for Python until r31055).
Notes:
'svn merge -c 31055 ^/trunk/subversion/bindings/swig
subversion/bindings/swig' cleanly merges the Python change.
Votes:
+1: epg
+0: djames
r31148 | hwright | 2008-05-12 21:51:24 -0700 (Mon, 12 May 2008) | 12 lines
Merge r31145 from trunk:
* r31145
Fix memory leaks in Python bindings.
Justification:
Memory leaks are bad.
Notes:
Depends on r31055 and r31066 (see above)
Votes:
+1: djames
+0: epg
r31164 | hwright | 2008-05-14 07:44:27 -0700 (Wed, 14 May 2008) | 9 lines
Merge r31081, r31082, r31153, r31155 from trunk:
* r31081, r31082, r31153, r31155
Various improvements to svnmerge-migrate-history.py for dealing
with the kinds of problems caused by svnmerge.py's total ignorance
of object history.
Votes:
+1: cmpilato, dlr
r31182 | hwright | 2008-05-14 20:53:40 -0700 (Wed, 14 May 2008) | 7 lines
Merge r31162 from trunk:
* r31162
Fix an OBOE in svn_path_splitext().
Votes:
+1: cmpilato, kfogel, danielsh
r31183 | hwright | 2008-05-14 20:56:17 -0700 (Wed, 14 May 2008) | 10 lines
Merge r31131 from trunk:
* r31131
Restore compatibility of svn_client_add3()'s non-recursive behavior.
Notes:
This fixes an API incompatibility. But in practice it's a minor
problem, and could probably wait until 1.5.1 if necessary.
Votes:
+1: kfogel, epg, cmpilato
r31184 | hwright | 2008-05-14 20:57:18 -0700 (Wed, 14 May 2008) | 7 lines
Merge r31056 from trunk:
* r31056
Enable svn.diff in swig-py on Windows.
Votes:
+1: epg, arfrever, cmpilato
The changes that have not yet been merged in that I feel should are:
* r31059, 31060, 31061, 31075, 31151
Fix issue #3157, Merging a change from a path's natural history
creates self-referential mergeinfo
Notes:
r31075 and 31151 are the core fixes for the issue, the other revisions
are a new test for it (and a few minor follow-ups to that test).
The addition of the new merge test in r31059 trivally conflicts
because several other new merge tests are not backported yet.
Votes:
+1: pburba, cmpilato
* r31243, r31246, r31249, r31250, r31251, r31271
Fix issue #3200, API Ickiness: svn_client_ctx_t shouldn't carry
"extra revprops"; the svn_client APIs should
Notes:
If we *don't* backport this in 1.5.0, we need to undo the changes
or otherwise rework them to use newly-revved svn_client APIs.
This is not quite finished -- need feedback from Ruby, Perl, and
JavaHL bindings maintainers.
Votes:
Given the changes that have been merged into the branch, I think we should merge
in these two sets of changes, cut an RC6 by Wednesday if possible. If the Ruby,
Perl and JavaHL bindings are not completely up to snuff, we can extend them in
1.5.1. Better the C API be clean.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.x, RC 6 and 1.5.0
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> Yes, I knew you said that but I had gotten a little confused by some
> of your other comments where it seemed like you were evaluation what
> to include on a commit by commit basis.
Sure, I am advocating that kind of evaluation. If a change is
trivial/obvious/simple, then there's no reason it needs to restart the
soak.
The mechanism by which we include those changes while not including
other ones is an implementation detail. There are various ways to do
it, they all work fine, and this thread doesn't need to go into them --
that's why we have a release manager (yay).
> I should really probably read the archives before I make this point,
> but I know we have had previous releases where 4-5 weeks into the
> cycle we merged non-trivial fixes and did not do a full soak. I do
> not want to open a debate on our policies, which I generally agree
> with, but let's be honest here. If these fixes go into a 1.5.1 we
> will release them with essentially no soak period at all.
That's a very good point -- I guess it just reaffirms the fact that
point releases are supposed to be for conservative fixes anyway, not big
things. But remember, anything that goes into 1.5.1 will also have been
"soaked" on trunk for that long. Also, we can optionally soak a point
release for as long as we want; some of the pressure is off then anyway,
because the .0 will already be out.
I don't want to be a mindless stickler for rules here. I'll just review
those changes in detail and see if afterwards I'm still disturbed by
anything. Hope others will be doing same.
> Yes for merge, but no for the log -g/blame -g options. As Mike said,
> this property is versioned and those commands operate on what happened
> to the property in the history of the repository.
Mmm, right, gotcha.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.x, RC 6 and 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, May 19, 2008 at 4:55 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "Mark Phippard" <ma...@gmail.com> writes:
>> On Sat, May 17, 2008 at 8:49 PM, Karl Fogel <kf...@red-bean.com> wrote:
>>> Mark Phippard <ma...@gmail.com> writes:
>>>> Make an rc6 soon so that we can give it a couple weeks before release?
>>>
>>> ? Well, that doesn't really address the question I'm asking... We
>>> already have a date on which to roll rc6, and while I've no objection to
>>> adding an extra week to its soak time, I don't think it's really
>>> necessary either.
>>
>> What is the date? I was not aware we had set one. I was thinking if
>> make an RC6 it will about a week from now. I was just saying let's do
>> the RC6 now so that we can have an extra week with it running on our
>> server and elsewhere.
>
> Oh, I was referring to Hyrum's mail from last Wednesday, this one:
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=138591.
> He wrote:
>
> > RC 5 was released on May 5, so I plan on rolling and posting the
> > next (and hopefully final!) release candidate on May 23-24. If all
> > goes well, whatever makes it into that RC will be in 1.5.0-final;
> > they will share the same magic revision. Fixes which don't make it
> > into RC 6 will be postponed to 1.5.1, which I anticipate releases
> > 1-2 months after 1.5.0, pending demand.
>
>> But would you propose we "un-merge" the ones we are not sure of? On
>> some of the ones you are concerned with, I am mostly concerned if they
>> cause unrelated regressions. Especially since that has plagued us
>> during the RC process. That said, I have concerned about some of the
>> changes still in STATUS:
>
> No un-merging necessary. Like I said, we have a choice of whether to
> branch the next RC from the previous RC's tag or from the tip of the
> current branch.
Yes, I knew you said that but I had gotten a little confused by some
of your other comments where it seemed like you were evaluation what
to include on a commit by commit basis.
>> What if we just pushed to get STATUS clean and do an RC6 and give it
>> two weeks for GA?
>
> Hmm, well, so we just ditch the original intent of the four-week soak?
> We allow trivial/obvious changes to go in without restarting the soak.
> But the guidelines (which IMHO are good) are pretty clear that what gets
> released has to be basically what was soaked for four weeks. We seem to
> be drifting away from that, and more by accident than on purpose.
I should really probably read the archives before I make this point,
but I know we have had previous releases where 4-5 weeks into the
cycle we merged non-trivial fixes and did not do a full soak. I do
not want to open a debate on our policies, which I generally agree
with, but let's be honest here. If these fixes go into a 1.5.1 we
will release them with essentially no soak period at all.
> You mentioned two that were of special concern:
>
>> * r31059, 31060, 31061, 31075, 31151
>> Fix issue #3157, Merging a change from a path's natural history
>> creates self-referential mergeinfo
>>
>> I would like to see this in 1.5.0 because once the "bad" mergeinfo is
>> created you cannot fix it. Note, that the mergeinfo is only bad for
>> log -g, not merge itself. But we have run into this problem on our
>> own repository, as well as via a user testing the RC. So we know it
>> is real.
>
> That sounds pretty serious. But is it absolutely necessary that it go
> in?
I wouldn't call it serious, more icky. I would say serious would be
something where it caused problems for merge. It sucks for log -g
users. I am also not sure how common it would happen. We have run
into it, but only on a couple of merges. Mike Pilato made a recipe
for creating the problem fairly easy. The only reason I think it
should go into 1.5.0 is ...
> Can't mergeinfo be edited?
Yes for merge, but no for the log -g/blame -g options. As Mike said,
this property is versioned and those commands operate on what happened
to the property in the history of the repository.
> How often is this likely to happen
> anyway? If it waited for 1.5.1, would that be a disaster? We can't
> keep folding in serious bugfixes and then pretending they aren't exactly
> what our soak time is intended to soak.
I agree and I cannot really say whether this particular fix is more or
less likely to cause regressions compared to other fixes.
> I'm reviewing the mergeinfo-related changes in STATUS and the ones
> merged since 1.5.0-rc5 (see r31218, r31186, r31185). From a high-level
> appraisal, it does look like some of those cannot be considered
> "trivial", though.
>
> We really need to focus on the fact that the point of a soak is that to
> release the thing that was soaking, not some other thing that is
> somewhat related. The hacking.html guidelines are clear on this, and we
> wrote them that way for a reason. I'm reluctant to revise the process.
> If we are going to revise it, let's please do it consciously :-).
>
>> * r31243, r31246, r31249, r31250, r31251, r31271
>> Fix issue #3200, API Ickiness: svn_client_ctx_t shouldn't carry
>> "extra revprops"; the svn_client APIs should
>> Notes:
>> If we *don't* backport this in 1.5.0, we need to undo the changes
>> or otherwise rework them to use newly-revved svn_client APIs.
>> This is not quite finished -- need feedback from Ruby, Perl, and
>> JavaHL bindings maintainers.
>>
>> Since it is fixing the API it has to go into 1.5.0 or pretty much just
>> be undone. I want to be against this change as not being worth the
>> risk, but I suspect the API ickiness in this case is probably worth
>> fixing.
>
> Sure, this was just an API untwisting, not a "real" code change. As
> long as we have enough eyeballs on it, I think there's little real risk
> in letting it in with just a one- or two-week soak.
Well FWIW, I think of the soak as being more important for our API
consumers than anyone else and changing the API at the last minute is
probably worse than trying to fix a bug.
>> What if we just pushed to get STATUS clean and do an RC6 and give it
>> two weeks for GA?
>
> Mrm. <squirms uncomfortably> See comments above.
Then I guess I'd be in favor of releasing 1.5.0 based off RC5 and get
the 1.5.1 queued up to be ready to go shortly thereafter (say 3-4
weeks later).
--
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.x, RC 6 and 1.5.0
Posted by "C. Michael Pilato" <cm...@collab.net>.
Karl Fogel wrote:
> You mentioned two that were of special concern:
>
>> * r31059, 31060, 31061, 31075, 31151
>> Fix issue #3157, Merging a change from a path's natural history
>> creates self-referential mergeinfo
>>
>> I would like to see this in 1.5.0 because once the "bad" mergeinfo is
>> created you cannot fix it. Note, that the mergeinfo is only bad for
>> log -g, not merge itself. But we have run into this problem on our
>> own repository, as well as via a user testing the RC. So we know it
>> is real.
>
> That sounds pretty serious. But is it absolutely necessary that it go
> in? Can't mergeinfo be edited? How often is this likely to happen
> anyway? If it waited for 1.5.1, would that be a disaster? We can't
> keep folding in serious bugfixes and then pretending they aren't exactly
> what our soak time is intended to soak.
Mergeinfo is versioned, and therefore can't be (easily) retroactively edited.
>> * r31243, r31246, r31249, r31250, r31251, r31271
>> Fix issue #3200, API Ickiness: svn_client_ctx_t shouldn't carry
>> "extra revprops"; the svn_client APIs should
>> Notes:
>> If we *don't* backport this in 1.5.0, we need to undo the changes
>> or otherwise rework them to use newly-revved svn_client APIs.
>> This is not quite finished -- need feedback from Ruby, Perl, and
>> JavaHL bindings maintainers.
>>
>> Since it is fixing the API it has to go into 1.5.0 or pretty much just
>> be undone. I want to be against this change as not being worth the
>> risk, but I suspect the API ickiness in this case is probably worth
>> fixing.
>
> Sure, this was just an API untwisting, not a "real" code change. As
> long as we have enough eyeballs on it, I think there's little real risk
> in letting it in with just a one- or two-week soak.
Agreed.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 1.5.x, RC 6 and 1.5.0
Posted by Karl Fogel <kf...@red-bean.com>.
"Mark Phippard" <ma...@gmail.com> writes:
> On Sat, May 17, 2008 at 8:49 PM, Karl Fogel <kf...@red-bean.com> wrote:
>> Mark Phippard <ma...@gmail.com> writes:
>>> Make an rc6 soon so that we can give it a couple weeks before release?
>>
>> ? Well, that doesn't really address the question I'm asking... We
>> already have a date on which to roll rc6, and while I've no objection to
>> adding an extra week to its soak time, I don't think it's really
>> necessary either.
>
> What is the date? I was not aware we had set one. I was thinking if
> make an RC6 it will about a week from now. I was just saying let's do
> the RC6 now so that we can have an extra week with it running on our
> server and elsewhere.
Oh, I was referring to Hyrum's mail from last Wednesday, this one:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=138591.
He wrote:
> RC 5 was released on May 5, so I plan on rolling and posting the
> next (and hopefully final!) release candidate on May 23-24. If all
> goes well, whatever makes it into that RC will be in 1.5.0-final;
> they will share the same magic revision. Fixes which don't make it
> into RC 6 will be postponed to 1.5.1, which I anticipate releases
> 1-2 months after 1.5.0, pending demand.
> But would you propose we "un-merge" the ones we are not sure of? On
> some of the ones you are concerned with, I am mostly concerned if they
> cause unrelated regressions. Especially since that has plagued us
> during the RC process. That said, I have concerned about some of the
> changes still in STATUS:
No un-merging necessary. Like I said, we have a choice of whether to
branch the next RC from the previous RC's tag or from the tip of the
current branch.
> What if we just pushed to get STATUS clean and do an RC6 and give it
> two weeks for GA?
Hmm, well, so we just ditch the original intent of the four-week soak?
We allow trivial/obvious changes to go in without restarting the soak.
But the guidelines (which IMHO are good) are pretty clear that what gets
released has to be basically what was soaked for four weeks. We seem to
be drifting away from that, and more by accident than on purpose.
When someone nominates a change for backport in the "1.5.0" section of
STATUS, that doesn't mean that change has to go into 1.5.0. It just
means that if we're re-starting the full soak anyway, then that change
might as well go in. But if we're not restarting the full soak, then
it's an open question whether the change can wait till 1.5.1 or not --
it really depends on the individual change.
You mentioned two that were of special concern:
> * r31059, 31060, 31061, 31075, 31151
> Fix issue #3157, Merging a change from a path's natural history
> creates self-referential mergeinfo
>
> I would like to see this in 1.5.0 because once the "bad" mergeinfo is
> created you cannot fix it. Note, that the mergeinfo is only bad for
> log -g, not merge itself. But we have run into this problem on our
> own repository, as well as via a user testing the RC. So we know it
> is real.
That sounds pretty serious. But is it absolutely necessary that it go
in? Can't mergeinfo be edited? How often is this likely to happen
anyway? If it waited for 1.5.1, would that be a disaster? We can't
keep folding in serious bugfixes and then pretending they aren't exactly
what our soak time is intended to soak.
I'm reviewing the mergeinfo-related changes in STATUS and the ones
merged since 1.5.0-rc5 (see r31218, r31186, r31185). From a high-level
appraisal, it does look like some of those cannot be considered
"trivial", though.
We really need to focus on the fact that the point of a soak is that to
release the thing that was soaking, not some other thing that is
somewhat related. The hacking.html guidelines are clear on this, and we
wrote them that way for a reason. I'm reluctant to revise the process.
If we are going to revise it, let's please do it consciously :-).
> * r31243, r31246, r31249, r31250, r31251, r31271
> Fix issue #3200, API Ickiness: svn_client_ctx_t shouldn't carry
> "extra revprops"; the svn_client APIs should
> Notes:
> If we *don't* backport this in 1.5.0, we need to undo the changes
> or otherwise rework them to use newly-revved svn_client APIs.
> This is not quite finished -- need feedback from Ruby, Perl, and
> JavaHL bindings maintainers.
>
> Since it is fixing the API it has to go into 1.5.0 or pretty much just
> be undone. I want to be against this change as not being worth the
> risk, but I suspect the API ickiness in this case is probably worth
> fixing.
Sure, this was just an API untwisting, not a "real" code change. As
long as we have enough eyeballs on it, I think there's little real risk
in letting it in with just a one- or two-week soak.
> What if we just pushed to get STATUS clean and do an RC6 and give it
> two weeks for GA?
Mrm. <squirms uncomfortably> See comments above.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.x, RC 6 and 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
On Sat, May 17, 2008 at 8:49 PM, Karl Fogel <kf...@red-bean.com> wrote:
> Mark Phippard <ma...@gmail.com> writes:
>> Make an rc6 soon so that we can give it a couple weeks before release?
>
> ? Well, that doesn't really address the question I'm asking... We
> already have a date on which to roll rc6, and while I've no objection to
> adding an extra week to its soak time, I don't think it's really
> necessary either.
What is the date? I was not aware we had set one. I was thinking if
make an RC6 it will about a week from now. I was just saying let's do
the RC6 now so that we can have an extra week with it running on our
server and elsewhere.
> The question is just what changes to include in rc6. For example, I'd
> be very happy for 1.5.x-r31159-r31179 branch changes (merged in r31218)
> to simply wait until 1.5.1. That way they'd get a full soak in a later
> RC, and of course testing on trunk as well that whole time.
>
> Regarding the other two changesets I listed (merged in r31186 and
> r31185), a good plan would be for us to figure out what harm would come
> from letting them wait until 1.5.1. If we decide they can wait, then
> IMHO they should; if we decide they really need to be in in 1.5.0, let's
> at least give give them extra review, so that on top of the one-week
> soak they've had more brain time as well.
But would you propose we "un-merge" the ones we are not sure of? On
some of the ones you are concerned with, I am mostly concerned if they
cause unrelated regressions. Especially since that has plagued us
during the RC process. That said, I have concerned about some of the
changes still in STATUS:
* r31059, 31060, 31061, 31075, 31151
Fix issue #3157, Merging a change from a path's natural history
creates self-referential mergeinfo
I would like to see this in 1.5.0 because once the "bad" mergeinfo is
created you cannot fix it. Note, that the mergeinfo is only bad for
log -g, not merge itself. But we have run into this problem on our
own repository, as well as via a user testing the RC. So we know it
is real.
Then there is this one:
* r31243, r31246, r31249, r31250, r31251, r31271
Fix issue #3200, API Ickiness: svn_client_ctx_t shouldn't carry
"extra revprops"; the svn_client APIs should
Notes:
If we *don't* backport this in 1.5.0, we need to undo the changes
or otherwise rework them to use newly-revved svn_client APIs.
This is not quite finished -- need feedback from Ruby, Perl, and
JavaHL bindings maintainers.
Since it is fixing the API it has to go into 1.5.0 or pretty much just
be undone. I want to be against this change as not being worth the
risk, but I suspect the API ickiness in this case is probably worth
fixing.
What if we just pushed to get STATUS clean and do an RC6 and give it
two weeks for GA?
--
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.x, RC 6 and 1.5.0
Posted by Karl Fogel <kf...@red-bean.com>.
Mark Phippard <ma...@gmail.com> writes:
> Make an rc6 soon so that we can give it a couple weeks before release?
? Well, that doesn't really address the question I'm asking... We
already have a date on which to roll rc6, and while I've no objection to
adding an extra week to its soak time, I don't think it's really
necessary either.
The question is just what changes to include in rc6. For example, I'd
be very happy for 1.5.x-r31159-r31179 branch changes (merged in r31218)
to simply wait until 1.5.1. That way they'd get a full soak in a later
RC, and of course testing on trunk as well that whole time.
Regarding the other two changesets I listed (merged in r31186 and
r31185), a good plan would be for us to figure out what harm would come
from letting them wait until 1.5.1. If we decide they can wait, then
IMHO they should; if we decide they really need to be in in 1.5.0, let's
at least give give them extra review, so that on top of the one-week
soak they've had more brain time as well.
> Sent from my iPhone
:-)
-Karl
> On May 17, 2008, at 7:34 PM, Karl Fogel <kf...@red-bean.com> wrote:
>
>> "Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
>>> Hi all. We're almost halfway through the 4-week soak period for
>>> rc5. There have been several minor items merged to the 1.5.x branch,
>>> but overall, it looks like we're on track for release during the
>>> first
>>> week of June (*knock on wood*).
>>>
>>> [...]
>>> [http://subversion.tigris.org/hacking.html#release-stabilization]
>>> [...]
>>>
>>> RC 5 was released on May 5, so I plan on rolling and posting the next
>>> (and hopefully final!) release candidate on May 23-24. If all goes
>>> well, whatever makes it into that RC will be in 1.5.0-final; they
>>> will
>>> share the same magic revision. Fixes which don't make it into RC 6
>>> will be postponed to 1.5.1, which I anticipate releases 1-2 months
>>> after 1.5.0, pending demand.
>>
>> Below are all the changes that have been ported to the 1.5.x branch
>> since 1.5.0-rc5 came out. I think a few of them are questionable for
>> inclusion in a one-week soak (that is, I've no complaints about the
>> changes themselves, I just think they might be a bit complex to be
>> released with undergoing full soak).
>>
>> Of course, the fact that they were merged into 1.5.x is fine, no
>> objection there. The question is merely whether we make the final RC
>> (and thence 1.5.0 itself) off the tip of the 1.5.x branch or off the
>> 1.5.0-rc5 tag. In the former case, we automatically get all the
>> changes
>> below; in the latter case, we pick which changes we want to re-merge,
>> and anything below that doesn't get re-merged ends up in 1.5.1 anyway.
>>
>> Just to be clear: I am *not* proposing that any soak times be
>> extended.
>> The ship date should not be affected by any of this; I'm just asking
>> about what should be included in the release when it happens.
>>
>> Search for "### THOUGHTS? ###" below to see which merges look to me
>> like
>> they might want more than one week of soak. There should be only
>> three:
>> r31218, r31186, r31185.
>>
>> ---
>> ---------------------------------------------------------------------
>> r31218 | cmpilato | 2008-05-15 15:58:42 -0400 (Thu, 15 May 2008) |
>> 16 lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/libsvn_wc/merge.c
>> M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
>>
>> Merge from trunk this change group:
>>
>> ### THOUGHTS? ###
>>
>> * (r31159, r31179) or r31193 from 1.5.x-r31159-r31179 branch.
>> Fix "file not found" error when a merge target is a broken
>> symbolic link.
>> Notes:
>> r31179 just makes sure the new test is skipped on Windows.
>> r31193 from 1.5.x-r31159-r31179 branch has r31159 and r31179
>> merged to it with a conflict resolution.
>> Votes:
>> +1: kfogel(r31159, r31179), kameshj, cmpilato (r31159, r31179)
>>
>> Also:
>>
>> * STATUS
>> Remove the group.
>>
>> ---
>> ---------------------------------------------------------------------
>> r31216 | cmpilato | 2008-05-15 15:40:26 -0400 (Thu, 15 May 2008) |
>> 16 lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/include/svn_repos.h
>> M /branches/1.5.x/subversion/libsvn_repos/fs-wrap.c
>> M /branches/1.5.x/subversion/tests/cmdline/prop_tests.py
>>
>> Merge this change group from trunk:
>>
>> * r31138, r31141, r31157, r31209
>> Validate svn:date property values in libsvn_repos.
>> Notes:
>> r31141 is a docstring change.
>> r31157 marks the regression test XFail over DAV.
>> r31209 is a teeny typo (read: obvious) fix
>> Votes:
>> +1: danielsh, kfogel, cmpilato
>>
>> Also:
>>
>> * STATUS
>> Remove the group.
>>
>> ---
>> ---------------------------------------------------------------------
>> r31186 | hwright | 2008-05-15 00:00:53 -0400 (Thu, 15 May 2008) | 14
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/libsvn_client/merge.c
>> M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
>>
>> Merge r30746, r30747 from trunk:
>>
>> ### THOUGHTS? ###
>>
>> * r30746, r30747
>> Fix a minor merge range notification header bug.
>> Notes:
>> r30747 is just cleanup of some cruft that snuck in with r30746,
>> thus adhering to my "every commit should need a follow-up" ethos.
>> r30746 contains, like, one tiny *real* change, then a whole bunch
>> of bogus indentation changes that were supposed to be part of
>> r30748. Probably best to not fix that indentation during
>> backport, in case we later backport r30748.
>> Votes:
>> +1: pburba, markphip, cmpilato
>>
>> ---
>> ---------------------------------------------------------------------
>> r31185 | hwright | 2008-05-14 23:59:12 -0400 (Wed, 14 May 2008) | 8
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/libsvn_client/merge.c
>> M /branches/1.5.x/subversion/libsvn_client/mergeinfo.c
>> M /branches/1.5.x/subversion/libsvn_client/mergeinfo.h
>> M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
>>
>> Merge r30949, r30962 from trunk:
>>
>> ### THOUGHTS? ###
>>
>> * r30949, r30962
>> Fix issue #3188. Mergeinfo on switched targets/subtrees should
>> elide
>> to repos.
>> Votes:
>> +1: pburba, markphip, cmpilato
>>
>> ---
>> ---------------------------------------------------------------------
>> r31184 | hwright | 2008-05-14 23:57:18 -0400 (Wed, 14 May 2008) | 7
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/build.conf
>> M /branches/1.5.x/subversion/bindings/swig
>>
>> Merge r31056 from trunk:
>>
>> * r31056
>> Enable svn.diff in swig-py on Windows.
>> Votes:
>> +1: epg, arfrever, cmpilato
>>
>> ---
>> ---------------------------------------------------------------------
>> r31183 | hwright | 2008-05-14 23:56:17 -0400 (Wed, 14 May 2008) | 10
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/include/svn_client.h
>> M /branches/1.5.x/subversion/libsvn_client/add.c
>>
>> Merge r31131 from trunk:
>>
>> * r31131
>> Restore compatibility of svn_client_add3()'s non-recursive behavior.
>> Notes:
>> This fixes an API incompatibility. But in practice it's a minor
>> problem, and could probably wait until 1.5.1 if necessary.
>> Votes:
>> +1: kfogel, epg, cmpilato
>>
>> ---
>> ---------------------------------------------------------------------
>> r31182 | hwright | 2008-05-14 23:53:40 -0400 (Wed, 14 May 2008) | 7
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/libsvn_subr/path.c
>> M /branches/1.5.x/subversion/tests/libsvn_subr/path-test.c
>>
>> Merge r31162 from trunk:
>>
>> * r31162
>> Fix an OBOE in svn_path_splitext().
>> Votes:
>> +1: cmpilato, kfogel, danielsh
>>
>> ---
>> ---------------------------------------------------------------------
>> r31164 | hwright | 2008-05-14 10:44:27 -0400 (Wed, 14 May 2008) | 9
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/contrib/client-side/svnmerge/svnmerge-migrate-
>> history.py
>> M /branches/1.5.x/contrib/client-side/svnmerge/svnmerge-migrate-
>> test.sh
>> M /branches/1.5.x/subversion/bindings/swig
>>
>> Merge r31081, r31082, r31153, r31155 from trunk:
>>
>> * r31081, r31082, r31153, r31155
>> Various improvements to svnmerge-migrate-history.py for dealing
>> with the kinds of problems caused by svnmerge.py's total ignorance
>> of object history.
>> Votes:
>> +1: cmpilato, dlr
>>
>> ---
>> ---------------------------------------------------------------------
>> r31150 | hwright | 2008-05-13 00:54:47 -0400 (Tue, 13 May 2008) | 10
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/libsvn_ra_serf/log.c
>>
>> Merge r31125 from trunk:
>>
>> * r31125
>> Fix circular dependency between libsvn_ra and libsvn_ra_serf by
>> teaching
>> libsvn_ra_serf to call svn_ra_serf__has_capability directly.
>> Justification:
>> Trivial fix. Necessary for cygwin build.
>> Votes:
>> +1: djames, lgo, danielsh
>>
>> ---
>> ---------------------------------------------------------------------
>> r31149 | hwright | 2008-05-13 00:53:43 -0400 (Tue, 13 May 2008) | 10
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/libsvn_ra/compat.c
>>
>> Merge r31126 from trunk:
>>
>> * r31126
>> Use 'void *' to avoid compile warnings and eliminate casts.
>> Justification:
>> Trivial fix. Allows clean build with EXTRA_CFLAGS='-Wall
>> -Wno-uninitialized -Wdeclaration-after-statement -Werror'
>> Votes:
>> +1: djames, kfogel, lgo
>>
>> ---
>> ---------------------------------------------------------------------
>> r31148 | hwright | 2008-05-13 00:51:24 -0400 (Tue, 13 May 2008) | 12
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/
>> swigutil_py.c
>>
>> Merge r31145 from trunk:
>>
>> * r31145
>> Fix memory leaks in Python bindings.
>> Justification:
>> Memory leaks are bad.
>> Notes:
>> Depends on r31055 and r31066 (see above)
>> Votes:
>> +1: djames
>> +0: epg
>>
>> ---
>> ---------------------------------------------------------------------
>> r31147 | hwright | 2008-05-13 00:50:16 -0400 (Tue, 13 May 2008) | 12
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/bindings/swig
>> M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/
>> swigutil_py.c
>> M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/
>> swigutil_py.h
>> M /branches/1.5.x/subversion/bindings/swig/python/svn/wc.py
>> M /branches/1.5.x/subversion/bindings/swig/python/tests/wc.py
>> M /branches/1.5.x/subversion/bindings/swig/svn_wc.i
>>
>> Merge r31055, r31066 from trunk:
>>
>> * r31055 (subversion/bindings/swig), r31066
>> Make svn_wc_diff_callbacks2_t work in Python (not a new interface,
>> it was just broken for Python until r31055).
>> Notes:
>> 'svn merge -c 31055 ^/trunk/subversion/bindings/swig
>> subversion/bindings/swig' cleanly merges the Python change.
>> Votes:
>> +1: epg
>> +0: djames
>>
>> ---
>> ---------------------------------------------------------------------
>> r31114 | hwright | 2008-05-09 10:47:36 -0400 (Fri, 09 May 2008) | 7
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/libsvn_ra_serf/serf.c
>>
>> Merge r31107 from trunk:
>>
>> * r31107
>> ra_serf: Fix API bug when fetched_rev is non-NULL and revision is
>> invalid.
>> Votes:
>> +1: epg, jerenkrantz, kfogel
>>
>> ---
>> ---------------------------------------------------------------------
>> r31112 | cauchy | 2008-05-09 05:11:12 -0400 (Fri, 09 May 2008) | 4
>> lines
>> Changed paths:
>> M /branches/1.5.x/subversion/po/zh_CN.po
>>
>> Simplified chinese translation update.
>>
>> * subversion/po/zh_CN.po: translate new backport strings.
>>
>> ---
>> ---------------------------------------------------------------------
>> r31074 | hwright | 2008-05-07 15:50:04 -0400 (Wed, 07 May 2008) | 7
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/libsvn_fs_base/fs.c
>>
>> Merge r31049 from trunk:
>>
>> * r31049
>> s/lock-nodes/lock-tokens/ in a message.
>> Votes:
>> +1: arfrever, danielsh, hwright
>>
>> ---
>> ---------------------------------------------------------------------
>> r31073 | hwright | 2008-05-07 15:48:12 -0400 (Wed, 07 May 2008) | 7
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/include/svn_io.h
>>
>> Merge r31031 from trunk:
>>
>> * r31031
>> Match svn_io_check_path's docstring to its implementation.
>> Votes:
>> +1: danielsh, arfrever, hwright
>>
>> ---
>> ---------------------------------------------------------------------
>> r31071 | hwright | 2008-05-07 15:44:08 -0400 (Wed, 07 May 2008) | 7
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/include/svn_error_codes.h
>>
>> Merge r31025 from trunk:
>>
>> * r31025
>> Fix the SVN_ERR_AUTHN_CREDS_NOT_SAVED message.
>> Votes:
>> +1: arfrever, danielsh, hwright
>>
>> ---
>> ---------------------------------------------------------------------
>> r31065 | hwright | 2008-05-07 14:59:49 -0400 (Wed, 07 May 2008) | 10
>> lines
>> Changed paths:
>> M /branches/1.5.x
>> M /branches/1.5.x/CHANGES
>> M /branches/1.5.x/COMMITTERS
>> M /branches/1.5.x/STATUS
>> M /branches/1.5.x/subversion/include/svn_ra.h
>>
>> Merge r31018 from trunk:
>>
>> * r31018
>> Fix svn_ra_open3() doc string to say "@since 1.5" not "@since 1.6".
>> Notes: This falls into hacking.html's no-vote-necessary category.
>> Since I'm nominating it anyway, I'll record my vote, but I'm
>> just filing it directly in the Approved section.
>> Votes:
>> +1: kfogel, danielsh
>>
>> ---
>> ---------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.x, RC 6 and 1.5.0
Posted by Mark Phippard <ma...@gmail.com>.
Make an rc6 soon so that we can give it a couple weeks before release?
Sent from my iPhone
On May 17, 2008, at 7:34 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
>> Hi all. We're almost halfway through the 4-week soak period for
>> rc5. There have been several minor items merged to the 1.5.x branch,
>> but overall, it looks like we're on track for release during the
>> first
>> week of June (*knock on wood*).
>>
>> [...]
>> [http://subversion.tigris.org/hacking.html#release-stabilization]
>> [...]
>>
>> RC 5 was released on May 5, so I plan on rolling and posting the next
>> (and hopefully final!) release candidate on May 23-24. If all goes
>> well, whatever makes it into that RC will be in 1.5.0-final; they
>> will
>> share the same magic revision. Fixes which don't make it into RC 6
>> will be postponed to 1.5.1, which I anticipate releases 1-2 months
>> after 1.5.0, pending demand.
>
> Below are all the changes that have been ported to the 1.5.x branch
> since 1.5.0-rc5 came out. I think a few of them are questionable for
> inclusion in a one-week soak (that is, I've no complaints about the
> changes themselves, I just think they might be a bit complex to be
> released with undergoing full soak).
>
> Of course, the fact that they were merged into 1.5.x is fine, no
> objection there. The question is merely whether we make the final RC
> (and thence 1.5.0 itself) off the tip of the 1.5.x branch or off the
> 1.5.0-rc5 tag. In the former case, we automatically get all the
> changes
> below; in the latter case, we pick which changes we want to re-merge,
> and anything below that doesn't get re-merged ends up in 1.5.1 anyway.
>
> Just to be clear: I am *not* proposing that any soak times be
> extended.
> The ship date should not be affected by any of this; I'm just asking
> about what should be included in the release when it happens.
>
> Search for "### THOUGHTS? ###" below to see which merges look to me
> like
> they might want more than one week of soak. There should be only
> three:
> r31218, r31186, r31185.
>
> ---
> ---------------------------------------------------------------------
> r31218 | cmpilato | 2008-05-15 15:58:42 -0400 (Thu, 15 May 2008) |
> 16 lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/libsvn_wc/merge.c
> M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
>
> Merge from trunk this change group:
>
> ### THOUGHTS? ###
>
> * (r31159, r31179) or r31193 from 1.5.x-r31159-r31179 branch.
> Fix "file not found" error when a merge target is a broken
> symbolic link.
> Notes:
> r31179 just makes sure the new test is skipped on Windows.
> r31193 from 1.5.x-r31159-r31179 branch has r31159 and r31179
> merged to it with a conflict resolution.
> Votes:
> +1: kfogel(r31159, r31179), kameshj, cmpilato (r31159, r31179)
>
> Also:
>
> * STATUS
> Remove the group.
>
> ---
> ---------------------------------------------------------------------
> r31216 | cmpilato | 2008-05-15 15:40:26 -0400 (Thu, 15 May 2008) |
> 16 lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/include/svn_repos.h
> M /branches/1.5.x/subversion/libsvn_repos/fs-wrap.c
> M /branches/1.5.x/subversion/tests/cmdline/prop_tests.py
>
> Merge this change group from trunk:
>
> * r31138, r31141, r31157, r31209
> Validate svn:date property values in libsvn_repos.
> Notes:
> r31141 is a docstring change.
> r31157 marks the regression test XFail over DAV.
> r31209 is a teeny typo (read: obvious) fix
> Votes:
> +1: danielsh, kfogel, cmpilato
>
> Also:
>
> * STATUS
> Remove the group.
>
> ---
> ---------------------------------------------------------------------
> r31186 | hwright | 2008-05-15 00:00:53 -0400 (Thu, 15 May 2008) | 14
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/libsvn_client/merge.c
> M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
>
> Merge r30746, r30747 from trunk:
>
> ### THOUGHTS? ###
>
> * r30746, r30747
> Fix a minor merge range notification header bug.
> Notes:
> r30747 is just cleanup of some cruft that snuck in with r30746,
> thus adhering to my "every commit should need a follow-up" ethos.
> r30746 contains, like, one tiny *real* change, then a whole bunch
> of bogus indentation changes that were supposed to be part of
> r30748. Probably best to not fix that indentation during
> backport, in case we later backport r30748.
> Votes:
> +1: pburba, markphip, cmpilato
>
> ---
> ---------------------------------------------------------------------
> r31185 | hwright | 2008-05-14 23:59:12 -0400 (Wed, 14 May 2008) | 8
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/libsvn_client/merge.c
> M /branches/1.5.x/subversion/libsvn_client/mergeinfo.c
> M /branches/1.5.x/subversion/libsvn_client/mergeinfo.h
> M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
>
> Merge r30949, r30962 from trunk:
>
> ### THOUGHTS? ###
>
> * r30949, r30962
> Fix issue #3188. Mergeinfo on switched targets/subtrees should
> elide
> to repos.
> Votes:
> +1: pburba, markphip, cmpilato
>
> ---
> ---------------------------------------------------------------------
> r31184 | hwright | 2008-05-14 23:57:18 -0400 (Wed, 14 May 2008) | 7
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/build.conf
> M /branches/1.5.x/subversion/bindings/swig
>
> Merge r31056 from trunk:
>
> * r31056
> Enable svn.diff in swig-py on Windows.
> Votes:
> +1: epg, arfrever, cmpilato
>
> ---
> ---------------------------------------------------------------------
> r31183 | hwright | 2008-05-14 23:56:17 -0400 (Wed, 14 May 2008) | 10
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/include/svn_client.h
> M /branches/1.5.x/subversion/libsvn_client/add.c
>
> Merge r31131 from trunk:
>
> * r31131
> Restore compatibility of svn_client_add3()'s non-recursive behavior.
> Notes:
> This fixes an API incompatibility. But in practice it's a minor
> problem, and could probably wait until 1.5.1 if necessary.
> Votes:
> +1: kfogel, epg, cmpilato
>
> ---
> ---------------------------------------------------------------------
> r31182 | hwright | 2008-05-14 23:53:40 -0400 (Wed, 14 May 2008) | 7
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/libsvn_subr/path.c
> M /branches/1.5.x/subversion/tests/libsvn_subr/path-test.c
>
> Merge r31162 from trunk:
>
> * r31162
> Fix an OBOE in svn_path_splitext().
> Votes:
> +1: cmpilato, kfogel, danielsh
>
> ---
> ---------------------------------------------------------------------
> r31164 | hwright | 2008-05-14 10:44:27 -0400 (Wed, 14 May 2008) | 9
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/contrib/client-side/svnmerge/svnmerge-migrate-
> history.py
> M /branches/1.5.x/contrib/client-side/svnmerge/svnmerge-migrate-
> test.sh
> M /branches/1.5.x/subversion/bindings/swig
>
> Merge r31081, r31082, r31153, r31155 from trunk:
>
> * r31081, r31082, r31153, r31155
> Various improvements to svnmerge-migrate-history.py for dealing
> with the kinds of problems caused by svnmerge.py's total ignorance
> of object history.
> Votes:
> +1: cmpilato, dlr
>
> ---
> ---------------------------------------------------------------------
> r31150 | hwright | 2008-05-13 00:54:47 -0400 (Tue, 13 May 2008) | 10
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/libsvn_ra_serf/log.c
>
> Merge r31125 from trunk:
>
> * r31125
> Fix circular dependency between libsvn_ra and libsvn_ra_serf by
> teaching
> libsvn_ra_serf to call svn_ra_serf__has_capability directly.
> Justification:
> Trivial fix. Necessary for cygwin build.
> Votes:
> +1: djames, lgo, danielsh
>
> ---
> ---------------------------------------------------------------------
> r31149 | hwright | 2008-05-13 00:53:43 -0400 (Tue, 13 May 2008) | 10
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/libsvn_ra/compat.c
>
> Merge r31126 from trunk:
>
> * r31126
> Use 'void *' to avoid compile warnings and eliminate casts.
> Justification:
> Trivial fix. Allows clean build with EXTRA_CFLAGS='-Wall
> -Wno-uninitialized -Wdeclaration-after-statement -Werror'
> Votes:
> +1: djames, kfogel, lgo
>
> ---
> ---------------------------------------------------------------------
> r31148 | hwright | 2008-05-13 00:51:24 -0400 (Tue, 13 May 2008) | 12
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/
> swigutil_py.c
>
> Merge r31145 from trunk:
>
> * r31145
> Fix memory leaks in Python bindings.
> Justification:
> Memory leaks are bad.
> Notes:
> Depends on r31055 and r31066 (see above)
> Votes:
> +1: djames
> +0: epg
>
> ---
> ---------------------------------------------------------------------
> r31147 | hwright | 2008-05-13 00:50:16 -0400 (Tue, 13 May 2008) | 12
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/bindings/swig
> M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/
> swigutil_py.c
> M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/
> swigutil_py.h
> M /branches/1.5.x/subversion/bindings/swig/python/svn/wc.py
> M /branches/1.5.x/subversion/bindings/swig/python/tests/wc.py
> M /branches/1.5.x/subversion/bindings/swig/svn_wc.i
>
> Merge r31055, r31066 from trunk:
>
> * r31055 (subversion/bindings/swig), r31066
> Make svn_wc_diff_callbacks2_t work in Python (not a new interface,
> it was just broken for Python until r31055).
> Notes:
> 'svn merge -c 31055 ^/trunk/subversion/bindings/swig
> subversion/bindings/swig' cleanly merges the Python change.
> Votes:
> +1: epg
> +0: djames
>
> ---
> ---------------------------------------------------------------------
> r31114 | hwright | 2008-05-09 10:47:36 -0400 (Fri, 09 May 2008) | 7
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/libsvn_ra_serf/serf.c
>
> Merge r31107 from trunk:
>
> * r31107
> ra_serf: Fix API bug when fetched_rev is non-NULL and revision is
> invalid.
> Votes:
> +1: epg, jerenkrantz, kfogel
>
> ---
> ---------------------------------------------------------------------
> r31112 | cauchy | 2008-05-09 05:11:12 -0400 (Fri, 09 May 2008) | 4
> lines
> Changed paths:
> M /branches/1.5.x/subversion/po/zh_CN.po
>
> Simplified chinese translation update.
>
> * subversion/po/zh_CN.po: translate new backport strings.
>
> ---
> ---------------------------------------------------------------------
> r31074 | hwright | 2008-05-07 15:50:04 -0400 (Wed, 07 May 2008) | 7
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/libsvn_fs_base/fs.c
>
> Merge r31049 from trunk:
>
> * r31049
> s/lock-nodes/lock-tokens/ in a message.
> Votes:
> +1: arfrever, danielsh, hwright
>
> ---
> ---------------------------------------------------------------------
> r31073 | hwright | 2008-05-07 15:48:12 -0400 (Wed, 07 May 2008) | 7
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/include/svn_io.h
>
> Merge r31031 from trunk:
>
> * r31031
> Match svn_io_check_path's docstring to its implementation.
> Votes:
> +1: danielsh, arfrever, hwright
>
> ---
> ---------------------------------------------------------------------
> r31071 | hwright | 2008-05-07 15:44:08 -0400 (Wed, 07 May 2008) | 7
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/include/svn_error_codes.h
>
> Merge r31025 from trunk:
>
> * r31025
> Fix the SVN_ERR_AUTHN_CREDS_NOT_SAVED message.
> Votes:
> +1: arfrever, danielsh, hwright
>
> ---
> ---------------------------------------------------------------------
> r31065 | hwright | 2008-05-07 14:59:49 -0400 (Wed, 07 May 2008) | 10
> lines
> Changed paths:
> M /branches/1.5.x
> M /branches/1.5.x/CHANGES
> M /branches/1.5.x/COMMITTERS
> M /branches/1.5.x/STATUS
> M /branches/1.5.x/subversion/include/svn_ra.h
>
> Merge r31018 from trunk:
>
> * r31018
> Fix svn_ra_open3() doc string to say "@since 1.5" not "@since 1.6".
> Notes: This falls into hacking.html's no-vote-necessary category.
> Since I'm nominating it anyway, I'll record my vote, but I'm
> just filing it directly in the Approved section.
> Votes:
> +1: kfogel, danielsh
>
> ---
> ---------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 1.5.x, RC 6 and 1.5.0
Posted by Karl Fogel <kf...@red-bean.com>.
"Hyrum K. Wright" <hy...@mail.utexas.edu> writes:
> Hi all. We're almost halfway through the 4-week soak period for
> rc5. There have been several minor items merged to the 1.5.x branch,
> but overall, it looks like we're on track for release during the first
> week of June (*knock on wood*).
>
> [...]
> [http://subversion.tigris.org/hacking.html#release-stabilization]
> [...]
>
> RC 5 was released on May 5, so I plan on rolling and posting the next
> (and hopefully final!) release candidate on May 23-24. If all goes
> well, whatever makes it into that RC will be in 1.5.0-final; they will
> share the same magic revision. Fixes which don't make it into RC 6
> will be postponed to 1.5.1, which I anticipate releases 1-2 months
> after 1.5.0, pending demand.
Below are all the changes that have been ported to the 1.5.x branch
since 1.5.0-rc5 came out. I think a few of them are questionable for
inclusion in a one-week soak (that is, I've no complaints about the
changes themselves, I just think they might be a bit complex to be
released with undergoing full soak).
Of course, the fact that they were merged into 1.5.x is fine, no
objection there. The question is merely whether we make the final RC
(and thence 1.5.0 itself) off the tip of the 1.5.x branch or off the
1.5.0-rc5 tag. In the former case, we automatically get all the changes
below; in the latter case, we pick which changes we want to re-merge,
and anything below that doesn't get re-merged ends up in 1.5.1 anyway.
Just to be clear: I am *not* proposing that any soak times be extended.
The ship date should not be affected by any of this; I'm just asking
about what should be included in the release when it happens.
Search for "### THOUGHTS? ###" below to see which merges look to me like
they might want more than one week of soak. There should be only three:
r31218, r31186, r31185.
------------------------------------------------------------------------
r31218 | cmpilato | 2008-05-15 15:58:42 -0400 (Thu, 15 May 2008) | 16 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/libsvn_wc/merge.c
M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
Merge from trunk this change group:
### THOUGHTS? ###
* (r31159, r31179) or r31193 from 1.5.x-r31159-r31179 branch.
Fix "file not found" error when a merge target is a broken symbolic link.
Notes:
r31179 just makes sure the new test is skipped on Windows.
r31193 from 1.5.x-r31159-r31179 branch has r31159 and r31179
merged to it with a conflict resolution.
Votes:
+1: kfogel(r31159, r31179), kameshj, cmpilato (r31159, r31179)
Also:
* STATUS
Remove the group.
------------------------------------------------------------------------
r31216 | cmpilato | 2008-05-15 15:40:26 -0400 (Thu, 15 May 2008) | 16 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/include/svn_repos.h
M /branches/1.5.x/subversion/libsvn_repos/fs-wrap.c
M /branches/1.5.x/subversion/tests/cmdline/prop_tests.py
Merge this change group from trunk:
* r31138, r31141, r31157, r31209
Validate svn:date property values in libsvn_repos.
Notes:
r31141 is a docstring change.
r31157 marks the regression test XFail over DAV.
r31209 is a teeny typo (read: obvious) fix
Votes:
+1: danielsh, kfogel, cmpilato
Also:
* STATUS
Remove the group.
------------------------------------------------------------------------
r31186 | hwright | 2008-05-15 00:00:53 -0400 (Thu, 15 May 2008) | 14 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/libsvn_client/merge.c
M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
Merge r30746, r30747 from trunk:
### THOUGHTS? ###
* r30746, r30747
Fix a minor merge range notification header bug.
Notes:
r30747 is just cleanup of some cruft that snuck in with r30746,
thus adhering to my "every commit should need a follow-up" ethos.
r30746 contains, like, one tiny *real* change, then a whole bunch
of bogus indentation changes that were supposed to be part of
r30748. Probably best to not fix that indentation during
backport, in case we later backport r30748.
Votes:
+1: pburba, markphip, cmpilato
------------------------------------------------------------------------
r31185 | hwright | 2008-05-14 23:59:12 -0400 (Wed, 14 May 2008) | 8 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/libsvn_client/merge.c
M /branches/1.5.x/subversion/libsvn_client/mergeinfo.c
M /branches/1.5.x/subversion/libsvn_client/mergeinfo.h
M /branches/1.5.x/subversion/tests/cmdline/merge_tests.py
Merge r30949, r30962 from trunk:
### THOUGHTS? ###
* r30949, r30962
Fix issue #3188. Mergeinfo on switched targets/subtrees should elide
to repos.
Votes:
+1: pburba, markphip, cmpilato
------------------------------------------------------------------------
r31184 | hwright | 2008-05-14 23:57:18 -0400 (Wed, 14 May 2008) | 7 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/build.conf
M /branches/1.5.x/subversion/bindings/swig
Merge r31056 from trunk:
* r31056
Enable svn.diff in swig-py on Windows.
Votes:
+1: epg, arfrever, cmpilato
------------------------------------------------------------------------
r31183 | hwright | 2008-05-14 23:56:17 -0400 (Wed, 14 May 2008) | 10 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/include/svn_client.h
M /branches/1.5.x/subversion/libsvn_client/add.c
Merge r31131 from trunk:
* r31131
Restore compatibility of svn_client_add3()'s non-recursive behavior.
Notes:
This fixes an API incompatibility. But in practice it's a minor
problem, and could probably wait until 1.5.1 if necessary.
Votes:
+1: kfogel, epg, cmpilato
------------------------------------------------------------------------
r31182 | hwright | 2008-05-14 23:53:40 -0400 (Wed, 14 May 2008) | 7 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/libsvn_subr/path.c
M /branches/1.5.x/subversion/tests/libsvn_subr/path-test.c
Merge r31162 from trunk:
* r31162
Fix an OBOE in svn_path_splitext().
Votes:
+1: cmpilato, kfogel, danielsh
------------------------------------------------------------------------
r31164 | hwright | 2008-05-14 10:44:27 -0400 (Wed, 14 May 2008) | 9 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/contrib/client-side/svnmerge/svnmerge-migrate-history.py
M /branches/1.5.x/contrib/client-side/svnmerge/svnmerge-migrate-test.sh
M /branches/1.5.x/subversion/bindings/swig
Merge r31081, r31082, r31153, r31155 from trunk:
* r31081, r31082, r31153, r31155
Various improvements to svnmerge-migrate-history.py for dealing
with the kinds of problems caused by svnmerge.py's total ignorance
of object history.
Votes:
+1: cmpilato, dlr
------------------------------------------------------------------------
r31150 | hwright | 2008-05-13 00:54:47 -0400 (Tue, 13 May 2008) | 10 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/libsvn_ra_serf/log.c
Merge r31125 from trunk:
* r31125
Fix circular dependency between libsvn_ra and libsvn_ra_serf by teaching
libsvn_ra_serf to call svn_ra_serf__has_capability directly.
Justification:
Trivial fix. Necessary for cygwin build.
Votes:
+1: djames, lgo, danielsh
------------------------------------------------------------------------
r31149 | hwright | 2008-05-13 00:53:43 -0400 (Tue, 13 May 2008) | 10 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/libsvn_ra/compat.c
Merge r31126 from trunk:
* r31126
Use 'void *' to avoid compile warnings and eliminate casts.
Justification:
Trivial fix. Allows clean build with EXTRA_CFLAGS='-Wall
-Wno-uninitialized -Wdeclaration-after-statement -Werror'
Votes:
+1: djames, kfogel, lgo
------------------------------------------------------------------------
r31148 | hwright | 2008-05-13 00:51:24 -0400 (Tue, 13 May 2008) | 12 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
Merge r31145 from trunk:
* r31145
Fix memory leaks in Python bindings.
Justification:
Memory leaks are bad.
Notes:
Depends on r31055 and r31066 (see above)
Votes:
+1: djames
+0: epg
------------------------------------------------------------------------
r31147 | hwright | 2008-05-13 00:50:16 -0400 (Tue, 13 May 2008) | 12 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/bindings/swig
M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
M /branches/1.5.x/subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.h
M /branches/1.5.x/subversion/bindings/swig/python/svn/wc.py
M /branches/1.5.x/subversion/bindings/swig/python/tests/wc.py
M /branches/1.5.x/subversion/bindings/swig/svn_wc.i
Merge r31055, r31066 from trunk:
* r31055 (subversion/bindings/swig), r31066
Make svn_wc_diff_callbacks2_t work in Python (not a new interface,
it was just broken for Python until r31055).
Notes:
'svn merge -c 31055 ^/trunk/subversion/bindings/swig
subversion/bindings/swig' cleanly merges the Python change.
Votes:
+1: epg
+0: djames
------------------------------------------------------------------------
r31114 | hwright | 2008-05-09 10:47:36 -0400 (Fri, 09 May 2008) | 7 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/libsvn_ra_serf/serf.c
Merge r31107 from trunk:
* r31107
ra_serf: Fix API bug when fetched_rev is non-NULL and revision is invalid.
Votes:
+1: epg, jerenkrantz, kfogel
------------------------------------------------------------------------
r31112 | cauchy | 2008-05-09 05:11:12 -0400 (Fri, 09 May 2008) | 4 lines
Changed paths:
M /branches/1.5.x/subversion/po/zh_CN.po
Simplified chinese translation update.
* subversion/po/zh_CN.po: translate new backport strings.
------------------------------------------------------------------------
r31074 | hwright | 2008-05-07 15:50:04 -0400 (Wed, 07 May 2008) | 7 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/libsvn_fs_base/fs.c
Merge r31049 from trunk:
* r31049
s/lock-nodes/lock-tokens/ in a message.
Votes:
+1: arfrever, danielsh, hwright
------------------------------------------------------------------------
r31073 | hwright | 2008-05-07 15:48:12 -0400 (Wed, 07 May 2008) | 7 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/include/svn_io.h
Merge r31031 from trunk:
* r31031
Match svn_io_check_path's docstring to its implementation.
Votes:
+1: danielsh, arfrever, hwright
------------------------------------------------------------------------
r31071 | hwright | 2008-05-07 15:44:08 -0400 (Wed, 07 May 2008) | 7 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/include/svn_error_codes.h
Merge r31025 from trunk:
* r31025
Fix the SVN_ERR_AUTHN_CREDS_NOT_SAVED message.
Votes:
+1: arfrever, danielsh, hwright
------------------------------------------------------------------------
r31065 | hwright | 2008-05-07 14:59:49 -0400 (Wed, 07 May 2008) | 10 lines
Changed paths:
M /branches/1.5.x
M /branches/1.5.x/CHANGES
M /branches/1.5.x/COMMITTERS
M /branches/1.5.x/STATUS
M /branches/1.5.x/subversion/include/svn_ra.h
Merge r31018 from trunk:
* r31018
Fix svn_ra_open3() doc string to say "@since 1.5" not "@since 1.6".
Notes: This falls into hacking.html's no-vote-necessary category.
Since I'm nominating it anyway, I'll record my vote, but I'm
just filing it directly in the Approved section.
Votes:
+1: kfogel, danielsh
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org