Crash when reverting single / selected files

With SmartSVN v8.5.4 on windows I get crashes every time I try to revert a local (single...multiple) file. It seems (!) not to happen if I revert complete directories, but If I try a single file it produces a bug report as following:  85956927 Thread[WorkerThread-68,2,main] starting runnable @14557BE  85957237 Thread[WorkerThread-68,2,main] Error processing runnable  85957237 Thread[WorkerThread-68,2,main] null  smartsvn.cr   at smartsvn.axB.a(SourceFile:166)   at smartsvn.auq.a(SourceFile:72)   at smartsvn.auq.compare(SourceFile:67)   at java.util.TreeMap.getEntryUsingComparator(Unknown Source)   at java.util.TreeMap.getEntry(Unknown Source)   at java.util.TreeMap.get(Unknown Source)   at smartsvn.aup.a(SourceFile:147)   at smartsvn.aup.a(SourceFile:136)   at smartsvn.amN.doStatus(SourceFile:70)   at org.apache.subversion.javahl.SVNClient.status(Native Method)   at smartsvn.Tj.status(SourceFile:67)   at smartsvn.Ss.a(SourceFile:1222)   at smartsvn.Ss.a(SourceFile:1217)   at smartsvn.Sd.a(SourceFile:1679)   at smartsvn.Sd.a(SourceFile:1652)   at smartsvn.Sd.a(SourceFile:1217)   at smartsvn.Sd.a(SourceFile:809)   at smartsvn.aux.b(SourceFile:121)   at smartsvn.aux.a(SourceFile:76)   at smartsvn.amI.a(SourceFile:96)   at smartsvn.amI.a(SourceFile:61)   at smartsvn.Tx.a(SourceFile:116)   at smartsvn.aFK.a(SourceFile:61)   at smartsvn.aFF.a(SourceFile:103)   at smartsvn.pE.run(SourceFile:35)   at smartsvn.aFE.run(SourceFile:56)   at smartsvn.pk.run(SourceFile:53)  85957237 Thread[WorkerThread-68,2,main] Exception occurred  85957237 Thread[WorkerThread-68,2,main] null  smartsvn.cr   at smartsvn.axB.a(SourceFile:166)   at smartsvn.auq.a(SourceFile:72)   at smartsvn.auq.compare(SourceFile:67)   at java.util.TreeMap.getEntryUsingComparator(Unknown Source)   at java.util.TreeMap.getEntry(Unknown Source)   at java.util.TreeMap.get(Unknown Source)   at smartsvn.aup.a(SourceFile:147)   at smartsvn.aup.a(SourceFile:136)   at smartsvn.amN.doStatus(SourceFile:70)   at org.apache.subversion.javahl.SVNClient.status(Native Method)   at smartsvn.Tj.status(SourceFile:67)   at smartsvn.Ss.a(SourceFile:1222)   at smartsvn.Ss.a(SourceFile:1217)   at smartsvn.Sd.a(SourceFile:1679)   at smartsvn.Sd.a(SourceFile:1652)   at smartsvn.Sd.a(SourceFile:1217)   at smartsvn.Sd.a(SourceFile:809)   at smartsvn.aux.b(SourceFile:121)   at smartsvn.aux.a(SourceFile:76)   at smartsvn.amI.a(SourceFile:96)   at smartsvn.amI.a(SourceFile:61)   at smartsvn.Tx.a(SourceFile:116)   at smartsvn.aFK.a(SourceFile:61)   at smartsvn.aFF.a(SourceFile:103)   at smartsvn.pE.run(SourceFile:35)   at smartsvn.aFE.run(SourceFile:56)   at smartsvn.pk.run(SourceFile:53)  

Last updated 8 years ago

Hi there,  I've raised this for you internally, I'll let you know when we get an update - this is the only report we've seen of this issue so if you hear of any more please let us know.

Hi,  Our developers are looking at this for you, but would like to see the results of a couple of commands if you could paste them into this thread please? The commands are:  svn status  dir /AL /S using command prompt in the root of the working copy  Also, are there any special circumstances you can think of in the working environment there? In particular are any of the files in your working copy showing as case-changed?  Thanks very much, this will help us get to the bottom of what's going on.

orbrey;168834svn status[/QUOTE]  Sorry, I cannot do this - its a business repo so the file names should not be posted.  However, instead I did a complete new checkout of the repo but the problem persists.  From the structure I have two external links and 2 embedded other working copies (checked them out into a sub-folder of the main working copy). But I am trying to revert within the main working copy.    

orbrey;168834dir /AL /S

 Reveals nothing: "File not found."    [QUOTE=orbrey;168834]any special circumstances

 Well this should have been resolved with a fresh checkout. Besides there is nothing obvious special. To try, I've checked out the repo on another computer with the same Windows operating system and tooling and it works there.    Summing up it may in fact have to do with the environment of this specific PC. Now the question is what is it? But thats probably something beyond your capabilities unless you have a magic ball.    The other way round: Can you tell me what the crash means and why/at which operation it happens?    BTW: I don't check here regularly so please be patient with my answers... sorry for that.

