On Sat, Jun 26, 2010 at 3:06 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> [ CC += users@. 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.
Received on 2010-06-26 15:37:38 CEST