On Tue, Jun 15, 2010 at 1:21 PM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> Hi devs. Â Going through the 1.6.x. STATUS file, I am finding some items
> that could do with a better description or justification to make it
> easier to evaluate them. Â Can anyone provide information on the
> following:
>
>
>> Â * r934599, r934603
>> Â Â Fix a concurrency issue in the FSFS rep-cache code. Â This indirectly
>> Â Â concerns issue #3506.
>> Â Â Justification:
>> Â Â Â Opening the DB twice (and overwriting the handle) is undesired.
>
> Why is that undesired? Â I mean that as a serious practical question -
> obviously it's theoretically redundant but that in itself doesn't
> necessarily matter. Â What is the user-visible effect of the problem, and
> of the proposed change?
>
>> Â Â Notes:
>> Â Â Â r934599 updates the svn_atomic__init_once() interface.
>> Â Â Â r934603 is the actual fix.
>> Â Â Notes:
>> Â Â Â Depends on the r879966 group, which does not merge cleanly.
>> Â Â Branch:
>> Â Â Â ^/subversion/branches/1.6.x-issue3506-init_once
>> Â Â Â (based on ^/subversion/branches/1.6.x-issue3506)
>> Â Â Votes:
>> Â Â Â +1: danielsh
>
>
>> Â * r878590, r878607, r878625, r878626, r878627
>> Â Â In trunk we optimized the common case of 'find-and-replace with same uri'
>> Â Â of proxied content thanks to issue 3445 "WebDAV proxy code munging user
>> Â Â data".
>
> What is the purpose and effect of the change proposed for back-port?
>
>> Â Â r878590 is just a change that adds FIXME marker to code comment. We take it
>> Â Â to avoid spurious conflicts with other revisions.
>> Â Â r878607 Special cases no-op find and replace.
>> Â Â "r878625, r878626, r878627" are follow-up to r878607 and the other long
>> Â Â pending Master info leak to the clients.
>> Â Â Justification:
>> Â Â Â 1. This group has the most common 'optimization' fix of *not* groking the
>> Â Â Â Â proxied response to find and replace with same string.
>> Â Â Â 2. Fixes the master information leak via the Location header.
>> Â Â Â 3. Need this to be ported for the other defect to be ported
>> Â Â Â Â without conflict.
>> Â Â Votes:
>> Â Â Â +1: kameshj, cmpilato
>> Â Â Â -0: julianfoad (seem to be multiple changes here for different reasons -
>> Â Â Â Â Â Â at least issue '3445 and an optimization and an information leak;
>> Â Â Â Â Â Â r878607 log msg says it fixes bugs but it's not clear what bugs;
>> Â Â Â Â Â Â don't know how to tell whether justification 1 is significant;
>> Â Â Â Â Â Â justifications don't seem to refer to issue #3445. Please can we
>> Â Â Â Â Â Â separate these changes and clearly describe each one? And update
>> Â Â Â Â Â Â the r878607 log msg.)
>
> Ah, I already put my concerns here.
>
>
>> Â * r916286, r917512
>> Â Â ???
>
> What is the purpose and effect of the change proposed for back-port?
>
> (It was me who added the question marks, some time ago.)
>
>> Â Â Notes:
>> Â Â Â This backport depends on the r878590 group only for the conflict free port.
>> Â Â Justification:
>> Â Â Â Vague commit error when server has been configured with <Location /svn/>
>> Â Â Â and write through proxy.
>
> How bad is the old error message? Â How much better is the new one? Â An
> example might help. Â Does the change have any other effect?
>
>> Â Â Votes:
>> Â Â Â +1: kameshj
>
>
>> Â * r917523
>> Â Â ???
>
> Ditto.
>
>> Â Â Notes:
>> Â Â Â This backport depends on the r878590 and r916286 groups only for the
>> Â Â Â conflict free port.
>> Â Â Justification:
>> Â Â Â If the configured slave url has the *encodable* characters *write through*
>> Â Â Â is not happening rather commit happens in slave itself.
>
> Commit happens in the slave? Â That's certainly and obviously wrong. Â But
> I don't understand what you mean by "the configured slave url has the
> *encodable* characters".
>
>> Â Â Votes:
>> Â Â Â +1: kameshj
>
>
>> Â * r935631
>> Â Â Fix one of the sanity checks in the 'svn merge --reintegrate' logic.
>
> What check? Â What did it do? Â What will it do after this change?
>
> OK, I've looked at this one, and it appears that the check to ensure the
> source and target are in the same repository was not being checked (it
> was comparing target-repos with target-repos), and this change will make
> it return an error if they are in different repositories, as was
> intended. Â I'm not sure exactly what would happen if this condition were
> not caught.
Hi Julian,
Fortunately even without r935631 any attempt to reintegrate a source
from a foreign repository fails. So this change is really about
providing a (much) better error mesage:
1.6.11:
>svn merge %REPOS_A_ROOT_URL%file:///C%3A/SVN/src-branch-1.6.x/Release/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-54.other/A_COPY A --reintegrate
svn: URL 'file:///C%3A/SVN/src-branch-1.6.x/Release/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-54.other/A_COPY'
is not a child of repository root URL
'file:///C%3A/SVN/src-branch-1.6.x/Release/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-54'
1.6.12 with Mike's patch:
>svn merge file:///C%3A/SVN/src-branch-1.6.x/Release/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-54.other/A_COPY A --reintegrate
svn: 'file:///C%3A/SVN/src-branch-1.6.x/Release/subversion/tests/cmdline/svn-test-work/repositories/merge_tests-54.other/A_COPY'
must be from the same repository as 'A'
I made a note of the above in STATUS.
Paul
>> Â Â Justification:
>> Â Â Â Sanity checks should themselves be sane.
>> Â Â Branch:
>> Â Â Â ^/subversion/branches/1.6.x-r935631
>> Â Â Votes:
>> Â Â Â +1: cmpilato, pburba
>
>
>> Â * r939375-939376
>> Â Â Fix issue #3623, a bug in foreign repository merges that causes properties
>> Â Â on merge-added files to be dropped from commits of those merges.
>> Â Â Justification:
>> Â Â Â This can actually result in what is arguably a corrupt working copy,
>> Â Â Â one that thinks it is in sync with the repository but actually is not.
>
> (Here's an example of a good description and justification.)
>
>
>> Â * r950445, 950468
>> Â Â Fix for issue #2591 "'svnadmin hotcopy' does not replicate symlinks".
>> Â Â Justification:
>> Â Â Â This issue is waiting for resolution for more than 3 years.
>
> Length of time is not really a justification.
>
>> Â Â Notes:
>> Â Â Â r950445 fixes the issue and r950468 is a test for this issue.
>> Â Â Votes:
>> Â Â Â +1: stylesen
>
>
>> Â * r952973, r952992
>> Â Â Fix for issue #3651 "svn copy does not eat peg revision within copy target
>> Â Â path"
>> Â Â Justification:
>> Â Â Â This issue exists in 1.6.x.
>
> All of these issues exist in 1.6.x, that's why the fixes are proposed
> for back-port.
>
>> Â Â Notes:
>> Â Â Â r952973 fixes the issue and r952992 is a test for this issue. Both r952973
>> Â Â Â and r952992 are merged into the backport branch 1.6.x-issue3651.
>> Â Â Â Use the private API in the 1.6.x branch since the API was made public in
>> Â Â Â 1.7. The backport branch exists in order to resolve this.
>> Â Â Branch:
>> Â Â Â ^/subversion/branches/1.6.x-issue3651
>> Â Â Votes:
>> Â Â Â +1: stylesen, pburba
>
>
> - Julian
>
>
>
Received on 2010-06-15 20:06:29 CEST