The stack trace shows that SmartSVN for some reason thinks that the root of the working copy is unversioned for some reason - or possibly that some other path within the working copy is being incorrectly reported as /, though it's not obvious why this is the case - that's why I asked about the special circumstances (thinking things like externals, nested WCs, switched parts of the WC, symlinks or using a network share to store the working copy).  Having said that one of our developers is suspicious of the 2 embedded working copies - were they the same on the fresh working copy you checked out? They might be better also being defined as externals rather than embedding separate working copies in there.  Hope that sheds some light on things?

Thanks again for the feedback. The layout is as following: The folder contains 3 working copies (WC) from 3 addresses/repos all hosted on 1 server:  ROOT_WC: svn://server/repo1 - folder_1_from_repo1... - folder_2_from_repo1... - (...) - EMBEDDED_WC_FOLDER1: svn://server/repo2 - EMBEDDED_WC_FOLDER2: svn://server/repo3 - folder_x_from_repo1...  When I update the ROOT folder it correctly updates the top-level WS as the embedded ones are not declared as external.  There is a reason for not defining the embedded WSes as external: No all people that can access repo1 have access to repo2 and repo3 (these are libraries). Therefore for these people, checking out repo1 would otherwise result in an error.  There is a reason for embedding the folders of repo2 and repo3 like that: It eases the build process as relative paths can be used for these libraries that resolve to files in repo1.  If that is the root of the issue (and in fact that is the ONLY PC with these additional WS folders - good catch!) I could try to revert without these embedded folders and see if that woul NOT fail... I'll report back once I have access to this PC again.  However, from my humble opinion such a folder structure should be OK.

Just to complete this topic: I can confirm that removing the embedded workspaces will make the crash disappear.  Still I would like to consider this as a bug because I see no reason why it should crash SmartSVN. However, I do see reasons to have a folder structure like that. Furthermore it works in previous versions, btw.  I would be happy if you could consider to support embedded workspaces.  Thank you!

Well, it's not that we don't - one of our developers tried to replicate your issue with nested working copies and was unable to, so we were wondering if there's some sort of case changed issue there as well?

orbrey;168923Well, it's not that we don't - one of our developers tried to replicate your issue with nested working copies and was unable to, so we were wondering if there's some sort of case changed issue there as well?

 No, no case changed files. (They would appear in "Changed files", right?)

No - I mean in the sense that different operating systems handle capital letters in file systems differently (i.e. in Windows, 'file' and 'File' are both regarded as the same filename because it's not case sensitive whereas in Linux, they'd be two different files).

Well I am on Windows. And as the WS'es are in different folders there should be no case change issue.  I've tried the v8.6 RC2 early access version because I read about some changes that I thought are related to this topic. Unfortunately the error is the same. The only difference is a new dialog asking me to send the bug report directly.  Let me know if you need further details. I would love to see this resolved because it is really annoying. It happens to me nearly every day. However - as I've mentioned as well there are good reason not to change the layout so that it would work with SmartSVN. I expect SmartSVN to be... erm... smarter. :-)

Still no joy with v8.6 (release). I had to buy an updated for my license to try. My old one was not longer working with this update. Interesting to notice that it did with RC2... ;-)

Well, I can explain the license - it's the General Access releases that require a current license, the release candidates will work with ones that are expired I believe.

