Re: Subversion crash report

[Stefan Hett]

Hi James,

without knowing which client you are using it's a bit difficult to dig 
into this problem.
From the logs I can only get your command line, working directory, 
version number (1.9.2) and see that you are using a 32-bit build:
Cmd line: "C:\MyScripts\SVN\svn.exe"  merge 
svn://oit-teaqasocfs1.som.w2k.state.me.us/MACWIS/branches/Verona/MACWIS 
--accept tc

Working Dir: C:\SVN_Play\z-our-server\trunk\MACWIS


Stacktrace:

#1  0x6eec60b0 in apr_file_mktemp()
#2  0x6eec66d1 in apr_file_open()
#3  0x5e55ada1 in svn_mergeinfo__filter_catalog_by_ranges()
#4  0x6eec7c2b in apr_file_read()
#5  0x6eec5d71 in apr_file_read_full()
#6  0x6dc279e3 in svn_diff_diff_2()

EAX: 0

If I were you, I'd retry the test first with the more recent 1.9.3 version.


Hello,

Attached please find a crash report during an attempt to merge 
something to a trunk.


James C Patten

Senior Programmer/Analyst, OIT OCFS/DLRS

State of Maine, Office of Information Technology

james.pat...@maine.gov 

207-557-0349 (Desk/Cell)




--
Regards,
Stefan Hett

Debian Linux 32 vs. 64 bit

[Niemann, Hartmut]

Hello!

I want to upgrade my Linux box from Debian Jessie (32bit) to Debian Jessie 
(64bit).
For the transition time, the machine will boot alternating the 32bit and the 
64bit OS.
I have several SVN repositories and working copies on it.

Is it safe to share SVN repositories and working copies between 32bit and 64 
bit?

(Jessie ships with 1.8.10, as far as I know.)

Mit freundlichen Grüßen
Dr. Hartmut Niemann

Siemens AG
MO MLT LM EN CCI 1
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel.: +49 9131 7-34264
Fax: +49 9131 7-26254
mailto:hartmut.niem...@siemens.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; 
Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, 
Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Sitz der Gesellschaft: Berlin 
und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, 
München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

Re: Subversion crash report

[Stefan Hett]

Hi James,


Stefan,

Windows client, using a Powershell script running the svn command 
line.  I am running 64-bit Windows 7, running it in Powershell 4.  I 
use the 32-bit build because only developers have 64-bit windows.


James

*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* Monday, January 25, 2016 5:25 AM
*To:* Patten, James; users@subversion.apache.org
*Subject:* Re: Subversion crash report

Hi James,

without knowing which client you are using it's a bit difficult to dig 
into this problem.
>From the logs I can only get your command line, working directory, 
version number (1.9.2) and see that you are using a 32-bit build:
Cmd line: "C:\MyScripts\SVN\svn.exe"  merge 
svn://oit-teaqasocfs1.som.w2k.state.me.us/MACWIS/branches/Verona/MACWIS --accept 
tc

Working Dir: C:\SVN_Play\z-our-server\trunk\MACWIS


Stacktrace:

#1  0x6eec60b0 in apr_file_mktemp()
#2  0x6eec66d1 in apr_file_open()
#3  0x5e55ada1 in svn_mergeinfo__filter_catalog_by_ranges()
#4  0x6eec7c2b in apr_file_read()
#5  0x6eec5d71 in apr_file_read_full()
#6  0x6dc279e3 in svn_diff_diff_2()

EAX: 0

If I were you, I'd retry the test first with the more recent 1.9.3 
version.


Hello,

Attached please find a crash report during an attempt to merge
something to a trunk.

James C Patten

Senior Programmer/Analyst, OIT OCFS/DLRS

State of Maine, Office of Information Technology

james.pat...@maine.gov 

207-557-0349 (Desk/Cell)

please always reply to the list as well, since while I might provide the 
first ideas/info, others might be better with helping with the actual 
problem at hand.


By "which client" I rather meant which distribution you are using. 
Apache Subversion does not provide any binaries itself, so you must be 
using either some distribution or use your own compiled binaries.


I'm asking because if the symbols would be available for the dump you 
provided, it could be easier to debug the problem.


--
Regards,
Stefan Hett

RE: Subversion crash report

[Patten, James]

Sorry.  I'm using the distribution from Collabnet.

