On Sat, Jun 26, 2010 at 3:06 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > [ CC += us...@. The reply trims and rearranges some of Nico's quotes. ] > > Nico Kadel-Garcia wrote on Sat, 26 Jun 2010 at 02:12 -0000: >> There's been plenty of time to address the issue. But according to the >> 2591 bug report: >> >> > Post-1.6 issue sweep. Since 1.7 is already shaping up to be a >> large release, >> move to 1.8-consider. >> >> To me, that looks like it's not scheduled until the 1.8 release. >> > > It is (present tense) fixed in 1.7.0 and the issue says so. > > Resolution: FIXED > Target milestone: 1.7.0
It's not "fixed" in the release code. Like a mechanic who has the new tire still in their garage, it's not "FIXED" until it's actually on the vehicle you drive away in. And according to what I just quoted, it looks like it may get pushed back to 1.8. This is why pre-release code should not be counted as a "FIX". It should be marked as "PENDING", or "TESTING", or some other reasonable category. >> There's nothing sophisticated about the situation. If you cannot >> duplicate one of the relevant contents of a repository with a >> "hotcopy", you don't silently ignore the problem and hope it goes >> away, that's basic programming practice for any backup or replication >> system: you at least report it, and ideally you provide an exit code, >> to let people know that they've done something you can't properly >> replicate and they need to fix it. The ignoring symlinks in silence is >> nasty > > I'm sure this will be useful input to the dev@ thread I mentioned in my > previous post. (which deals with what apr_filetype_e values > should/shouldn't be considered by svn_io_dir_walk()) That's actually a repeat of what I said 4 years ago, not word for word, admittedly. I'll push the conversation over there: it's getting out of the realm of ordinay user issues. >> The script tests the original bug as originally reported in the >> curreht 1.6.12 release. Compiling and integrating current Subversion >> releases under professionally supported RHEL releases (which I've been >> involved with supporting updates for for the last 4 years) is a fairly >> tricky procedure due to the non-RHEL-standard Python and SQLite >> requirements, so it will take me a bit to test it against the latest >> trunk code. > > Note that you don't need to build trunk Subversion --- you just need to > run the regression test from trunk. You can do that by running the > following in a fresh trunk checkout: > > ./subversion/tests/cmdline/svnadmin_tests.py --bin=/usr/bin hotcopy_symlink And you shouldn't have to check out the source tree to run a basic test script against your existing version: that's why I published that somewhat more rigorous script. > Then, you may suggest a change to the hotcopy_symlink() function (in > svnadmin_tests.py) so that it better captures the regression. (i.e., > merge your shell script with our Python regression test) That's quite reasonable. I'll look into it, and hop over to the developer's mailing list to pursue these issues there. I do hope this can be backported from "trunk" to the next 1.6.x release, because seriously, it's been a longstanding pain in the backside for me. We can discuss in some other thread someday the wisdom of having your "trunk" be your pre-release code for a future major revision, rather than using branches for that and keepign the trunk tied to your current major release. This is why I like major releases to get their own repos or top level directories: it helps avoid certain types of confusion.