Bump. :-)  Well the crash persists and remains very annoying. Whats your position on this? Do you give up? Can you reproduce? Do you need more details? Is it not important enough?  Here is again the crash log of a more recent SmartSVN v8.6:  94516183 Thread[WorkerThread-88,2,main] Collecting changes, pending trigger file count is 0 (latestSeq=488628) 94516184 Thread[WorkerThread-88,2,main] Collecting changes finished (latestSeq=488629) 94516184 Thread[WorkerThread-88,2,main] Firing 1 changes for [...] to 4 listeners (maxSeq=488627;latestSeq=488630) 94516235 Thread[WorkerThread-88,2,main] Scanning [...] took 17ms (lap=17, properties=true, file-system-data=true) 94517218 Thread[WorkerThread-88,2,main] Error processing runnable 94517218 Thread[WorkerThread-88,2,main] null smartsvn.cR  at smartsvn.ayv.a(SourceFile:166)  at smartsvn.avm.a(SourceFile:72)  at smartsvn.avm.compare(SourceFile:67)  at java.util.TreeMap.getEntryUsingComparator(Unknown Source)  at java.util.TreeMap.getEntry(Unknown Source)  at java.util.TreeMap.get(Unknown Source)  at smartsvn.avl.a(SourceFile:147)  at smartsvn.avl.a(SourceFile:136)  at smartsvn.anz.doStatus(SourceFile:75)  at org.apache.subversion.javahl.SVNClient.status(Native Method)  at smartsvn.TQ.status(SourceFile:67)  at smartsvn.SZ.a(SourceFile:1222)  at smartsvn.SZ.a(SourceFile:1217)  at smartsvn.SL.a(SourceFile:1679)  at smartsvn.SL.a(SourceFile:1652)  at smartsvn.SL.a(SourceFile:1217)  at smartsvn.SL.a(SourceFile:809)  at smartsvn.avt.b(SourceFile:121)  at smartsvn.avt.a(SourceFile:76)  at smartsvn.anu.a(SourceFile:96)  at smartsvn.anu.a(SourceFile:61)  at smartsvn.Ue.a(SourceFile:116)  at smartsvn.aGF.a(SourceFile:61)  at smartsvn.aGA.a(SourceFile:103)  at smartsvn.qd.run(SourceFile:35)  at smartsvn.aGz.run(SourceFile:56)  at smartsvn.pJ.run(SourceFile:53) 94517218 Thread[WorkerThread-88,2,main] Exception occurred 94517218 Thread[WorkerThread-88,2,main] null smartsvn.cR  at smartsvn.ayv.a(SourceFile:166)  at smartsvn.avm.a(SourceFile:72)  at smartsvn.avm.compare(SourceFile:67)  at java.util.TreeMap.getEntryUsingComparator(Unknown Source)  at java.util.TreeMap.getEntry(Unknown Source)  at java.util.TreeMap.get(Unknown Source)  at smartsvn.avl.a(SourceFile:147)  at smartsvn.avl.a(SourceFile:136)  at smartsvn.anz.doStatus(SourceFile:75)  at org.apache.subversion.javahl.SVNClient.status(Native Method)  at smartsvn.TQ.status(SourceFile:67)  at smartsvn.SZ.a(SourceFile:1222)  at smartsvn.SZ.a(SourceFile:1217)  at smartsvn.SL.a(SourceFile:1679)  at smartsvn.SL.a(SourceFile:1652)  at smartsvn.SL.a(SourceFile:1217)  at smartsvn.SL.a(SourceFile:809)  at smartsvn.avt.b(SourceFile:121)  at smartsvn.avt.a(SourceFile:76)  at smartsvn.anu.a(SourceFile:96)  at smartsvn.anu.a(SourceFile:61)  at smartsvn.Ue.a(SourceFile:116)  at smartsvn.aGF.a(SourceFile:61)  at smartsvn.aGA.a(SourceFile:103)  at smartsvn.qd.run(SourceFile:35)  at smartsvn.aGz.run(SourceFile:56)  at smartsvn.pJ.run(SourceFile:53) -- BEGIN STACKTRACE -- smartsvn.cR  at smartsvn.ayv.a(SourceFile:166)  at smartsvn.avm.a(SourceFile:72)  at smartsvn.avm.compare(SourceFile:67)  at java.util.TreeMap.getEntryUsingComparator(Unknown Source)  at java.util.TreeMap.getEntry(Unknown Source)  at java.util.TreeMap.get(Unknown Source)  at smartsvn.avl.a(SourceFile:147)  at smartsvn.avl.a(SourceFile:136)  at smartsvn.anz.doStatus(SourceFile:75)  at org.apache.subversion.javahl.SVNClient.status(Native Method)  at smartsvn.TQ.status(SourceFile:67)  at smartsvn.SZ.a(SourceFile:1222)  at smartsvn.SZ.a(SourceFile:1217)  at smartsvn.SL.a(SourceFile:1679)  at smartsvn.SL.a(SourceFile:1652)  at smartsvn.SL.a(SourceFile:1217)  at smartsvn.SL.a(SourceFile:809)  at smartsvn.avt.b(SourceFile:121)  at smartsvn.avt.a(SourceFile:76)  at smartsvn.anu.a(SourceFile:96)  at smartsvn.anu.a(SourceFile:61)  at smartsvn.Ue.a(SourceFile:116)  at smartsvn.aGF.a(SourceFile:61)  at smartsvn.aGA.a(SourceFile:103)  at smartsvn.qd.run(SourceFile:35)  at smartsvn.aGz.run(SourceFile:56)  at smartsvn.pJ.run(SourceFile:53) -- END STACKTRACE --

Hi, realise it's been a while, sorry about that. The issue is that we've not been able to replicate it, even with embedded workspaces configured in the setup, so there must be something different in the way we're setting things up from how yours are configured, and the stacktraces don't show anything along those lines. You've even said it only happens on that one PC, so it's not something that's going to be easy to catch and probably not something we can actually find for you - I guess there's nothing obvious that stands out as being different on that PC from any others?