From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: Monday, January 25, 2016 7:30 AM
To: Patten, James
Cc: 'subversion'
Subject: Re: Subversion crash report

Hi James,
Stefan,

Windows client, using a Powershell script running the svn command line.  I am 
running 64-bit Windows 7, running it in Powershell 4.  I use the 32-bit build 
because only developers have 64-bit windows.

James

From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: Monday, January 25, 2016 5:25 AM
To: Patten, James; 
users@subversion.apache.org
Subject: Re: Subversion crash report

Hi James,

without knowing which client you are using it's a bit difficult to dig into 
this problem.
>From the logs I can only get your command line, working directory, version 
>number (1.9.2) and see that you are using a 32-bit build:
Cmd line: "C:\MyScripts\SVN\svn.exe"  merge 
svn://oit-teaqasocfs1.som.w2k.state.me.us/MACWIS/branches/Verona/MACWIS 
--accept tc
Working Dir: C:\SVN_Play\z-our-server\trunk\MACWIS


Stacktrace:

#1  0x6eec60b0 in apr_file_mktemp()
#2  0x6eec66d1 in apr_file_open()
#3  0x5e55ada1 in svn_mergeinfo__filter_catalog_by_ranges()
#4  0x6eec7c2b in apr_file_read()
#5  0x6eec5d71 in apr_file_read_full()
#6  0x6dc279e3 in svn_diff_diff_2()

EAX: 0

If I were you, I'd retry the test first with the more recent 1.9.3 version.
Hello,

Attached please find a crash report during an attempt to merge something to a 
trunk.

James C Patten
Senior Programmer/Analyst, OIT OCFS/DLRS
State of Maine, Office of Information Technology
james.pat...@maine.gov
207-557-0349 (Desk/Cell)
please always reply to the list as well, since while I might provide the first 
ideas/info, others might be better with helping with the actual problem at hand.

By "which client" I rather meant which distribution you are using. Apache 
Subversion does not provide any binaries itself, so you must be using either 
some distribution or use your own compiled binaries.

I'm asking because if the symbols would be available for the dump you provided, 
it could be easier to debug the problem.



--

Regards,

Stefan Hett

RE: Modifying SVN Externals with Specific Revision

[Crast, Nicholas]

Thanks Daniel!

Exactly the information I was looking for. 

For anyone else in the future, there is more information here:
https://people.apache.org/~brane/svndocs/capi/group__Commit.html

-Nick


Nick Crast
Software Engineer
Saab Sensis Corporation
Phone: 315-445-5703
Email: nicholas.cr...@saabsensis.com


-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Saturday, January 23, 2016 7:00 PM
To: Crast, Nicholas
Cc: users@subversion.apache.org
Subject: Re: Modifying SVN Externals with Specific Revision

Crast, Nicholas wrote on Wed, Jan 20, 2016 at 21:05:51 +:
> This is, in fact, the behavior I want. I just want to know if it's 
> guaranteed that modifications to external directories with a specific 
> revisions will not be committed.

It is an explicit API promise of svn_client_commit6():

 * If @a include_file_externals and/or @a include_dir_externals are #TRUE,
 * also commit all file and/or dir externals (respectively) that are reached
 * by recursion, except for those externals which:
 * - have a fixed revision, or
 * - come from a different repository root URL (dir externals).
 * These flags affect only recursion; externals that directly appear in @a
 * targets are always included in the commit.

Cheers,

Daniel
-
This message is intended only for the addressee and may contain information 
that is company confidential or privileged.  Any technical data in this message 
may be exported only in accordance with the U.S. International Traffic in Arms 
Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 
CFR Parts 730-774). Unauthorized use is strictly prohibited and may be 
unlawful. If you are not the intended recipient, or the person responsible for 
delivering to the intended recipient, you should not read, copy, disclose or 
otherwise use this message. If you have received this email in error, please 
delete it, and advise the sender immediately. 
-  

Re: Subversion crash report

[Stefan Hett]

Sorry.  I’m using the distribution from Collabnet.

*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* Monday, January 25, 2016 7:30 AM
*To:* Patten, James
*Cc:* 'subversion'
*Subject:* Re: Subversion crash report

Hi James,

Stefan,

Windows client, using a Powershell script running the svn command
line.  I am running 64-bit Windows 7, running it in Powershell 4. 
I use the 32-bit build because only developers have 64-bit windows.


James

