My 4th separate crash issue on commit

Jan 1, 2008 at 1:16 AM
Edited Jan 1, 2008 at 6:48 AM
I'm finding it difficult to believe that anyone can actually commit anything using SvnBridge... ?

My next commit, after my disasterous last attempt, in which I had to negotiate 3 separate crash issues and then make do with an identical twin commit, results in a much less informative crash:

An unhandled exception of type 'System.NullReferenceException' occurred in SvnBridge.exe
Additional information: Object reference not set to an instance of an object.

Once again, this crash seems to be related to renaming folders. It crashes on the first file that is within a folder that is renamed.

If renaming folders in SvnBridge works in isolation, I can only guess it has problems renaming folders and modifying the contents of one or all the files within that folder (being renamed)
Jan 1, 2008 at 6:48 AM
I've been able to find a couple of bugs that sometimes will show up when committing a folder rename. One of them is fixed if you get the latest changeset and I'm working on fixing the other one. The "NullReferenceException" error should be fixed.

Sorry about the trouble, but I definitely appreciate you reporting any problems you run into so I can get them fixed.
Jan 1, 2008 at 6:51 AM
Edited Jan 1, 2008 at 8:23 AM


I've been able to find a couple of bugs that sometimes will show up when committing a folder rename.


OK, thanks, I will get the latest changeset and give it a run.
Jan 1, 2008 at 8:34 AM
Edited Jan 1, 2008 at 9:00 AM
It looks like the latest changeset (14722) fixes those issues.
However I still can't commit.

I just went to try again, and this time the error is different (and now I have the .pdb so I can probably give more detailed error/debug information)

An unhandled exception of type 'CodePlex.TfsLibrary.TfsFailureException' occurred in CodePlex.TfsLibrary.dll
Additional information: The following errors occurred:
The item $/CABDevExpress/lib/xunit.dll is locked for check-out by PandaWood_cp in workspace 54653ae1-dd19-854b-9485-b65525dd7cc1.

I tried this again, and the same happened.
So I'm still stuck unable to commit, and yes, this makes it my 5th separate crashing issue ;-) (and counting...)

I can see that TFS has this concept of binary files that are checked out with a check-out lock due to the problems of merging two binary files - but I can't see how this relates to me and my simple commit. To be honest, I don't really want to care about what TFS does.

I have a funny feeling that all this crashing is causing it to crash ;-)
Is someone going to have to do something special on my TFS server to manually unlock this file?
Jan 1, 2008 at 6:09 PM
SvnBridge creates a temporary workspace during commit, which apparently is not getting cleaned up. So when you attempt the second commit, the old workspace is there and it fails.

If you have Team Explorer, you should be able to connect to the TFS server, then delete the workspace from within Source Explorer.
Jan 2, 2008 at 1:30 AM
I deleted the temporary workspace causing your problem. This is one of the other bugs related to renaming that I'm working on, if a rename operation fails it can leave a stale lock.
Jan 17, 2008 at 10:29 AM

jwanagel wrote:
I deleted the temporary workspace causing your problem. This is one of the other bugs related to renaming that I'm working on, if a rename operation fails it can leave a stale lock.

Thanks you for that, I changed the folder structure to work around it. Since changeset 14845, I haven't had any problems.