Exception on Checkin

[carpediemevive]

I had an older project sitting around that I needed to bring in to plastic. I created a new repository, and added the files and committed. Then I wanted to 'update' this project with a whole bunch of new bells and whistles. I was bringing it up to date on current in-house libraries as well as switching .net version (and corresponding visual studio IDEs as well). This meant a lot of file and directory movement over the past few hours. I'm approaching the last step and I can seem to check in this changed file. When I do I receive an error. This is a copy of it below:

There has been an unexpected error "The item should be found on the server tree. Child [QueueFormatter.vb]. Parent [utility]". For more information check the server log.

Server stack trace: 
  at Codice.CM.Server.TransactionInterceptor.TryCheckIn(Int64 repId, Int64 brId, SerializedTreeChangedNode changedTree, TryCheckinSource tryCiSource)
  at Codice.CM.Server.TriggerInterceptor.TryCheckIn(Int64 repId, Int64 brId, SerializedTreeChangedNode changedTree, TryCheckinSource tryCiSource)
  at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
  at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
  at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]: 
  at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
  at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
  at Codice.CM.Interfaces.IItemHandler.TryCheckIn(Int64 repId, Int64 brId, SerializedTreeChangedNode changedTree, TryCheckinSource tryCiSource)
  at a2.a(ae A_0)
  at a2.e(ae A_0)
  at a2.h(ae A_0)
  at a2.i(ae A_0)
  at a2.a(CheckinParams A_0)
  at Codice.CM.Client.Gui.GuiItem.a(ap A_0, String[] A_1, String A_2, Boolean A_3, ICheckinOperation A_4)

I pulled the server logs and this is what I have for those:

2012-02-02 14:18:25,502 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO Operations - Get info for branch /main at repository ID 160

2012-02-02 14:18:25,580 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO UpdatePerf - TryCheckin initial security check [0] ms

2012-02-02 14:18:25,580 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO UpdatePerf - TryCheckin operation [0] ms

2012-02-02 14:18:25,642 b4861af2-fcf7-4dad-944c-aece3daf51a1 IS-TAU-4132 INFO UpdatePerf - Checkin initial security check [0] ms

2012-02-02 14:18:25,674 b4861af2-fcf7-4dad-944c-aece3daf51a1 IS-TAU-4132 INFO Operations - Commit repository transaction b4861af2-fcf7-4dad-944c-aece3daf51a1

2012-02-02 14:18:25,908 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO Operations - Get info for branch /main at repository ID 160

2012-02-02 14:18:29,236 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO Security - ACLReader reading all acls for repository 160. 15 ms

2012-02-02 14:18:29,267 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO Security - ACLReader reading all acl entries for repository 160. 31 ms

2012-02-02 14:18:29,283 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO Security - ACLReader reading all acl inheritance entries for repository 160. 16 ms

2012-02-02 14:18:29,283 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO Security - ACLReader updating ACL cache for repository 160. 0 ms

2012-02-02 14:18:40,689 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO Operations - Get info for branch /main at repository ID 160

2012-02-02 14:18:40,752 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO UpdatePerf - TryCheckin initial security check [0] ms

2012-02-02 14:18:40,752 00000000-0000-0000-0000-000000000000 IS-TAU-4132 ERROR Operations - OnError catching exception The item should be found on the server tree. Child [QueueFormatter.vb]. Parent [utility]

at Codice.CM.Common.CmAssert.CheckNull(Object target, String exceptionMsg, Object[] arguments)

at Codice.CM.Server.TreeExceptionManager.a(TreeChangedNode A_0, TreeNode A_1, IList A_2)

at Codice.CM.Server.TreeExceptionManager.a(TreeChangedNode A_0, TreeNode A_1, IList A_2)

at Codice.CM.Server.TreeExceptionManager.a(TreeChangedNode A_0, TreeNode A_1, IList A_2)

at Codice.CM.Server.TreeExceptionManager.ProcessExceptions(TreeChangedNode changedTree, TreeNode serverTree, Int64 loadedCset, Int64 headCset, PendingMergeLink[] pendingMergeLinks)

at rw.a(TreeChangedNode A_0, Int64 A_1, PendingMergeLink[] A_2)

at Codice.CM.Server.ItemHandler.TryCheckIn(Int64 repId, Int64 brId, SerializedTreeChangedNode changedTree, TryCheckinSource tryCiSource)

at Codice.CM.Server.SecuredItemHandler.TryCheckIn(Int64 repId, Int64 brId, SerializedTreeChangedNode changedTree, TryCheckinSource tryCiSource)

at Codice.CM.Server.TransactionInterceptor.TryCheckIn(Int64 repId, Int64 brId, SerializedTreeChangedNode changedTree, TryCheckinSource tryCiSource)

2012-02-02 14:18:40,752 ERROR Codice.CM.Server.ExceptionTracerSink - Dumping in-transit exception:There has been an unexpected error "The item should be found on the server tree. Child [QueueFormatter.vb]. Parent [utility]". For more information check the server log.