*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* Monday, January 25, 2016 5:25 AM
*To:* Patten, James; users@subversion.apache.org

*Subject:* Re: Subversion crash report

Hi James,

without knowing which client you are using it's a bit difficult to
dig into this problem.
>From the logs I can only get your command line, working
directory, version number (1.9.2) and see that you are using a
32-bit build:
Cmd line: "C:\MyScripts\SVN\svn.exe"  merge
svn://oit-teaqasocfs1.som.w2k.state.me.us/MACWIS/branches/Verona/MACWIS
--accept tc
Working Dir: C:\SVN_Play\z-our-server\trunk\MACWIS


Stacktrace:

#1  0x6eec60b0 in apr_file_mktemp()
#2  0x6eec66d1 in apr_file_open()
#3  0x5e55ada1 in svn_mergeinfo__filter_catalog_by_ranges()
#4  0x6eec7c2b in apr_file_read()
#5  0x6eec5d71 in apr_file_read_full()
#6  0x6dc279e3 in svn_diff_diff_2()

EAX: 0

If I were you, I'd retry the test first with the more recent 1.9.3
version.

Hello,

Attached please find a crash report during an attempt to merge
something to a trunk.

James C Patten

Senior Programmer/Analyst, OIT OCFS/DLRS

State of Maine, Office of Information Technology

james.pat...@maine.gov 

207-557-0349 (Desk/Cell)

please always reply to the list as well, since while I might provide 
the first ideas/info, others might be better with helping with the 
actual problem at hand.


By "which client" I rather meant which distribution you are using. 
Apache Subversion does not provide any binaries itself, so you must be 
using either some distribution or use your own compiled binaries.


I'm asking because if the symbols would be available for the dump you 
provided, it could be easier to debug the problem.


Unfortunately I'm a bit stuck here, since I don't have access to the 
CollabNet symbol files. Maybe you can try to reproduce the issue with 
SilkSVN: https://sliksvn.com/download/ and attach the dmp file of the 
crash when testing with their version?


--
Regards,
Stefan Hett

RE: Subversion crash report

[Patten, James]

I downloaded SlikSVN and installed it, using the Typical installation.  I then 
copied the DLLs and EXEs from C:\Program Files (x86)\SlikSvn\bin to 
C:\MyScripts\SVN2 so that it was easier to type the address, and ran the merge 
again.  It crashed.  I have included the log files as you requested.

James

From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: Monday, January 25, 2016 10:58 AM
To: Patten, James
Cc: 'subversion'
Subject: Re: Subversion crash report


Sorry.  I'm using the distribution from Collabnet.

From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: Monday, January 25, 2016 7:30 AM
To: Patten, James
Cc: 'subversion'
Subject: Re: Subversion crash report

Hi James,
Stefan,

Windows client, using a Powershell script running the svn command line.  I am 
running 64-bit Windows 7, running it in Powershell 4.  I use the 32-bit build 
because only developers have 64-bit windows.

James

From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: Monday, January 25, 2016 5:25 AM
To: Patten, James; 
users@subversion.apache.org
Subject: Re: Subversion crash report

Hi James,

without knowing which client you are using it's a bit difficult to dig into 
this problem.
>From the logs I can only get your command line, working directory, version 
>number (1.9.2) and see that you are using a 32-bit build:
Cmd line: "C:\MyScripts\SVN\svn.exe"  merge 
svn://oit-teaqasocfs1.som.w2k.state.me.us/MACWIS/branches/Verona/MACWIS 
--accept tc
Working Dir: C:\SVN_Play\z-our-server\trunk\MACWIS


Stacktrace:

#1  0x6eec60b0 in apr_file_mktemp()
#2  0x6eec66d1 in apr_file_open()
#3  0x5e55ada1 in svn_mergeinfo__filter_catalog_by_ranges()
#4  0x6eec7c2b in apr_file_read()
#5  0x6eec5d71 in apr_file_read_full()
#6  0x6dc279e3 in svn_diff_diff_2()

EAX: 0

If I were you, I'd retry the test first with the more recent 1.9.3 version.
Hello,

Attached please find a crash report during an attempt to merge something to a 
trunk.

James C Patten
Senior Programmer/Analyst, OIT OCFS/DLRS
State of Maine, Office of Information Technology
james.pat...@maine.gov
207-557-0349 (Desk/Cell)
please always reply to the list as well, since while I might provide the first 
ideas/info, others might be better with helping with the actual problem at hand.

