You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nico Kadel-Garcia <nk...@gmail.com> on 2010/06/25 12:08:14 UTC
Oh, shoot: Issue 2591 should not have been closed
Good morning:
This is Nico Kadel-Garcia, the person who submitted the svnadmin
hotcopy/symlink issue number 2591 in 2006. I see that it's been very
recently marked "resolved". This is not fixed in the recent 1.6.12
release, I'm sad to say.
This bug has been a pain in my backside for 4 years. Can we seriously
encourage its inclusion in 1.6.13, at least?
I've also included a somewhat more robust test script below, to verify
that the symlinks are duplicated and they point to the same place.
========================================
#!/bin/sh
#
# test-hotcopy-hardlink.sh - verify svnadmin hotcopy preservation of symlinks
REPO1=/tmp/repo1
REPO2=/tmp/repo2
rm -rf $REPO1 $REPO2 || exit 1
svnadmin create $REPO1
/bin/mv $REPO1/conf/passwd $REPO1/conf/passwd.template
ln -s $REPO1/conf/passwd.template $REPO1/conf/passwd
svnadmin hotcopy $REPO1 $REPO2
readlink $REPO1/conf/passwd
if [ ! -h $REPO2/conf/passwd ]; then
echo "Error: svnadmin hotcopy fails to duplicate symlinks in repository"
exit 1
elif [ "`readlink $REPO1/conf/passwd`" != "`readlink
$REPO2/conf/passwd`" ]; then
echo "Error: svnadmin hotcopy gets symlinks wrong in repository"
exit 1
fi
Re: Oh, shoot: Issue 2591 should not have been closed
Posted by Senthil Kumaran S <se...@collab.net>.
Hi Nico,
Nico Kadel-Garcia wrote:
> This bug has been a pain in my backside for 4 years. Can we seriously
> encourage its inclusion in 1.6.13, at least?
I ll do my best so that this fix is included in 1.6.13 release.
Thank You.
--
Senthil Kumaran S
http://www.stylesen.org/
Re: Oh, shoot: Issue 2591 should not have been closed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nico Kadel-Garcia wrote on Sat, 26 Jun 2010 at 02:12 -0000:
> [ I accidentally replied only to Daniel, and meant to send this to the
> list. Forgive me please, Daniel. ]
Don't worry. (Next time, you may want to forward your reply to the list,
so that others can answer and so that any quote-trimming I do while
replying doesn't prevent portions of your text from reaching the list.)
I've replied now and added the list back to CC.
See you,
Daniel
Re: Oh, shoot: Issue 2591 should not have been closed
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
[ I accidentally replied only to Daniel, and meant to send this to the
list. Forgive me please, Daniel. ]
On Fri, Jun 25, 2010 at 9:12 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> This came across as a very negative tone. (I assume you had read the
> comments in the issue)
>
> It's nominated for backport. There was a dev@ thread asking if it should
> get some (fairly trivial to implement) changes before being backported.
> The thread concluded, but the branches/1.6.x/STATUS entry is still marked
> "waiting for thread to resolve".
>
> If you'd like to move this forward, you can ask on dev@ to see what
> changes need to be made (if any) and for more +1 votes (and less -0 votes)
> in STATUS.
>
> Regarding your shell script, please review the regression test in HEAD of
> trunk to ensure it captures the desired behaviour.
>
> Daniel
>
>
> Nico Kadel-Garcia wrote on Fri, 25 Jun 2010 at 15:08 -0000:
>> Good morning:
>>
>> This is Nico Kadel-Garcia, the person who submitted the svnadmin
>> hotcopy/symlink issue number 2591 in 2006. I see that it's been very
>> recently marked "resolved". This is not fixed in the recent 1.6.12
>> release, I'm sad to say.
>>
>> This bug has been a pain in my backside for 4 years. Can we seriously
>> encourage its inclusion in 1.6.13, at least?
>>
>> I've also included a somewhat more robust test script below, to verify
>> that the symlinks are duplicated and they point to the same place.
>>
>> ========================================
>>
>> #!/bin/sh
>> #
>> # test-hotcopy-hardlink.sh - verify svnadmin hotcopy preservation of symlinks
>>
>> REPO1=/tmp/repo1
>> REPO2=/tmp/repo2
>>
>> rm -rf $REPO1 $REPO2 || exit 1
>> svnadmin create $REPO1
>> /bin/mv $REPO1/conf/passwd $REPO1/conf/passwd.template
>> ln -s $REPO1/conf/passwd.template $REPO1/conf/passwd
>> svnadmin hotcopy $REPO1 $REPO2
>> readlink $REPO1/conf/passwd
>> if [ ! -h $REPO2/conf/passwd ]; then
>> echo "Error: svnadmin hotcopy fails to duplicate symlinks in repository"
>> exit 1
>> elif [ "`readlink $REPO1/conf/passwd`" != "`readlink
>> $REPO2/conf/passwd`" ]; then
>> echo "Error: svnadmin hotcopy gets symlinks wrong in repository"
>> exit 1
>> fi
>>
>>
>
Re: Oh, shoot: Issue 2591 should not have been closed
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Jun 26, 2010 at 9:59 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Nico Kadel-Garcia wrote on Sat, 26 Jun 2010 at 16:36 -0000:
>> And according to what I just quoted, it looks like it may get pushed
>> back to 1.8.
>
> I just told you that it will be fixed in 1.7.0 (when the latter is released).
Good. I can conrirm that it's fixed in trunk, compiled under Fedora
13. Compiling it under RHEL 5 is.... considerably harder and will take
a while.
Re: Oh, shoot: Issue 2591 should not have been closed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nico Kadel-Garcia wrote on Sat, 26 Jun 2010 at 16:36 -0000:
> And according to what I just quoted, it looks like it may get pushed
> back to 1.8.
I just told you that it will be fixed in 1.7.0 (when the latter is released).
Re: Oh, shoot: Issue 2591 should not have been closed
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Jun 26, 2010 at 3:06 AM, Daniel Shahaf <d....@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.
Re: Oh, shoot: Issue 2591 should not have been closed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[ 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
> 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())
> and I've had to clean up after it 3 times since originally
> submitting the bug for people who thought they were being clever, and
> written some cumbersome autoconfiguration workarounds to deal with
> propagating configurations among multiple repositories.
>
> On Fri, Jun 25, 2010 at 9:12 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > If you'd like to move this forward, you can ask on dev@ to see what
> > changes need to be made (if any) and for more +1 votes (and less -0 votes)
> > in STATUS.
> >
> > Regarding your shell script, please review the regression test in HEAD of
> > trunk to ensure it captures the desired behaviour.
> >
> > Daniel
>
> 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
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)
Re: Oh, shoot: Issue 2591 should not have been closed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
This came across as a very negative tone. (I assume you had read the
comments in the issue)
It's nominated for backport. There was a dev@ thread asking if it should
get some (fairly trivial to implement) changes before being backported.
The thread concluded, but the branches/1.6.x/STATUS entry is still marked
"waiting for thread to resolve".
If you'd like to move this forward, you can ask on dev@ to see what
changes need to be made (if any) and for more +1 votes (and less -0 votes)
in STATUS.
Regarding your shell script, please review the regression test in HEAD of
trunk to ensure it captures the desired behaviour.
Daniel
Nico Kadel-Garcia wrote on Fri, 25 Jun 2010 at 15:08 -0000:
> Good morning:
>
> This is Nico Kadel-Garcia, the person who submitted the svnadmin
> hotcopy/symlink issue number 2591 in 2006. I see that it's been very
> recently marked "resolved". This is not fixed in the recent 1.6.12
> release, I'm sad to say.
>
> This bug has been a pain in my backside for 4 years. Can we seriously
> encourage its inclusion in 1.6.13, at least?
>
> I've also included a somewhat more robust test script below, to verify
> that the symlinks are duplicated and they point to the same place.
>
> ========================================
>
> #!/bin/sh
> #
> # test-hotcopy-hardlink.sh - verify svnadmin hotcopy preservation of symlinks
>
> REPO1=/tmp/repo1
> REPO2=/tmp/repo2
>
> rm -rf $REPO1 $REPO2 || exit 1
> svnadmin create $REPO1
> /bin/mv $REPO1/conf/passwd $REPO1/conf/passwd.template
> ln -s $REPO1/conf/passwd.template $REPO1/conf/passwd
> svnadmin hotcopy $REPO1 $REPO2
> readlink $REPO1/conf/passwd
> if [ ! -h $REPO2/conf/passwd ]; then
> echo "Error: svnadmin hotcopy fails to duplicate symlinks in repository"
> exit 1
> elif [ "`readlink $REPO1/conf/passwd`" != "`readlink
> $REPO2/conf/passwd`" ]; then
> echo "Error: svnadmin hotcopy gets symlinks wrong in repository"
> exit 1
> fi
>
>