at Codice.CM.Server.TransactionInterceptor.TryCheckIn(Int64 repId, Int64 brId, SerializedTreeChangedNode changedTree, TryCheckinSource tryCiSource)

at Codice.CM.Server.TriggerInterceptor.TryCheckIn(Int64 repId, Int64 brId, SerializedTreeChangedNode changedTree, TryCheckinSource tryCiSource)

at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)

at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)

at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

2012-02-02 14:18:50,142 00000000-0000-0000-0000-000000000000 IS-TAU-4132 INFO Operations - Get info for branch /main at repository ID 160

2012-02-02 14:19:22,392 INFO Channel - The exception was caught during PlasticTcpClientConnection.ProcessMessages: System.Runtime.Remoting.RemotingException, Tcp transport error., ThId: 17

Any clue as to what's going on?

[carpediemevive]

As a side note, I attempt to undo changes and re-apply them and still no dice. The undo changes worked, but when I reapplied the changes and tried to commit it wouldn't let me.

[carpediemevive]

I had to come up with a workaround, so I deleted the file, checked in the delete, and then re-added it. Yes it puts a stop to the file's history, but it was new anyway, so I am not really missing anything.

[jgonzalez]

Hi,

we would like to check why the checkin is throwing that error... Could you tell me please which version of Plastic SCM client and server version

are you using?

Thanks!

-Jesús M.

[carpediemevive]

client version is 4.0.239.2

server version is 4.0.239.0

Thanks for the reply!

[carpediemevive]

It's strange but I don't think I'm able to recreate the problem after I deleted the file and re-added it. I just took a trip through my changesets and this is what I'm seeing.

In the first couple of changesets, everything is normal. At changeset 4 I upgrade the project from 2005 to 2008. The project had a directory structure of /project/vsproject/vsproject/........ This duplicate nesting of the vsproject folder was really unnecessary. So I created a brand new 2008 project and gave it the same name as the original project, but didn't have the nesting. At this point the 2008 project exists at /project/vsproject and the 2005 project exists at /project/vsproject/vsproject.

Then, from inside visual studio 2008, I moved the directories from underneath the sub-vsproject folder to the higher lever folder. Once they were there I removed the sub-vsproject folder. I committed that change as changeset 4.

When I browse changeset 4, I see the folders I moved, but all of them are completely empty.

At changeset 7, I deleted the file that was causing the issue and committed that delete. In this changeset, now all the files are there.

[carpediemevive]

I created a branch from changeset 3 and was able to successfully recreate this error! So it's sitting on a separate branch for us to figure out whenever we get around to it.

[gav135]

I'm having the same problem, though despite this being a standard installation my server is not logging it. My version is 4.0.237.7.

I don't know if this is related, but I've only noticed the problem since adding a second workspace. I am able to checkin to this new workspace without a problem.

The other possibly brave action I took, after creating the new workspace, was to attempt to add a folder to source control via Windows Explorer in my original workspace. The adding worked, but I first got the exception when I tried to checkin that change. I now cannot checkin at all in the old workspace.

[carpediemevive]

I still actually have this branch sitting off to the side of the repository. I haven't attempted to reproduce it since I wrote this entry, but I'm confident the problem still exists. If you get your issue figured out let me know and I'll see if the fix works for me as well.

[gav135]

Fixed! I believe my specific issue was resolved by a bug fix in 4.0.239.2: "Fast-import: After performing a fast-import the following changeset created had number 1 instead of the last one. Fixed."

After my initial fast-import I had checked in changesets 1, 2, and 3. I thought this was just part of the update process... guess I was wrong! I had been able to create a new changeset involving some files, but not others, and when I did so they started numbering themselves from 846, which is where things should have been up to, rather than 4 as I had expected.

Reading up the release notes made it clear what was going on. I don't know how I ended up with 4.0.237.7, I only upgraded to v4 on March 27th! It appears that on that day I downloaded PlasticSCM-4.0.237.7-windows-installer.exe and PlasticSCM-4.0.239.19-windows-client-installer.exe. Don't know why I got both, or why one was so far behind the other, but it seems the full install version of 239.19 would've saved me some hassle!

I resolved this in what I gather is an unsupported fashion... I manually altered the database for the repository. The fields I had to correct were [ichangesetid] and [iparentid] in the [changeset] table, and [fidchangeset] in the [revision] table. The issue was obviously that when I was trying to checkin files that were children of objects that didn't exist back at the time of the original changeset 3, it failed. Once it knew the last changeset was actually number 848, and all the expected parent objects existed, all was well.

As an aside, I did have to take a round-about approach to retrieving some data I had been able to checkin as changeset 846. It MAY have been easier if I knew the encoding format of the [revisiondata] table, so that I could just copy the data out of there.

[manu]

Great hacker work.

[carpediemevive]

I just attempted to reproduce this error in the 4.1 version and it's been fixed. So whatever my problem was you guys fixed it! Thanks!

[manu]

Perfect