By "which client" I rather meant which distribution you are using. Apache 
Subversion does not provide any binaries itself, so you must be using either 
some distribution or use your own compiled binaries.

I'm asking because if the symbols would be available for the dump you provided, 
it could be easier to debug the problem.
Unfortunately I'm a bit stuck here, since I don't have access to the CollabNet 
symbol files. Maybe you can try to reproduce the issue with SilkSVN: 
https://sliksvn.com/download/ and attach the dmp file of the crash when testing 
with their version?



--

Regards,

Stefan Hett


svn-crash-log20160125114827.dmp
Description: svn-crash-log20160125114827.dmp


svn-crash-log20160125114828.log
Description: svn-crash-log20160125114828.log

Re: Debian Linux 32 vs. 64 bit

[David Chapman]

On 1/25/2016 3:59 AM, Niemann, Hartmut wrote:


Hello!

I want to upgrade my Linux box from Debian Jessie (32bit) to Debian 
Jessie (64bit).


For the transition time, the machine will boot alternating the 32bit 
and the 64bit OS.


I have several SVN repositories and working copies on it.

Is it safe to share SVN repositories and working copies between 32bit 
and 64 bit?


(Jessie ships with 1.8.10, as far as I know.)




I wouldn't try this approach for a machine with repositories.  I had a 
repository on a 64-bit Linux machine, then bought a 32-bit micro server 
that I could keep running all the time.  I was unable to copy the 
repository directory tree directly, even though both were Intel 
architecture machines.  I had to dump and load (with svnadmin).  I'd be 
surprised if this has changed in the last three years.


It is possible that the working copies would be OK, but I haven't tried 
that migration path.  I'd worry that there are binary files in the 
working copy format as well (e.g. SQLite), and these might have native 
long integers which will switch from 32 to 64 bits on Linux machines.


I just did a 32-bit to 32-bit migration, and I found that the safest 
approach was to have a separate machine (or at least a separate hard 
drive) so that I always had a stable system running.  I took the 
original offline only after the new one was running and stable.


--
David Chapman  dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com

Re: Subversion crash report

[Stefan Hett]

Hi James,


I downloaded SlikSVN and installed it, using the Typical 
installation.  I then copied the DLLs and EXEs from C:\Program Files 
(x86)\SlikSvn\bin to C:\MyScripts\SVN2 so that it was easier to type 
the address, and ran the merge again.  It crashed. I have included the 
log files as you requested.


Thanks for the dump. Looking at the corresponding code sections suggest 
that the crash might not occur with the 64-bit binaries. Any chance you 
could try such a build? I'd expect you'd get some error in this case 
which should be a useful lead to the underlying problem.


--
Regards,
Stefan Hett

Re: Debian Linux 32 vs. 64 bit

[Philip Martin]

David Chapman  writes:

> On 1/25/2016 3:59 AM, Niemann, Hartmut wrote:
>>
>> I want to upgrade my Linux box from Debian Jessie (32bit) to Debian
>> Jessie (64bit).
>>
>> For the transition time, the machine will boot alternating the 32bit
>> and the 64bit OS.
>>
>> I have several SVN repositories and working copies on it.
>>
>> Is it safe to share SVN repositories and working copies between
>> 32bit and 64 bit?
>>
>> (Jessie ships with 1.8.10, as far as I know.)

It should just work for both repositories and working copies.

> I wouldn't try this approach for a machine with repositories.  I had a
> repository on a 64-bit Linux machine, then bought a 32-bit micro
> server that I could keep running all the time.  I was unable to copy
> the repository directory tree directly, even though both were Intel
> architecture machines.  I had to dump and load (with svnadmin).  I'd
> be surprised if this has changed in the last three years.

It's hard to work out what went wrong from that vague description.  In
the unlikely event that you were using a BDB repository then there are
BDB library compatibility issues: a recover/upgrade may be needed and 
downgrading to older BDB is not always possible.

-- 
Philip Martin
WANdisco

RE: Subversion crash report

[Patten, James]

I uninstalled the old SlikSVN, and installed the new 64-bit SlikSVN, using 
Typical installation.  Again, copied the DLLs and EXEs to another location for 
each of typing the address.  After reverting and cleaning up from the prior 
merge, I ran  the merge again.  It crashed at the same location as last time.  
Log files are included.

