These are all good questions, and I would suggest that whoever answers them does so in the STATUS file, rather than just on list.
Cheers, -Hyrum On Tue, Jun 15, 2010 at 12:21 PM, Julian Foad <julian.f...@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. > >> 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 > > >
