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 2009/12/03 00:39:39 UTC
Subversion 1.6.7 on Dec. 16.
Hi all.
Gather up your holiday cheer, for I would like to propose a gift to the Subversion user community: Subversion 1.6.7. I know that folks have been busy with the ASF transition as of late, but our users have been busy finding bugs and STATUS is getting pretty full. As a result, I'd like to roll 1.6.7 on Wed., Dec. 16.
Remember, 'tis better to give than receive, so please give the gift of review time and votes to worthy items in STATUS.
Thanks,
-Hyrum
PS - Almost sent this to dev@s.t.o too, but figured the people that cared are already on dev@s.a.o. We really need to get rid of dev@s.t.o RSN.
Re: Subversion 1.6.7 on Dec. 16.
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Dec 17, 2009, at 9:10 PM, Branko Čibej wrote:
> Paul Burba wrote:
>> On Thu, Dec 17, 2009 at 5:53 PM, Branko Čibej <br...@xbc.nu> wrote:
>>
>>> Paul Burba wrote:
>>>
>>>> Regardless, I don't think this is a true regression, just a
>>>> new bug, and as such, not something that should hold up 1.6.7.
>>>>
>>>>
>>> Sorry, what? Subversion will suddenly error out where it previously did
>>> not. No matter /how/ that mergeinfo got into the repository, if we don't
>>> fix this before releasing 1.6.7, we'll likely get a whole bunch of error
>>> reports. Telling people that "it's not really a bug" isn't going to be
>>> very productive, given that it effectively stops them from using svn
>>> merge in this situation.
>>>
>>> Can you be sure that the circumstances that lead to this error are rare
>>> enough to address in 1.6.8?
>>>
>>
>> Hi Brane,
>>
>> I haven't explained this clearly, sorry. What has happened here is a
>> semi-complicated dance among several issues.
>>
>> Let me try to explain again:
>>
>> The reintegrate bug Hyrum encountered is not IMO a regression because
>> it *only* worked in 1.6.6 because another bug hid it.
>>
>> That other bug is issue #3547, which converted all the mergeinfo in
>> our repository from absolute paths to relative paths. The mergeinfo
>> APIs don't expect relative source paths in mergeinfo, so when it is
>> encountered the results are unpredictable (and usually wrong).
>>
>> In r890993 I made fixes so the relative pathed mergeinfo are
>> interpreted as absolute, and so the various svn_mergeinfo_* APIs don't
>> choke on the relative paths. This was nominated and backported to
>> 1.6.7.
>>
>> Along comes Hyrum, who, using the latest 1.6.7 with r890993 included,
>> tries to reintegrate a backport branch to 1.6.x. It fails, a bug!
>>
>> I try the same merge with 1.6.6 and it works. Regression right?
>> Actually no. It only worked because without the r890993 fix, the
>> relative pathed mergeinfo caused by issue #3547 was essentially
>> invisible to 1.6.6. It was just dumb luck that it actually
>> *prevented* an error. It most cases it would cause errors, as we
>> discussed here: http://svn.haxx.se/dev/archive-2009-12/0222.shtml.
>>
>> ~~~~~
>>
>> This may all be moot because I fixed the bug in r892085 and nominated
>> this for backport to 1.6.7. I also nominated a test which reproduces
>> the bug Hyrum found. This test fails across the board on trunk,
>> 1.6.x, and 1.6.6 without the the r892085 fix in place.
>>
>> I hope that makes things clearer. If not let me know or ping me in
>> IRC tomorrow.
>>
>> Thanks,
>>
>
> Oh, I think I see. So the no-leading-slash in svnadmin load caused some
> merge info to be ignored, and when you made the merge logic more
> flexible WRT the svn:mergeinfo format, this new bug (not ignoring
> irrelevant revisions in svn:mergeinfo?) raised its head.
>
> OK ... I gather from other posts that we don't really know when this
> invalid mergeinfo got into the repository, but we can assume that it was
> caused by another bug (possibly even in 1.5) which has hopefully since
> been fixed.
Paul may be able to correct me here, but I think the bug which caused the invalid mergeinfo was only fixed recently, and has been merged to 1.6.x for the 1.6.7 release.
> The question remains, though, can this situation really only be
> reproduced with the complex chain of events we saw here? In other words,
> if we had not migrated the repository to svn.apache.org and still had
> invalid mergeinfo in the repository -- would not the merge have failed
> even without your recent change in mergeinfo handling?
>
> I'm trying to wrap my head around this because it doesn't seem
> reasonable that irrelevant revisions in mergeinfo would only cause
> problems in combination with your changes. Because if that's the case,
> then there's either a bug in your "flexibilification" of mergeinfo
> paths, or there's a more fundamental bug in mergeinfo processing ...
> sorry if all this isn't crystal clear, but this is a bit of a muddle. :)
>
> To illustrate what I'm getting at ... say a user has a file ^/foo in her
> repository that was created in r10. He creates a branch, "svn cp ^/foo
> ^/bar" and creates r11. in r12, she modifies ^/foo, and in r13 merges
> the change to ^/bar. One would expect ^/bar's mergeinfo to be:
> /foo:10-12, yes? Now let's imagine for a moment that for some reason
> this was all done with a broken client/server combo, and the actual
> mergeinfo is: /foo:2-12. Would Hyrum's reintegrate merge fail in the
> same way in this case? If not, why not?
Reguardless of how frequently this problem exhibits itself, Paul claims* to have fixed it in r892085, and should that prove true, the problem of frequency is moot.
FWIW, I haven't yet rolled the 1.6.7 tarball, so we can straighten this all out tomorrow and possibly roll then.
-Hyrum
* - Not that I doubt Paul's ability to fix this bug, I just haven't seen any review on it yet (and haven't done so myself).
Re: Subversion 1.6.7 on Dec. 16.
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Dec 18, 2009 at 5:01 PM, Branko Čibej <br...@xbc.nu> wrote:
> Philip Martin wrote:
>> Paul Burba <pt...@gmail.com> writes:
>>
>>> So shouldn't the mergeinfo on this path in the old repos,
>>>
>>>
>>>> svn pg svn:mergeinfo https://svn.collab.net/repos/svn/branches/1.6.x-r40452/CHANGES@40513
>>>>
>>> ...
>>> /trunk/CHANGES:2-1281,35888-40052,40088,40152,40451-40452
>>>
>>> differ from from the new repos,
>>>
>>>
>>>> svn pg svn:mergeinfo https://svn.apache.org/repos/asf/subversion/branches/1.6.x-r40452/CHANGES@880587
>>>>
>>> ...
>>> subversion/trunk/CHANGES:836421-837700,872307-876471,876507,876571,880525-880526
>>>
>>> only by the offset? The fact that it doesn't is troubling, to say the
>>> least, and might also explain why you got different results with the
>>> old repos.
>>>
>>
>> Yes, I think you are right and I don't understand it.
>>
>
> I find this quite disturbing ... although it has no direct bearing on
> whether the merge bug is a new bug or not, we should still figure out
> how this mergeinfo got out of sync.
>
> (BTW, all the above pretty much convinced me that this merge failure
> indeed is not a new bug.)
>
> -- Brane
I agree and will be trying to figure out what happened Monday.
Paul
Re: Subversion 1.6.7 on Dec. 16.
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> So shouldn't the mergeinfo on this path in the old repos,
>>
>>
>>> svn pg svn:mergeinfo https://svn.collab.net/repos/svn/branches/1.6.x-r40452/CHANGES@40513
>>>
>> ...
>> /trunk/CHANGES:2-1281,35888-40052,40088,40152,40451-40452
>>
>> differ from from the new repos,
>>
>>
>>> svn pg svn:mergeinfo https://svn.apache.org/repos/asf/subversion/branches/1.6.x-r40452/CHANGES@880587
>>>
>> ...
>> subversion/trunk/CHANGES:836421-837700,872307-876471,876507,876571,880525-880526
>>
>> only by the offset? The fact that it doesn't is troubling, to say the
>> least, and might also explain why you got different results with the
>> old repos.
>>
>
> Yes, I think you are right and I don't understand it.
>
I find this quite disturbing ... although it has no direct bearing on
whether the merge bug is a new bug or not, we should still figure out
how this mergeinfo got out of sync.
(BTW, all the above pretty much convinced me that this merge failure
indeed is not a new bug.)
-- Brane
Re: Subversion 1.6.7 on Dec. 16.
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> That does fail on 1.6.6, better replicating the error Hyrum
> encountered, but it fails simply because the self-referential
> mergeinfo is never considered. As I was saying in IRC this morning
> this is a case where one bug (rel pathed mergeinfo not handled
> correctly by svn_mergeinfo_* APIs) allows us to avoid a different bug
> (reintegrate code doesn't tolerate self-referential mergeinfo in some
> cases). In most cases the first bug is going to cause problems, not
> solve them.
OK.
>> svn merge --reintegrate ^/subversion/branches/1.6.x-r40452@891008
>>
>> the 1.6.x client gives an error:
>>
>> svn: '/repos/asf/!svn/bc/875961/subversion/branches/1.6.x' path not found
>>
>> and the 1.6.4 client doesn't:
>>
>> --- Merging differences between repository URLs into '../src-1.6':
>> G ../src-1.6/CHANGES
>> G ../src-1.6
>
> That is interesting about 1.6.4, I'll have to look into what changed
> from 1.6.4 to 1.6.6 that would account for this.
1.6.x is the prospective 1.6.7 with the r40452 branch merged. I
expect 1.6.4 (that's my system version) and 1.6.6 to be the same.
>> As I stated in a mail yesterday, the bug on the Subversion repository
>> is triggered by the mergeinfo paths not having a leading '/' in
>> addition to the other bogus data. It doesn't happen with the old
>> collab repository where the paths do have a leading '/'.
>
> Regarding what you found with the old repos: The revision offset
> between our old repos revs and the ASF repos is 840074 right?
>
> So shouldn't the mergeinfo on this path in the old repos,
>
>>svn pg svn:mergeinfo https://svn.collab.net/repos/svn/branches/1.6.x-r40452/CHANGES@40513
> ...
> /trunk/CHANGES:2-1281,35888-40052,40088,40152,40451-40452
>
> differ from from the new repos,
>
>>svn pg svn:mergeinfo https://svn.apache.org/repos/asf/subversion/branches/1.6.x-r40452/CHANGES@880587
> ...
> subversion/trunk/CHANGES:836421-837700,872307-876471,876507,876571,880525-880526
>
> only by the offset? The fact that it doesn't is troubling, to say the
> least, and might also explain why you got different results with the
> old repos.
Yes, I think you are right and I don't understand it.
--
Philip
Re: Subversion 1.6.7 on Dec. 16.
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Dec 18, 2009 at 11:41 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> "This may all be moot because I fixed the bug in r892085 and nominated
>> this for backport to 1.6.7. I also nominated a test which reproduces
>> the bug Hyrum found. This test fails across the board on trunk,
>> 1.6.x, and 1.6.6 without the the r892085 fix in place."
>
> I don't think your test case is exactly the same bug since your
> testcase affects both 1.6.x and 1.6.6 while the bug on the Subversion
> repository doesn't affect 1.6.6. Merging into the 1.6.x.source:
Hi Philip,
Right, it's not exactly the same because it is only testing the
underlying reintegrate bug, not anything to do with the *separate* rel
pathed mergeinfo handling bug which would obscure the first bug. If
we want the test to conflate the two issues, we could apply this
patch:
[[[
Index: subversion/tests/cmdline/merge_tests.py
===================================================================
--- subversion/tests/cmdline/merge_tests.py (revision 892317)
+++ subversion/tests/cmdline/merge_tests.py (working copy)
@@ -17194,10 +17194,14 @@
# /A:3 describes A2's natural history, a.k.a. it's implicit mergeinfo, so
# it is self-referential. Same for /A/B:4 and A2/B. Normally this is
# redundant but not harmful.
+ #
+ # Also, make this self-referential mergeinfo use relative merge source
+ # paths to replicate the type of bogus mergeinfo that issue #3547 might
+ # let into the repository.
svntest.actions.run_and_verify_svn(None, None, [],
- 'ps', 'svn:mergeinfo', '/A:3', A2_path)
+ 'ps', 'svn:mergeinfo', 'A:3', A2_path)
svntest.actions.run_and_verify_svn(None, None, [],
- 'ps', 'svn:mergeinfo', '/A/B:4',
A2_B_path)
+ 'ps', 'svn:mergeinfo', 'A/B:4', A2_B_path)
svntest.actions.run_and_verify_svn(
None, None, [], 'ci', '-m',
'copy A to A2 and set some self-referential mergeinfo on the latter.',
@@ -17246,8 +17250,8 @@
})
expected_status.tweak(wc_rev=8)
expected_disk = wc.State('', {
- '' : Item(props={SVN_PROP_MERGEINFO : '/A:3\n/A2.1:7-8'}),
- 'B' : Item(props={SVN_PROP_MERGEINFO : '/A/B:4\n/A2.1/B:7-8'}),
+ '' : Item(props={SVN_PROP_MERGEINFO : '/A2.1:7-8\nA:3'}),
+ 'B' : Item(props={SVN_PROP_MERGEINFO : '/A2.1/B:7-8\nA/B:4'}),
'mu' : Item("New A2.1 stuff"),
'B/E' : Item(),
'B/E/alpha' : Item("This is the file 'alpha'.\n"),
]]]
That does fail on 1.6.6, better replicating the error Hyrum
encountered, but it fails simply because the self-referential
mergeinfo is never considered. As I was saying in IRC this morning
this is a case where one bug (rel pathed mergeinfo not handled
correctly by svn_mergeinfo_* APIs) allows us to avoid a different bug
(reintegrate code doesn't tolerate self-referential mergeinfo in some
cases). In most cases the first bug is going to cause problems, not
solve them.
> svn merge --reintegrate ^/subversion/branches/1.6.x-r40452@891008
>
> the 1.6.x client gives an error:
>
> svn: '/repos/asf/!svn/bc/875961/subversion/branches/1.6.x' path not found
>
> and the 1.6.4 client doesn't:
>
> --- Merging differences between repository URLs into '../src-1.6':
> G ../src-1.6/CHANGES
> G ../src-1.6
That is interesting about 1.6.4, I'll have to look into what changed
from 1.6.4 to 1.6.6 that would account for this.
> As I stated in a mail yesterday, the bug on the Subversion repository
> is triggered by the mergeinfo paths not having a leading '/' in
> addition to the other bogus data. It doesn't happen with the old
> collab repository where the paths do have a leading '/'.
Regarding what you found with the old repos: The revision offset
between our old repos revs and the ASF repos is 840074 right?
So shouldn't the mergeinfo on this path in the old repos,
>svn pg svn:mergeinfo https://svn.collab.net/repos/svn/branches/1.6.x-r40452/CHANGES@40513
...
/trunk/CHANGES:2-1281,35888-40052,40088,40152,40451-40452
differ from from the new repos,
>svn pg svn:mergeinfo https://svn.apache.org/repos/asf/subversion/branches/1.6.x-r40452/CHANGES@880587
...
subversion/trunk/CHANGES:836421-837700,872307-876471,876507,876571,880525-880526
only by the offset? The fact that it doesn't is troubling, to say the
least, and might also explain why you got different results with the
old repos.
> Merging r892085 to 1.6.x produces a client that does the merge, so I
> suppose we could simply approve r892085 and then there is definitely
> no regression.
That is probably the best option at this point.
Paul
Re: Subversion 1.6.7 on Dec. 16.
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> "This may all be moot because I fixed the bug in r892085 and nominated
> this for backport to 1.6.7. I also nominated a test which reproduces
> the bug Hyrum found. This test fails across the board on trunk,
> 1.6.x, and 1.6.6 without the the r892085 fix in place."
I don't think your test case is exactly the same bug since your
testcase affects both 1.6.x and 1.6.6 while the bug on the Subversion
repository doesn't affect 1.6.6. Merging into the 1.6.x.source:
svn merge --reintegrate ^/subversion/branches/1.6.x-r40452@891008
the 1.6.x client gives an error:
svn: '/repos/asf/!svn/bc/875961/subversion/branches/1.6.x' path not found
and the 1.6.4 client doesn't:
--- Merging differences between repository URLs into '../src-1.6':
G ../src-1.6/CHANGES
G ../src-1.6
As I stated in a mail yesterday, the bug on the Subversion repository
is triggered by the mergeinfo paths not having a leading '/' in
addition to the other bogus data. It doesn't happen with the old
collab repository where the paths do have a leading '/'.
Merging r892085 to 1.6.x produces a client that does the merge, so I
suppose we could simply approve r892085 and then there is definitely
no regression.
--
Philip
Re: Subversion 1.6.7 on Dec. 16.
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Dec 17, 2009 at 10:10 PM, Branko Čibej <br...@xbc.nu> wrote:
> Paul Burba wrote:
>> On Thu, Dec 17, 2009 at 5:53 PM, Branko Čibej <br...@xbc.nu> wrote:
>>
>>> Paul Burba wrote:
>>>
>>>> Regardless, I don't think this is a true regression, just a
>>>> new bug, and as such, not something that should hold up 1.6.7.
>>>>
>>>>
>>> Sorry, what? Subversion will suddenly error out where it previously did
>>> not. No matter /how/ that mergeinfo got into the repository, if we don't
>>> fix this before releasing 1.6.7, we'll likely get a whole bunch of error
>>> reports. Telling people that "it's not really a bug" isn't going to be
>>> very productive, given that it effectively stops them from using svn
>>> merge in this situation.
>>>
>>> Can you be sure that the circumstances that lead to this error are rare
>>> enough to address in 1.6.8?
>>>
>>
>> Hi Brane,
>>
>> I haven't explained this clearly, sorry. What has happened here is a
>> semi-complicated dance among several issues.
>>
>> Let me try to explain again:
>>
>> The reintegrate bug Hyrum encountered is not IMO a regression because
>> it *only* worked in 1.6.6 because another bug hid it.
>>
>> That other bug is issue #3547, which converted all the mergeinfo in
>> our repository from absolute paths to relative paths. The mergeinfo
>> APIs don't expect relative source paths in mergeinfo, so when it is
>> encountered the results are unpredictable (and usually wrong).
>>
>> In r890993 I made fixes so the relative pathed mergeinfo are
>> interpreted as absolute, and so the various svn_mergeinfo_* APIs don't
>> choke on the relative paths. This was nominated and backported to
>> 1.6.7.
>>
>> Along comes Hyrum, who, using the latest 1.6.7 with r890993 included,
>> tries to reintegrate a backport branch to 1.6.x. It fails, a bug!
>>
>> I try the same merge with 1.6.6 and it works. Regression right?
>> Actually no. It only worked because without the r890993 fix, the
>> relative pathed mergeinfo caused by issue #3547 was essentially
>> invisible to 1.6.6. It was just dumb luck that it actually
>> *prevented* an error. It most cases it would cause errors, as we
>> discussed here: http://svn.haxx.se/dev/archive-2009-12/0222.shtml.
>>
>> ~~~~~
>>
>> This may all be moot because I fixed the bug in r892085 and nominated
>> this for backport to 1.6.7. I also nominated a test which reproduces
>> the bug Hyrum found. This test fails across the board on trunk,
>> 1.6.x, and 1.6.6 without the the r892085 fix in place.
>>
>> I hope that makes things clearer. If not let me know or ping me in
>> IRC tomorrow.
>>
>> Thanks,
>>
>
> Oh, I think I see. So the no-leading-slash in svnadmin load caused some
> merge info to be ignored, and when you made the merge logic more
> flexible WRT the svn:mergeinfo format, this new bug (not ignoring
> irrelevant revisions in svn:mergeinfo?) raised its head.
It raised it's head for us yes, but it is not new, it's been there for
some time. I'd go as far to say that there are no new bugs here, if
by "new" we mean a regression against 1.6.6.
> OK ... I gather from other posts that we don't really know when this
> invalid mergeinfo got into the repository, but we can assume that it was
> caused by another bug (possibly even in 1.5) which has hopefully since
> been fixed.
Right, I'm not sure how the self-referential mergeinfo got in, and I
can't reproduce it. Waiting on Stephen Butler to maybe shed some
light on what version he was using.
> The question remains, though, can this situation really only be
> reproduced with the complex chain of events we saw here? In other words,
> if we had not migrated the repository to svn.apache.org and still had
> invalid mergeinfo in the repository -- would not the merge have failed
> even without your recent change in mergeinfo handling?
Right, it would have failed regardless of my change to handle relative
pathed mergeinfo. The new merge_tests.py 141 "source has target's
history as explicit mergeinfo" demonstrates the underlying reintegrate
bug. Run that test with 1.6.6 and it still fails.
> I'm trying to wrap my head around this because it doesn't seem
> reasonable that irrelevant revisions in mergeinfo would only cause
> problems in combination with your changes.
I'm not entirely sure which changes you are referring to here(?).
> Because if that's the case,
> then there's either a bug in your "flexibilification" of mergeinfo
> paths, or there's a more fundamental bug in mergeinfo processing ...
> sorry if all this isn't crystal clear, but this is a bit of a muddle. :)
Absolutely there is another bug, the one I mentioned here:
"This may all be moot because I fixed the bug in r892085 and nominated
this for backport to 1.6.7. I also nominated a test which reproduces
the bug Hyrum found. This test fails across the board on trunk,
1.6.x, and 1.6.6 without the the r892085 fix in place."
> To illustrate what I'm getting at ... say a user has a file ^/foo
Assuming you mean ^/foo is a directory here.
> in her
> repository that was created in r10. He creates a branch, "svn cp ^/foo
> ^/bar" and creates r11. in r12, she modifies ^/foo, and in r13 merges
> the change to ^/bar. One would expect ^/bar's mergeinfo to be:
> /foo:10-12,
Assuming you didn't specify any revisions and merged everything available, i.e.
svn merge ^/foo bar-wc
The mergeinfo should be
/foo:11-12
But that is a minor point.
> yes? Now let's imagine for a moment that for some reason
> this was all done with a broken client/server combo, and the actual
> mergeinfo is: /foo:2-12. Would Hyrum's reintegrate merge fail in the
> same way in this case? If not, why not?
No, that would work. The bug I fixed in r892085 only comes into play
when reintegrating branches that were never merged to earlier from the
source (like Hyrum was doing).
Paul
Re: Subversion 1.6.7 on Dec. 16.
Posted by Branko Čibej <br...@xbc.nu>.
Paul Burba wrote:
> On Thu, Dec 17, 2009 at 5:53 PM, Branko Čibej <br...@xbc.nu> wrote:
>
>> Paul Burba wrote:
>>
>>> Regardless, I don't think this is a true regression, just a
>>> new bug, and as such, not something that should hold up 1.6.7.
>>>
>>>
>> Sorry, what? Subversion will suddenly error out where it previously did
>> not. No matter /how/ that mergeinfo got into the repository, if we don't
>> fix this before releasing 1.6.7, we'll likely get a whole bunch of error
>> reports. Telling people that "it's not really a bug" isn't going to be
>> very productive, given that it effectively stops them from using svn
>> merge in this situation.
>>
>> Can you be sure that the circumstances that lead to this error are rare
>> enough to address in 1.6.8?
>>
>
> Hi Brane,
>
> I haven't explained this clearly, sorry. What has happened here is a
> semi-complicated dance among several issues.
>
> Let me try to explain again:
>
> The reintegrate bug Hyrum encountered is not IMO a regression because
> it *only* worked in 1.6.6 because another bug hid it.
>
> That other bug is issue #3547, which converted all the mergeinfo in
> our repository from absolute paths to relative paths. The mergeinfo
> APIs don't expect relative source paths in mergeinfo, so when it is
> encountered the results are unpredictable (and usually wrong).
>
> In r890993 I made fixes so the relative pathed mergeinfo are
> interpreted as absolute, and so the various svn_mergeinfo_* APIs don't
> choke on the relative paths. This was nominated and backported to
> 1.6.7.
>
> Along comes Hyrum, who, using the latest 1.6.7 with r890993 included,
> tries to reintegrate a backport branch to 1.6.x. It fails, a bug!
>
> I try the same merge with 1.6.6 and it works. Regression right?
> Actually no. It only worked because without the r890993 fix, the
> relative pathed mergeinfo caused by issue #3547 was essentially
> invisible to 1.6.6. It was just dumb luck that it actually
> *prevented* an error. It most cases it would cause errors, as we
> discussed here: http://svn.haxx.se/dev/archive-2009-12/0222.shtml.
>
> ~~~~~
>
> This may all be moot because I fixed the bug in r892085 and nominated
> this for backport to 1.6.7. I also nominated a test which reproduces
> the bug Hyrum found. This test fails across the board on trunk,
> 1.6.x, and 1.6.6 without the the r892085 fix in place.
>
> I hope that makes things clearer. If not let me know or ping me in
> IRC tomorrow.
>
> Thanks,
>
Oh, I think I see. So the no-leading-slash in svnadmin load caused some
merge info to be ignored, and when you made the merge logic more
flexible WRT the svn:mergeinfo format, this new bug (not ignoring
irrelevant revisions in svn:mergeinfo?) raised its head.
OK ... I gather from other posts that we don't really know when this
invalid mergeinfo got into the repository, but we can assume that it was
caused by another bug (possibly even in 1.5) which has hopefully since
been fixed.
The question remains, though, can this situation really only be
reproduced with the complex chain of events we saw here? In other words,
if we had not migrated the repository to svn.apache.org and still had
invalid mergeinfo in the repository -- would not the merge have failed
even without your recent change in mergeinfo handling?
I'm trying to wrap my head around this because it doesn't seem
reasonable that irrelevant revisions in mergeinfo would only cause
problems in combination with your changes. Because if that's the case,
then there's either a bug in your "flexibilification" of mergeinfo
paths, or there's a more fundamental bug in mergeinfo processing ...
sorry if all this isn't crystal clear, but this is a bit of a muddle. :)
To illustrate what I'm getting at ... say a user has a file ^/foo in her
repository that was created in r10. He creates a branch, "svn cp ^/foo
^/bar" and creates r11. in r12, she modifies ^/foo, and in r13 merges
the change to ^/bar. One would expect ^/bar's mergeinfo to be:
/foo:10-12, yes? Now let's imagine for a moment that for some reason
this was all done with a broken client/server combo, and the actual
mergeinfo is: /foo:2-12. Would Hyrum's reintegrate merge fail in the
same way in this case? If not, why not?
-- Brane
Re: Subversion 1.6.7 on Dec. 16.
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Dec 17, 2009 at 5:53 PM, Branko Čibej <br...@xbc.nu> wrote:
> Paul Burba wrote:
>> Regardless, I don't think this is a true regression, just a
>> new bug, and as such, not something that should hold up 1.6.7.
>>
>
> Sorry, what? Subversion will suddenly error out where it previously did
> not. No matter /how/ that mergeinfo got into the repository, if we don't
> fix this before releasing 1.6.7, we'll likely get a whole bunch of error
> reports. Telling people that "it's not really a bug" isn't going to be
> very productive, given that it effectively stops them from using svn
> merge in this situation.
>
> Can you be sure that the circumstances that lead to this error are rare
> enough to address in 1.6.8?
Hi Brane,
I haven't explained this clearly, sorry. What has happened here is a
semi-complicated dance among several issues.
Let me try to explain again:
The reintegrate bug Hyrum encountered is not IMO a regression because
it *only* worked in 1.6.6 because another bug hid it.
That other bug is issue #3547, which converted all the mergeinfo in
our repository from absolute paths to relative paths. The mergeinfo
APIs don't expect relative source paths in mergeinfo, so when it is
encountered the results are unpredictable (and usually wrong).
In r890993 I made fixes so the relative pathed mergeinfo are
interpreted as absolute, and so the various svn_mergeinfo_* APIs don't
choke on the relative paths. This was nominated and backported to
1.6.7.
Along comes Hyrum, who, using the latest 1.6.7 with r890993 included,
tries to reintegrate a backport branch to 1.6.x. It fails, a bug!
I try the same merge with 1.6.6 and it works. Regression right?
Actually no. It only worked because without the r890993 fix, the
relative pathed mergeinfo caused by issue #3547 was essentially
invisible to 1.6.6. It was just dumb luck that it actually
*prevented* an error. It most cases it would cause errors, as we
discussed here: http://svn.haxx.se/dev/archive-2009-12/0222.shtml.
~~~~~
This may all be moot because I fixed the bug in r892085 and nominated
this for backport to 1.6.7. I also nominated a test which reproduces
the bug Hyrum found. This test fails across the board on trunk,
1.6.x, and 1.6.6 without the the r892085 fix in place.
I hope that makes things clearer. If not let me know or ping me in
IRC tomorrow.
Thanks,
Paul
Re: Subversion 1.6.7 on Dec. 16.
Posted by Branko Čibej <br...@xbc.nu>.
Paul Burba wrote:
> Regardless, I don't think this is a true regression, just a
> new bug, and as such, not something that should hold up 1.6.7.
>
Sorry, what? Subversion will suddenly error out where it previously did
not. No matter /how/ that mergeinfo got into the repository, if we don't
fix this before releasing 1.6.7, we'll likely get a whole bunch of error
reports. Telling people that "it's not really a bug" isn't going to be
very productive, given that it effectively stops them from using svn
merge in this situation.
Can you be sure that the circumstances that lead to this error are rare
enough to address in 1.6.8?
-- Brane
Re: Subversion 1.6.7 on Dec. 16.
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
The end result of all this discussion appears to be that 1.6.7 can roll as-is, so I will proceed to do so sometime in the next 24 hours.
-Hyrum
On Dec 17, 2009, at 9:26 AM, Philip Martin wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> Now that we correctly interpret mergeinfo with relative paths
>> (r890993) we actually *consider* mergeinfo with relative source paths.
>> Where Hyrum ran into a problem there was some very dubious mergeinfo
>> on CHANGES in both the reintegrate source and the target:
>>
>> On the target:
>>
>> 1.6.6>svn pg svn:mergeinfo ^^/subversion/branches/1.6.x/CHANGES@891108
> [...]
>> /subversion/trunk/CHANGES:836421-837700,875962-876471,876507,876571,880274-880275,880474,880525-880526,881905,884842,886164,886197,888979,889081,889840
>
> I have a an old copy of the r40513 pre-apache repository. It has:
>
> $ svn pg svn:mergeinfo http://localhost:8080/smb/branches/1.6.x-r40452/CHANGES | grep trunk
> /trunk/CHANGES:2-1281,35888-40052,40088,40152,40451-40452
>
>
>> On the source:
>>
>> 1.6.6>svn pg svn:mergeinfo ^^/subversion/branches/1.6.x-r40452/CHANGES@891008
> [...]
>> subversion/trunk/CHANGES:836421-837700,872307-876471,876507,876571,880525-880526
>
> $ svn pg svn:mergeinfo http://localhost:8080/smb/branches/1.6.x/CHANGES | grep trunk
> /trunk/CHANGES:2-1281,35888-40052,40088,40152
>
>> What you want to notice here is the mergeinfo
>> 'subverison/trunk/CHANGES:836421-837700', this actually predates the
>> creation of subversion/trunk/CHANGES, which was in r841356. How this
>> got into our repos in the first place is a good question, and one I am
>> trying to track down, see
>> http://mail-archives.apache.org/mod_mbox/subversion-dev/200912.mbox/browser,
>> but I don't think it should impact the decision to roll 1.6.7. There
>> may be another bug here, but since the offending mergeinfo was created
>> a month prior to 1.6.6 we are not dealing with a regression.
>
> And the problem existed the old repository: 2-1281.
>
>> Anyway, onto the "regression". A 1.6.6 client, not realizing that the
>> merge source "subversion/trunk/CHANGES" == "/subversion/trunk/CHANGES"
>> simply ignores the relative pathed mergeinfo. But with r890993 the
>> relative path is interpreted as an absolute path and so the
>> reintegrate code thinks that we have done some merge(s) from trunk to
>> the 1.6.x-r889840 branch, but the code doesn't handle the case where
>> that mergeinfo describes non-existent path-revs, ultimately producing
>> the error that Hyrum saw.
>
> If I reintegrate using
>
> $ svn merge --reintegrate ^/branches/1.6.x-r40452 srcx
>
> then both r890992 and r890993 give
>
> --- Merging differences between repository URLs into 'srcx':
> U srcx/subversion/tests/cmdline/resolved_tests.py
> U srcx/subversion/libsvn_wc/adm_ops.c
> U srcx/CHANGES
> U srcx
>
> So the presence of the dodgy revisions doesn't seem to be a problem
> and the new 1.6.x code will work as well as 1.6.6. It's only when the
> dodgy revisions are combined with the dodgy paths that there is a
> problem.
>
> --
> Philip
Re: Subversion 1.6.7 on Dec. 16.
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> Now that we correctly interpret mergeinfo with relative paths
> (r890993) we actually *consider* mergeinfo with relative source paths.
> Where Hyrum ran into a problem there was some very dubious mergeinfo
> on CHANGES in both the reintegrate source and the target:
>
> On the target:
>
> 1.6.6>svn pg svn:mergeinfo ^^/subversion/branches/1.6.x/CHANGES@891108
[...]
> /subversion/trunk/CHANGES:836421-837700,875962-876471,876507,876571,880274-880275,880474,880525-880526,881905,884842,886164,886197,888979,889081,889840
I have a an old copy of the r40513 pre-apache repository. It has:
$ svn pg svn:mergeinfo http://localhost:8080/smb/branches/1.6.x-r40452/CHANGES | grep trunk
/trunk/CHANGES:2-1281,35888-40052,40088,40152,40451-40452
> On the source:
>
> 1.6.6>svn pg svn:mergeinfo ^^/subversion/branches/1.6.x-r40452/CHANGES@891008
[...]
> subversion/trunk/CHANGES:836421-837700,872307-876471,876507,876571,880525-880526
$ svn pg svn:mergeinfo http://localhost:8080/smb/branches/1.6.x/CHANGES | grep trunk
/trunk/CHANGES:2-1281,35888-40052,40088,40152
> What you want to notice here is the mergeinfo
> 'subverison/trunk/CHANGES:836421-837700', this actually predates the
> creation of subversion/trunk/CHANGES, which was in r841356. How this
> got into our repos in the first place is a good question, and one I am
> trying to track down, see
> http://mail-archives.apache.org/mod_mbox/subversion-dev/200912.mbox/browser,
> but I don't think it should impact the decision to roll 1.6.7. There
> may be another bug here, but since the offending mergeinfo was created
> a month prior to 1.6.6 we are not dealing with a regression.
And the problem existed the old repository: 2-1281.
> Anyway, onto the "regression". A 1.6.6 client, not realizing that the
> merge source "subversion/trunk/CHANGES" == "/subversion/trunk/CHANGES"
> simply ignores the relative pathed mergeinfo. But with r890993 the
> relative path is interpreted as an absolute path and so the
> reintegrate code thinks that we have done some merge(s) from trunk to
> the 1.6.x-r889840 branch, but the code doesn't handle the case where
> that mergeinfo describes non-existent path-revs, ultimately producing
> the error that Hyrum saw.
If I reintegrate using
$ svn merge --reintegrate ^/branches/1.6.x-r40452 srcx
then both r890992 and r890993 give
--- Merging differences between repository URLs into 'srcx':
U srcx/subversion/tests/cmdline/resolved_tests.py
U srcx/subversion/libsvn_wc/adm_ops.c
U srcx/CHANGES
U srcx
So the presence of the dodgy revisions doesn't seem to be a problem
and the new 1.6.x code will work as well as 1.6.6. It's only when the
dodgy revisions are combined with the dodgy paths that there is a
problem.
--
Philip
Re: Subversion 1.6.7 on Dec. 16.
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Dec 17, 2009 at 8:48 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Paul Burba <pt...@gmail.com> writes:
>
>> Hyrum ran into a problem when reintegrating a branch back to 1.6.x
>> using the (at the time) latest 1.6.x client. Here is the merge he did
>> (though this has a pegged source because the backport branch was
>> deleted):
>>
>> 1.6.x.>svn merge ^^/subversion/branches/1.6.x-r40452@891008 . --reintegrate
>> ..\..\..\subversion\libsvn_ra_neon\util.c:546: (apr_err=160013)
>> svn: '/repos/asf/!svn/bc/875961/subversion/branches/1.6.x' path not found
>>
>> Unfortunately this reintegrate works with 1.6.6, so we have a regression.
>>
>> I've traced the cause to r890993 (Reintegrate the 1.6.x-r889840
>> branch) which was my attempt to address the myriad of problems caused
>> by issue #3547 http://subversion.tigris.org/issues/show_bug.cgi?id=3547,
>> which converted all the mergeinfo in our repository from absolute to
>> relative merge source paths when we loaded it into the ASF repos. I
>> haven't been able to fix the reintegrate problem Hyrum encountered,
>> heck it's not exactly clear to me what is going wrong, but I'm working
>> on it.
>
> As one who voted for r890993 I wouldn't object if it was reverted and
> we released without it. It is a change in behaviour, so I guess that
> counts as a regression, but what seems to be happening is that the old
> code ignores some of the incorrect mergeinfo because the paths don't
> match. It's possible that the new behaviour, getting an error when
> the mergeinfo is broken, is better.
Philip,
Short Story: I agree, calling this a regression was a bit premature.
Long Story:
Now that we correctly interpret mergeinfo with relative paths
(r890993) we actually *consider* mergeinfo with relative source paths.
Where Hyrum ran into a problem there was some very dubious mergeinfo
on CHANGES in both the reintegrate source and the target:
On the target:
1.6.6>svn pg svn:mergeinfo ^^/subversion/branches/1.6.x/CHANGES@891108
/subversion/branches/1.5.x-r30215/CHANGES:866657
/subversion/branches/1.6.x-UNC-paths/CHANGES:872816-872890
/subversion/branches/1.6.x-dirent-basename/CHANGES:872475-872607
/subversion/branches/1.6.x-future-proof/CHANGES:880259-884209
/subversion/branches/1.6.x-issue3443/CHANGES:874942-875825
/subversion/branches/1.6.x-issue3519/CHANGES:880376-889934
/subversion/branches/1.6.x-no-svn_uri/CHANGES:872705-872760
/subversion/branches/1.6.x-r36178/CHANGES:874221-874229
/subversion/branches/1.6.x-r36252/CHANGES:872673-873133
/subversion/branches/1.6.x-r37622/CHANGES:874044-874338
/subversion/branches/1.6.x-r37627/CHANGES:874049-874273
/subversion/branches/1.6.x-r37857/CHANGES:874277-874281
/subversion/branches/1.6.x-r37953/CHANGES:876154-876416
/subversion/branches/1.6.x-r37988/CHANGES:874408-875242
/subversion/branches/1.6.x-r38000/CHANGES:875428-876112
/subversion/branches/1.6.x-r38222/CHANGES:874644-875236
/subversion/branches/1.6.x-r38572/CHANGES:875006-875011
/subversion/branches/1.6.x-r38799/CHANGES:875225-875262
/subversion/branches/1.6.x-r38927/CHANGES:875347-875521
/subversion/branches/1.6.x-r39557/CHANGES:876013-876252
/subversion/branches/1.6.x-r39887/CHANGES:876369-876411
/subversion/branches/1.6.x-r40452/CHANGES:880530-890996
/subversion/branches/1.6.x-r889840/CHANGES:889888-890974
/subversion/branches/bdb-reverse-deltas/CHANGES:868395-868874
/subversion/branches/diff-callbacks3/CHANGES:866404-867106
/subversion/branches/dont-save-plaintext-passwords-by-default/CHANGES:867073-867463
/subversion/branches/double-delete/CHANGES:866856-869315
/subversion/branches/file-externals/CHANGES:868124-869647
/subversion/branches/fs-rep-sharing/CHANGES:865381-870148
/subversion/branches/fsfs-pack/CHANGES:870062-870920
/subversion/branches/gnome-keyring/CHANGES:866903-867755
/subversion/branches/in-memory-cache/CHANGES:866174-867797
/subversion/branches/issue-2843-dev/CHANGES:867777-870524
/subversion/branches/issue-3000/CHANGES:868058,868061-868064,868066-868071,868073,868079
/subversion/branches/issue-3067-deleted-subtrees/CHANGES:869720-870429
/subversion/branches/issue-3148-dev/CHANGES:871538-871549
/subversion/branches/issue-3220-dev/CHANGES:868555-868571
/subversion/branches/issue-3334-dirs/CHANGES:871501-872212
/subversion/branches/kwallet/CHANGES:867130-867659
/subversion/branches/log-g-performance/CHANGES:867286-867377
/subversion/branches/merge-skips-obstructions/CHANGES:870870-870960
/subversion/branches/reintegrate-improvements/CHANGES:870198-870509
/subversion/branches/svn-mergeinfo-enhancements/CHANGES:866464-866540,866542-866633
/subversion/branches/svnpatch-diff/CHANGES:868250,868331
/subversion/branches/svnserve-logging/CHANGES:866173-867238
/subversion/branches/tc-issue-3334/CHANGES:871042-871118
/subversion/branches/tc-merge-notify/CHANGES:870362-870407
/subversion/branches/tc-resolve/CHANGES:870536-870584
/subversion/branches/tc_url_rev/CHANGES:870696-870828
/subversion/branches/tree-conflicts/CHANGES:864636-869499
/subversion/branches/tree-conflicts-notify/CHANGES:870271-870353
/subversion/trunk/CHANGES:836421-837700,875962-876471,876507,876571,880274-880275,880474,880525-880526,881905,884842,886164,886197,888979,889081,889840
On the source:
1.6.6>svn pg svn:mergeinfo ^^/subversion/branches/1.6.x-r40452/CHANGES@891008
subversion/branches/1.5.x-r30215/CHANGES:866657
subversion/branches/1.6.x-UNC-paths/CHANGES:872816-872890
subversion/branches/1.6.x-dirent-basename/CHANGES:872475-872607
subversion/branches/1.6.x-issue3443/CHANGES:874942-875825
subversion/branches/1.6.x-no-svn_uri/CHANGES:872705-872760
subversion/branches/1.6.x-r36178/CHANGES:874221-874229
subversion/branches/1.6.x-r36252/CHANGES:872673-873133
subversion/branches/1.6.x-r37622/CHANGES:874044-874338
subversion/branches/1.6.x-r37627/CHANGES:874049-874273
subversion/branches/1.6.x-r37857/CHANGES:874277-874281
subversion/branches/1.6.x-r37953/CHANGES:876154-876416
subversion/branches/1.6.x-r37988/CHANGES:874408-875242
subversion/branches/1.6.x-r38000/CHANGES:875428-876112
subversion/branches/1.6.x-r38222/CHANGES:874644-875236
subversion/branches/1.6.x-r38572/CHANGES:875006-875011
subversion/branches/1.6.x-r38799/CHANGES:875225-875262
subversion/branches/1.6.x-r38927/CHANGES:875347-875521
subversion/branches/1.6.x-r39557/CHANGES:876013-876252
subversion/branches/1.6.x-r39887/CHANGES:876369-876411
subversion/branches/bdb-reverse-deltas/CHANGES:868395-868874
subversion/branches/diff-callbacks3/CHANGES:866404-867106
subversion/branches/dont-save-plaintext-passwords-by-default/CHANGES:867073-867463
subversion/branches/double-delete/CHANGES:866856-869315
subversion/branches/file-externals/CHANGES:868124-869647
subversion/branches/fs-rep-sharing/CHANGES:865381-870148
subversion/branches/fsfs-pack/CHANGES:870062-870920
subversion/branches/gnome-keyring/CHANGES:866903-867755
subversion/branches/in-memory-cache/CHANGES:866174-867797
subversion/branches/issue-2843-dev/CHANGES:867777-870524
subversion/branches/issue-3000/CHANGES:868058,868061-868064,868066-868071,868073,868079
subversion/branches/issue-3067-deleted-subtrees/CHANGES:869720-870429
subversion/branches/issue-3148-dev/CHANGES:871538-871549
subversion/branches/issue-3220-dev/CHANGES:868555-868571
subversion/branches/issue-3334-dirs/CHANGES:871501-872212
subversion/branches/kwallet/CHANGES:867130-867659
subversion/branches/log-g-performance/CHANGES:867286-867377
subversion/branches/merge-skips-obstructions/CHANGES:870870-870960
subversion/branches/reintegrate-improvements/CHANGES:870198-870509
subversion/branches/svn-mergeinfo-enhancements/CHANGES:866464-866540,866542-866633
subversion/branches/svnpatch-diff/CHANGES:868250,868331
subversion/branches/svnserve-logging/CHANGES:866173-867238
subversion/branches/tc-issue-3334/CHANGES:871042-871118
subversion/branches/tc-merge-notify/CHANGES:870362-870407
subversion/branches/tc-resolve/CHANGES:870536-870584
subversion/branches/tc_url_rev/CHANGES:870696-870828
subversion/branches/tree-conflicts/CHANGES:864636-869499
subversion/branches/tree-conflicts-notify/CHANGES:870271-870353
subversion/trunk/CHANGES:836421-837700,872307-876471,876507,876571,880525-880526
What you want to notice here is the mergeinfo
'subverison/trunk/CHANGES:836421-837700', this actually predates the
creation of subversion/trunk/CHANGES, which was in r841356. How this
got into our repos in the first place is a good question, and one I am
trying to track down, see
http://mail-archives.apache.org/mod_mbox/subversion-dev/200912.mbox/browser,
but I don't think it should impact the decision to roll 1.6.7. There
may be another bug here, but since the offending mergeinfo was created
a month prior to 1.6.6 we are not dealing with a regression.
Anyway, onto the "regression". A 1.6.6 client, not realizing that the
merge source "subversion/trunk/CHANGES" == "/subversion/trunk/CHANGES"
simply ignores the relative pathed mergeinfo. But with r890993 the
relative path is interpreted as an absolute path and so the
reintegrate code thinks that we have done some merge(s) from trunk to
the 1.6.x-r889840 branch, but the code doesn't handle the case where
that mergeinfo describes non-existent path-revs, ultimately producing
the error that Hyrum saw.
I've hacked a crude fix to ignore mergeinfo on the reintegrate source
that predates the common ancestor of the reintegrate target and
source. This seems to work fine, though it still needs some more
testing. Regardless, I don't think this is a true regression, just a
new bug, and as such, not something that should hold up 1.6.7.
Some final thoughts:
If we revert r890993, we will have different problems with
reintegrate, namely that merges that really were done from 'trunk' to
'some-branch' will be ignored if we try to reintegrate 'some-branch'
back to 'trunk' and the reintegrate merge will fail/break. Of course
this won't matter much since the merge/mergeinfo subcommands, on our
own repository anyway (and any other bitten by issue #3547), will
effectively be useless with a 1.6.7 client, see
http://mail-archives.apache.org/mod_mbox/subversion-dev/200912.mbox/browser.
Paul
Re: Subversion 1.6.7 on Dec. 16.
Posted by Philip Martin <ph...@wandisco.com>.
Paul Burba <pt...@gmail.com> writes:
> Hyrum ran into a problem when reintegrating a branch back to 1.6.x
> using the (at the time) latest 1.6.x client. Here is the merge he did
> (though this has a pegged source because the backport branch was
> deleted):
>
> 1.6.x.>svn merge ^^/subversion/branches/1.6.x-r40452@891008 . --reintegrate
> ..\..\..\subversion\libsvn_ra_neon\util.c:546: (apr_err=160013)
> svn: '/repos/asf/!svn/bc/875961/subversion/branches/1.6.x' path not found
>
> Unfortunately this reintegrate works with 1.6.6, so we have a regression.
>
> I've traced the cause to r890993 (Reintegrate the 1.6.x-r889840
> branch) which was my attempt to address the myriad of problems caused
> by issue #3547 http://subversion.tigris.org/issues/show_bug.cgi?id=3547,
> which converted all the mergeinfo in our repository from absolute to
> relative merge source paths when we loaded it into the ASF repos. I
> haven't been able to fix the reintegrate problem Hyrum encountered,
> heck it's not exactly clear to me what is going wrong, but I'm working
> on it.
As one who voted for r890993 I wouldn't object if it was reverted and
we released without it. It is a change in behaviour, so I guess that
counts as a regression, but what seems to be happening is that the old
code ignores some of the incorrect mergeinfo because the paths don't
match. It's possible that the new behaviour, getting an error when
the mergeinfo is broken, is better.
--
Philip
Re: Subversion 1.6.7 on Dec. 16.
Posted by Paul Burba <pt...@gmail.com>.
On Mon, Dec 14, 2009 at 4:43 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> On Dec 2, 2009, at 6:39 PM, Hyrum K. Wright wrote:
>
>> Hi all.
>>
>> Gather up your holiday cheer, for I would like to propose a gift to the Subversion user community: Subversion 1.6.7. I know that folks have been busy with the ASF transition as of late, but our users have been busy finding bugs and STATUS is getting pretty full. As a result, I'd like to roll 1.6.7 on Wed., Dec. 16.
>>
>> Remember, 'tis better to give than receive, so please give the gift of review time and votes to worthy items in STATUS.
>
> Nudge, nudge...
>
> 1.6.7 is still rolling on Dec. 14, only 2 days away. Get your votes in now!
>
> -Hyrum
For those who missed it on IRC, 1.6.7 is on hold.
Hyrum ran into a problem when reintegrating a branch back to 1.6.x
using the (at the time) latest 1.6.x client. Here is the merge he did
(though this has a pegged source because the backport branch was
deleted):
1.6.x.>svn merge ^^/subversion/branches/1.6.x-r40452@891008 . --reintegrate
..\..\..\subversion\libsvn_ra_neon\util.c:546: (apr_err=160013)
svn: '/repos/asf/!svn/bc/875961/subversion/branches/1.6.x' path not found
Unfortunately this reintegrate works with 1.6.6, so we have a regression.
I've traced the cause to r890993 (Reintegrate the 1.6.x-r889840
branch) which was my attempt to address the myriad of problems caused
by issue #3547 http://subversion.tigris.org/issues/show_bug.cgi?id=3547,
which converted all the mergeinfo in our repository from absolute to
relative merge source paths when we loaded it into the ASF repos. I
haven't been able to fix the reintegrate problem Hyrum encountered,
heck it's not exactly clear to me what is going wrong, but I'm working
on it.
Paul
Re: Subversion 1.6.7 on Dec. 16.
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Dec 2, 2009, at 6:39 PM, Hyrum K. Wright wrote:
> Hi all.
>
> Gather up your holiday cheer, for I would like to propose a gift to the Subversion user community: Subversion 1.6.7. I know that folks have been busy with the ASF transition as of late, but our users have been busy finding bugs and STATUS is getting pretty full. As a result, I'd like to roll 1.6.7 on Wed., Dec. 16.
>
> Remember, 'tis better to give than receive, so please give the gift of review time and votes to worthy items in STATUS.
Nudge, nudge...
1.6.7 is still rolling on Dec. 14, only 2 days away. Get your votes in now!
-Hyrum
Re: Subversion 1.6.7 on Dec. 16.
Posted by Jack Repenning <jr...@collab.net>.
On Dec 8, 2009, at 11:37 AM, Hyrum K. Wright wrote:
> I know Greg and Justin have been traveling, but hopefully they can
> chime in.
Greg just tweeted something about "20 hours flying," so I'm guessing
you should plan in a decent "crash interval" before you expect
anything from either of them ;-)
You are, of course, welcome to use s.t.o one last time--or many--and
that's certainly the way I recall the outcome of the ApacheCon meet-
up. I hazard no guesses as to what path would be most acceptable to
the keepers of the Incubator.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
twitter: http://twitter.com/jrep
Re: Subversion 1.6.7 on Dec. 16.
Posted by Jack Repenning <jr...@collab.net>.
On Dec 8, 2009, at 11:37 AM, Hyrum K. Wright wrote:
> I know Greg and Justin have been traveling, but hopefully they can
> chime in.
Greg just tweeted something about "20 hours flying," so I'm guessing
you should plan in a decent "crash interval" before you expect
anything from either of them ;-)
You are, of course, welcome to use s.t.o one last time--or many--and
that's certainly the way I recall the outcome of the ApacheCon meet-
up. I hazard no guesses as to what path would be most acceptable to
the keepers of the Incubator.
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
twitter: http://twitter.com/jrep
Re: Subversion 1.6.7 on Dec. 16.
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Dec 8, 2009, at 1:47 PM, Branko Čibej wrote:
> Hyrum K. Wright wrote:
>> On Dec 8, 2009, at 1:34 PM, Mark Phippard wrote:
>>
>>
>>> On Wed, Dec 2, 2009 at 7:39 PM, Hyrum K. Wright
>>> <hy...@mail.utexas.edu> wrote:
>>>
>>>
>>>> Gather up your holiday cheer, for I would like to propose a gift to the Subversion user community: Subversion
>>>> 1.6.7. I know that folks have been busy with the ASF transition as of late, but our users have been busy
>>>> finding bugs and STATUS is getting pretty full. As a result, I'd like to roll 1.6.7 on Wed., Dec. 16.
>>>>
>>> Does being in the incubator add any new wrinkles in publishing a
>>> release? Such as having it reviewed first? Also, the release
>>> obviously does not have any of the license changes in it. Is that a
>>> problem? Out of curiosity, once we are a TLP can we still do a new
>>> 1.6.x or 1.5.x release without the license changes?
>>>
>>
>> I'm not sure about this. I know Greg and Justin have been traveling, but hopefully they can chime in. (I suspect we can still publish the code on s.t.o if it isn't yet acceptable to the ASF.)
>>
>
> 1.6.7 doesn't have all the necessary licensing bits. It wouldn't pass a
> license review. However, IIRC the IPMC wants to review the release process.
That's what I figured. I'm fine with doing the release process on dev@s.a.o, and allowing whatever scrutiny the IPMC want into the process.
-Hyrum
Re: Subversion 1.6.7 on Dec. 16.
Posted by Branko Čibej <br...@xbc.nu>.
Hyrum K. Wright wrote:
> On Dec 8, 2009, at 1:34 PM, Mark Phippard wrote:
>
>
>> On Wed, Dec 2, 2009 at 7:39 PM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>>
>>
>>> Gather up your holiday cheer, for I would like to propose a gift to the Subversion user community: Subversion
>>> 1.6.7. I know that folks have been busy with the ASF transition as of late, but our users have been busy
>>> finding bugs and STATUS is getting pretty full. As a result, I'd like to roll 1.6.7 on Wed., Dec. 16.
>>>
>> Does being in the incubator add any new wrinkles in publishing a
>> release? Such as having it reviewed first? Also, the release
>> obviously does not have any of the license changes in it. Is that a
>> problem? Out of curiosity, once we are a TLP can we still do a new
>> 1.6.x or 1.5.x release without the license changes?
>>
>
> I'm not sure about this. I know Greg and Justin have been traveling, but hopefully they can chime in. (I suspect we can still publish the code on s.t.o if it isn't yet acceptable to the ASF.)
>
1.6.7 doesn't have all the necessary licensing bits. It wouldn't pass a
license review. However, IIRC the IPMC wants to review the release process.
-- Brane
Re: Subversion 1.6.7 on Dec. 16.
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Dec 8, 2009 at 2:37 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>> Where are you planning on posting the release? The project on tigris
>> has changed, so you if you want to post to the downloads area, you now
>> need to checkout the project "/trunk/www" folder and then svn add/ci
>> the files to the download area to post them.
>
> Depending on the answers to the ASF question, we can put it on s.t.o or on ASF infrastructure. I need to get
> more answers at this point.
Other than the nasty checkout time if you do not use --depth=empty,
this part is at least easy to do. You might want to make sure your
tigris credentials are setup to commit to that repository though
before the release happens. I just wanted to give you a heads up in
case you had forgotten this change had been made.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Subversion 1.6.7 on Dec. 16.
Posted by Joe Schaefer <jo...@yahoo.com>.
In order to distribute it as an "Apache" release, using ASF
infrastructure (mirrors) to carry it, it has to be Apache-Licensed
at a minimum. It also would need to be formally approved by
the Incubator PMC.
AIUI you guys were going to use the "old" infrastructure to
distribute the release, in which case it's not an Apache release
per se, and the aforementioned rules do not apply.
----- Original Message ----
> From: Hyrum K. Wright <hy...@mail.utexas.edu>
> To: Mark Phippard <ma...@gmail.com>
> Cc: Subversion Development <de...@subversion.apache.org>
> Sent: Tue, December 8, 2009 2:37:24 PM
> Subject: Re: Subversion 1.6.7 on Dec. 16.
>
>
> On Dec 8, 2009, at 1:34 PM, Mark Phippard wrote:
>
> > On Wed, Dec 2, 2009 at 7:39 PM, Hyrum K. Wright
> > wrote:
> >
> >> Gather up your holiday cheer, for I would like to propose a gift to the
> Subversion user community: Subversion
> >> 1.6.7. I know that folks have been busy with the ASF transition as of late,
> but our users have been busy
> >> finding bugs and STATUS is getting pretty full. As a result, I'd like to
> roll 1.6.7 on Wed., Dec. 16.
> >
> > Does being in the incubator add any new wrinkles in publishing a
> > release? Such as having it reviewed first? Also, the release
> > obviously does not have any of the license changes in it. Is that a
> > problem? Out of curiosity, once we are a TLP can we still do a new
> > 1.6.x or 1.5.x release without the license changes?
>
> I'm not sure about this. I know Greg and Justin have been traveling, but
> hopefully they can chime in. (I suspect we can still publish the code on s.t.o
> if it isn't yet acceptable to the ASF.)
>
> > Where are you planning on posting the release? The project on tigris
> > has changed, so you if you want to post to the downloads area, you now
> > need to checkout the project "/trunk/www" folder and then svn add/ci
> > the files to the download area to post them.
>
> Depending on the answers to the ASF question, we can put it on s.t.o or on ASF
> infrastructure. I need to get more answers at this point.
>
> -Hyrum
Re: Subversion 1.6.7 on Dec. 16.
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Dec 8, 2009, at 1:34 PM, Mark Phippard wrote:
> On Wed, Dec 2, 2009 at 7:39 PM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>
>> Gather up your holiday cheer, for I would like to propose a gift to the Subversion user community: Subversion
>> 1.6.7. I know that folks have been busy with the ASF transition as of late, but our users have been busy
>> finding bugs and STATUS is getting pretty full. As a result, I'd like to roll 1.6.7 on Wed., Dec. 16.
>
> Does being in the incubator add any new wrinkles in publishing a
> release? Such as having it reviewed first? Also, the release
> obviously does not have any of the license changes in it. Is that a
> problem? Out of curiosity, once we are a TLP can we still do a new
> 1.6.x or 1.5.x release without the license changes?
I'm not sure about this. I know Greg and Justin have been traveling, but hopefully they can chime in. (I suspect we can still publish the code on s.t.o if it isn't yet acceptable to the ASF.)
> Where are you planning on posting the release? The project on tigris
> has changed, so you if you want to post to the downloads area, you now
> need to checkout the project "/trunk/www" folder and then svn add/ci
> the files to the download area to post them.
Depending on the answers to the ASF question, we can put it on s.t.o or on ASF infrastructure. I need to get more answers at this point.
-Hyrum
Re: Subversion 1.6.7 on Dec. 16.
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Dec 2, 2009 at 7:39 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Gather up your holiday cheer, for I would like to propose a gift to the Subversion user community: Subversion
> 1.6.7. I know that folks have been busy with the ASF transition as of late, but our users have been busy
> finding bugs and STATUS is getting pretty full. As a result, I'd like to roll 1.6.7 on Wed., Dec. 16.
Does being in the incubator add any new wrinkles in publishing a
release? Such as having it reviewed first? Also, the release
obviously does not have any of the license changes in it. Is that a
problem? Out of curiosity, once we are a TLP can we still do a new
1.6.x or 1.5.x release without the license changes?
Where are you planning on posting the release? The project on tigris
has changed, so you if you want to post to the downloads area, you now
need to checkout the project "/trunk/www" folder and then svn add/ci
the files to the download area to post them.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Subversion 1.6.7 on Dec. 16.
Posted by Branko Čibej <br...@xbc.nu>.
Hyrum K. Wright wrote:
> Hi all.
>
> Gather up your holiday cheer, for I would like to propose a gift to the Subversion user community: Subversion 1.6.7. I know that folks have been busy with the ASF transition as of late, but our users have been busy finding bugs and STATUS is getting pretty full. As a result, I'd like to roll 1.6.7 on Wed., Dec. 16.
>
> Remember, 'tis better to give than receive, so please give the gift of review time and votes to worthy items in STATUS.
>
> Thanks,
> -Hyrum
>
> PS - Almost sent this to dev@s.t.o too, but figured the people that cared are already on dev@s.a.o. We really need to get rid of dev@s.t.o RSN.
Hm, can we make it 1.6.40 and release on the 18th?
-- Brane