From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: Monday, January 25, 2016 1:37 PM
To: Patten, James
Cc: 'subversion'
Subject: Re: Subversion crash report

Hi James,
I downloaded SlikSVN and installed it, using the Typical installation.  I then 
copied the DLLs and EXEs from C:\Program Files (x86)\SlikSvn\bin to 
C:\MyScripts\SVN2 so that it was easier to type the address, and ran the merge 
again.  It crashed.  I have included the log files as you requested.
Thanks for the dump. Looking at the corresponding code sections suggest that 
the crash might not occur with the 64-bit binaries. Any chance you could try 
such a build? I'd expect you'd get some error in this case which should be a 
useful lead to the underlying problem.



--

Regards,

Stefan Hett


svn-crash-log20160125134649.dmp
Description: svn-crash-log20160125134649.dmp


svn-crash-log20160125134649.log
Description: svn-crash-log20160125134649.log

Re: Debian Linux 32 vs. 64 bit

[David Chapman]

On 1/25/2016 10:45 AM, Philip Martin wrote:

David Chapman  writes:


On 1/25/2016 3:59 AM, Niemann, Hartmut wrote:

I want to upgrade my Linux box from Debian Jessie (32bit) to Debian
Jessie (64bit).

For the transition time, the machine will boot alternating the 32bit
and the 64bit OS.

I have several SVN repositories and working copies on it.

Is it safe to share SVN repositories and working copies between
32bit and 64 bit?

(Jessie ships with 1.8.10, as far as I know.)

It should just work for both repositories and working copies.


Is that documented somewhere, such that system administrators can rely 
on it?  Or could a Subversion developer decide to put endian- or 
size-dependent binary data into a repository or working copy file somewhere?



I wouldn't try this approach for a machine with repositories.  I had a
repository on a 64-bit Linux machine, then bought a 32-bit micro
server that I could keep running all the time.  I was unable to copy
the repository directory tree directly, even though both were Intel
architecture machines.  I had to dump and load (with svnadmin).  I'd
be surprised if this has changed in the last three years.

It's hard to work out what went wrong from that vague description.  In
the unlikely event that you were using a BDB repository then there are
BDB library compatibility issues: a recover/upgrade may be needed and
downgrading to older BDB is not always possible.



My notes are vague, unfortunately.  This was back in 2007, when I was 
compiling from tarballs:


1) configure/compile with BDB support on both platforms
2) copy repository directory to 32-bit machine
3) problem found -> dump/load to avoid system dependencies
4) problem solved
5) hey, my repositories are actually FSFS!

I was trying to take good notes, as is my practice for system 
administration tasks that I do once every three years, but somewhere in 
the migration process I failed to write something down.  Item 5) was 
recorded some weeks after the migration, so I don't know when the build 
switched to FSFS support only, relative to the repository directory 
move.  Nor do my notes record what actually got me to a 
production-worthy repository.  So yes, kind of vague.  But enough to get 
me spooked.


I also know from experience that it is very easy to let platform 
dependencies leak into outside data files.  Avoidance takes a concerted 
effort and detection is extremely difficult when testing a build on a 
single machine (here, by definition we're talking about running a single 
repository on two separate machines).  Thus my question about a 
documented promise from Subversion developers.


--
David Chapman  dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com

Re: Subversion crash report

[Stefan]

Hi James,


I uninstalled the old SlikSVN, and installed the new 64-bit SlikSVN, 
using Typical installation.  Again, copied the DLLs and EXEs to 
another location for each of typing the address.  After reverting and 
cleaning up from the prior merge, I ran  the merge again.  It crashed 
at the same location as last time. Log files are included.


*From:*Stefan Hett [mailto:ste...@egosoft.com]
*Sent:* Monday, January 25, 2016 1:37 PM
*To:* Patten, James
*Cc:* 'subversion'
*Subject:* Re: Subversion crash report

Hi James,

I downloaded SlikSVN and installed it, using the Typical
installation. I then copied the DLLs and EXEs from C:\Program
Files (x86)\SlikSvn\bin to C:\MyScripts\SVN2 so that it was easier
to type the address, and ran the merge again.  It crashed.  I have
included the log files as you requested.

Thanks for the dump. Looking at the corresponding code sections 
suggest that the crash might not occur with the 64-bit binaries. Any 
chance you could try such a build? I'd expect you'd get some error in 
this case which should be a useful lead to the underlying problem.


