Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago I couldn't get this to happen on 10.5.4.
However, the crash logs were quite helpful and I hope I've fixed it in r102.Original comment by chris...@gmail.com on 22 May 2009 at 10:22
GoogleCodeExporter
commented
9 years ago Maybe this is only happening with large WC.
I have a WC with 2000+ files.
This time tried on an Intel Mac.
I did not get a crash with the WC for svnX :)Original comment by kim.take...@gmail.com on 25 May 2009 at 9:06
Attachments:
GoogleCodeExporter
commented
9 years ago It seems OK if I don't change view mode while svnX is refreshing.
Original comment by kim.take...@gmail.com on 26 May 2009 at 1:08
GoogleCodeExporter
commented
9 years ago I finally managed to track this down. I was able to reproduce it, eventually,
in a working copy with 52,000 items!
It took me all night, but once I could reproduce it - it was just a matter of
time.
The problem was related to memory corruption due to the tree view using stale
info. The bug was exposed when I
fixed a memory leak. Unfortunately the crash logs were a bit misleading as the
crash could happen long after the
error.
It all stems from the asynchronous nature of the old use of the svn tool. I
highly recommend enabling 'Call
Subversion libraries directly' if at all possible.
Thanks for your input. Fixed in r108.
[BTW It's often useful to also report any Console output before a crash. If
you hate what Apple have done to the
Console in 10.5 then leave `tail -F /var/log/system.log` running in a Terminal
window.]
Original comment by chris...@gmail.com on 26 May 2009 at 10:12
GoogleCodeExporter
commented
9 years ago That's a big working copy!
Thank you for your night and the fix.
I am sorry about the misleading log.
I still see a glitch, but let's forget about it :)
The reason why I am trying the option disabled is becuase I want to have svnX
work
with MacPort version of svn installed under /opt/local/bin while having the
automatic
refreshing work.
I am trying to link some directories under /opt/local/ to /opt/subversion/ and
mostly
it seems to work, but sometimes a library complains that it cannot find another
library which it depends on.
I wonder if it is possible to choose a specific location for the libraries to
link
dynamically.
Original comment by kim.take...@gmail.com on 28 May 2009 at 9:03
GoogleCodeExporter
commented
9 years ago It logs where it crashes. It's not your fault. Your feedback & help is
appreciated.
If there's still a glitch please report it.
It may be a bug, it may be a limitation of the current model.
You can always mark it 'Priority-Low' and I can mark it 'WontFix' :-).
SvnX should work with ANY installation of Subversion.
The 'auto refresh' is separate from 'call directly' and should work fully
without it.
[However, 'call directly' does make 'auto refresh' almost invisible due to the
5-10 x speed improvement.]
Since r100 it should be possible to make svnX use svn libs installed in
locations other than
/opt/subversion/lib by changing the symbolic links in
svnX.app/Contents/Frameworks.
[However, this may require some experimentation & further revision i.e. it's
untested.]
Use `otool -L <binary-or-dylib>` to find where binaries expect libs to be.
Original comment by chris...@gmail.com on 28 May 2009 at 2:14
GoogleCodeExporter
commented
9 years ago OK!
I have tried to reproduce the glitch on my Intel configuration, but the 'call
directly' option is grayed out (dimmed.)
If I changed the path to /usr/bin/ then the option is comming back, although I
cannot
try with this installation (1.4.4) since my working copies are converted to
1.6.0.
Any way, I guess the option is off, and was able to reproduce.Original comment by kim.take...@gmail.com on 28 May 2009 at 9:34
Original issue reported on code.google.com by
kim.take...@gmail.comon 22 May 2009 at 4:29Attachments: