[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Oh, shoot: Issue 2591 should not have been closed

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Sat, 26 Jun 2010 09:36:57 -0400

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

>> 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
Received on 2010-06-26 15:37:38 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.