My bad. I misread the code section there. I see why it's crashing there 
for you, but I don't know enough about the SVN source to determine the 
root cause of the issue.


I'll pass on my findings to the developers to see if they can make out 
more sense of it.


Regards,
Stefan

Re: Debian Linux 32 vs. 64 bit

[Philip Martin]

David Chapman  writes:

> On 1/25/2016 10:45 AM, Philip Martin wrote:
>> It should just work for both repositories and working copies.
>
> Is that documented somewhere, such that system administrators can rely
> on it?

I don't know if it is explictly documented anywhere.  The closest I can
get is:

http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.basics.backends.tbl-1

> Or could a Subversion developer decide to put endian- or
> size-dependent binary data into a repository or working copy file
> somewhere?

It happens but should be removed, for an example see
http://svn.apache.org/r1573371

> My notes are vague, unfortunately.  This was back in 2007, when I was
> compiling from tarballs:
>
> 1) configure/compile with BDB support on both platforms
> 2) copy repository directory to 32-bit machine
> 3) problem found -> dump/load to avoid system dependencies
> 4) problem solved
> 5) hey, my repositories are actually FSFS!

The BDB data files are portable but the BDB environment files are
platform dependent.  Switching platforms for BDB generally requires a
BDB recover operation to replace the BDB environment files, and may
require a BDB upgrade operation if the BDB library version changes.

FSFS repositories need no special operations.

-- 
Philip Martin
WANdisco

'svn status' reporting file not found when pathname contains an intermediate symlink

[Webster, Brent (Coriant - CA/Ottawa)]

I have a script within an absolute directory path: 
ots/osm1s/Target/sdcard/proj/test.sh
It exists:
  >> ls -I ots/osm1s/Target/sdcard/proj/test.sh
   1376926 ots/osm1s/Target/sdcard/proj/test.sh

   >> svn status ots/osm1s/Target/sdcard/proj/test.sh
   >>
   # i.e. no mods

An intermediate symlink is setup and created in
   >> cd ots/development
   >> ln -s ../osm1s OSM1S

>From a Linux perspective, this link is valid
  >> ls -I ots/development/OSM1S/Target/sdcard/proj/test.sh
   1376926 ots/development/OSM1S/Target/sdcard/proj/test.sh
   # i.e. the inode is the same

It is special:
  >> svn pl ots/development/OSM1S
  Properties on 'ots/development/OSM1S':
 svn:special

but when I query it
   >> svn status ots/development/OSM1S/Target/sdcard/proj/test.sh
   svn: warning: W155010: The node 
'/svn/xxx/aSymlinkBug/ots/development/OSM1S/Target/sdcard/proj/test.sh' was not 
found.

Note: Querying the status at the symlink reports nothing i.e no mods which is 
correct
  >> svn status ots/development/OSM1S
  >>

But as soon as I go past the symlink, the behaviour is erratic
  >> svn status ots/development/OSM1S/Target
  ?  ots/development/OSM1S/Target
  >> svn status ots/development/OSM1S/Target/sdcard
  svn: warning: W155010: The node 
'/svn/xxx/aSymlinkBug/ots/development/OSM1S/Target/sdcard' was not found.

This is not the symlink behaviour that I'm expecting in SVN or should I not be 
so picky

Environment setup:

-  OS: Red Hat Enterprise Linux Client release 5.9 (Tikanga)

-  svn: 1.8.14

-  binaries installed directly, we didn't build them

-  no private mods

-  no Berkeley DB

Yes, it is an old OS but welcome to big iron/telecom development

The following is my setup:
1/ create a new private branch called aSymlinkBug
   svn mkdir $svnnap/sdevolution/trunk/Sandbox/bwebster/aSymlinkBug

2/ then check it out
   svn co $svnnap/sdevolution/trunk/Sandbox/bwebster/aSymlinkBug

3/ Setup required structure
   >> cd aSymlinkBug
   >> mkdir -p ots/development
   >> mkdir -p ots/osm1s/Target/sdcard/proj
   >> cat >chmod 755 ots/osm1s/Target/sdcard/proj/test.sh

4/ Now, create the intermeidate symlink
   >> cd ots/development
   >> ln -s ../osm1s OSM1S

5/ Add everything and check it in
   >> cd ../..
   >> svn add ots
   >> svn commit -m "initial bug setup"


Brent Webster