Getting item by ID

[Soho]

When checking in a merge I often get an error message like "Item xxx could not be found in the tree. The new tree cannot be built.".

I don't know why I get these errors, but since I don't which item xxx is, it's hard to make a work around.

Is there a way to get item paths by ID?

I suppose it's hard here, since the error message tells me some item does not exist, but perhaps I can find it in another repo or on another server.

Bonus info: I think these errors come only when the merge contains merge links to xlinked repos. It could be nice to know which repo the item that could not be found was not found in.

Could this be a merge issue where items are checked in wrong dependency order?

I use 4.1.10.306 on server and client.

[manu]

Hello Soho,

you can use the "cm ls" command and the cm find command. For example:

c:\tmp\serverOne>cm ls --format="{itemid} {path}"
2 c:\tmp\serverOne
2341 c:\tmp\serverOne\server

or

c:\tmp\serverOne\server>cm find revision where item=2341
2342	 28/06/2012 16:03:06 dir manu	 [b]c:\tmp\serverOne\server[/b]#br:/main#1

Hope it helps!

[manu]

Remember that an item can have multiple revisions, for example:

c:\tmp\serverOne>cm find revision where item=2341 --format="{itemid} {path} {id}"
2341 c:\tmp\serverOne\server 2342

The itemid = 2341 ({itemid}) has a revision id 2342 ({id})

[mipi3]

Hello,

we are using wxlinks and we receive the same error messages from time to time when we want to commit the merge. We have found those erroneous items by item id as manu suggested, but this didn't help. We see that those items exist in source, destination and base changesets. We just don't understand where the problem is.

Is there some workaround? Or could you just explain what this error message means. This would be very helpful.

We are using client and server version 4.1.10.302 - Moscow

--

There's a little thing we can influent with this message. When we rename this problem item to some custom name and rename it back to normal this message changes to the second problem item, we do the rename again on that second item message changes pointing to another item, this repeats until again we receive the first error message.

[Soho]

I am glad to hear that we are not the only one with lots of wxlink problems. Hopefully this will increase the priority of these issues. Unfortunately it is a proven fact, that the likelihood of finding additional bugs is proportional to the number of bugs found so far.

[mipi3]

I didn't mention that all these problem items are several root directories of the root repository that we are trying to merge.

Soho, how did you overcome this error?

[Soho]

I didn't overcome the error. We are still unable to merge our branches back to /main. I am currently waiting to be scheduled for a support session.

It is possible that I could hack my way through by merging the other direction from /main to the branches and then back or combine a cherry pick merge with a branch merge.

This what I have been able to do before to work around Plastic xlink bugs, but I would prefer not to in this project, since some of the xlinked repos contain rather large datasets and it is quite time consuming to experiment with work-arounds when you have to merge and undo GB of data many times.

Unfortunately stability is not one of Plastics finest virtues. A true bleeding edge product in the best and worse meaning unless you stick to a proven subset of the features. This is still what's holding me back from recommending it to the rest of our organization. Even though Plastic support is excellent I don't want to be the go-to guy every time Plastic crashes.

[mipi3]

Thank you for your answer and some insight. We are in the similar situation. We are trying to move away from source safe and for test purpose our team started using Plastic. Wxlinks looked as very neat solution and we started to use it, but now we have some "object reference not found" errors and Plastic crashes. I don't know if these are because of wxlinks only. If wxlinks is the only problem we could live without it and wait for the time when this feature will mature. As I know there is no similar features in other source control systems.

[vsanchezm]

Hi both!

Sorry for the inconveniences.

Could you send an stacktrace of the error? It would be a tremendous help to isolate the problem.

We are already working in a known bug with the checkin where the XLinks are outdated (they are not pointing to the last changeset of the xlinked repository).

It might be your case but I need more information.

Thanks in advance.

[Soho]

Stack trace was posted here earlier: http://www.plasticscm.net/index.php?/topic/1052-resuming-a-merge/

[mipi3]

The end of the log file after the error message (updated both client and server to 4.1.10.315 - Santiago)

====

2012-07-17 17:06:15,802 DEBUG Checkin - Checkin

2012-07-17 17:06:15,806 INFO Performance - Checkin - CalculateFSInfo 15 ms

2012-07-17 17:06:15,806 INFO Performance - Checkin - Do - FillFSInfo: 15 ms

2012-07-17 17:06:15,811 DEBUG WorkspaceDataStore - ReadMergesToCheckin 0 ms

2012-07-17 17:06:15,823 INFO Serialization - Compressed 822 bytes in 412 bytes. Time: 0 ms.

2012-07-17 17:06:15,834 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5)

2012-07-17 17:06:15,834 DEBUG BufferPool - -> Entering with name UncompressionPool (5)

2012-07-17 17:06:15,834 INFO Serialization - Uncompressed 304 bytes in 448 bytes. Time: 0 ms.

2012-07-17 17:06:15,834 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4)

2012-07-17 17:06:15,835 DEBUG BufferPool - <- Releasing with name UncompressionPool (4)

2012-07-17 17:06:15,835 DEBUG ClientSink - | TryCheckIn | proc 16 | 10 | 31599160

2012-07-17 17:06:15,835 INFO Performance - Checkin - Do - TryCheckin: 16 ms. Tree ready

2012-07-17 17:06:15,835 DEBUG WorkspaceDataStore - ReadMergesToCheckin 0 ms

2012-07-17 17:06:15,836 INFO Serialization - Compressed 4091 bytes in 1505 bytes. Time: 16 ms.

2012-07-17 17:06:15,846 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5)

2012-07-17 17:06:15,846 DEBUG BufferPool - -> Entering with name UncompressionPool (5)

2012-07-17 17:06:15,846 INFO Serialization - Uncompressed 304 bytes in 448 bytes. Time: 0 ms.

2012-07-17 17:06:15,846 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4)

2012-07-17 17:06:15,846 DEBUG BufferPool - <- Releasing with name UncompressionPool (4)

2012-07-17 17:06:15,846 DEBUG ClientSink - | TryCheckIn | proc 16 | 10 | 31681080

2012-07-17 17:06:15,846 INFO Performance - Checkin - Do - TryCheckin: 16 ms. Tree ready

2012-07-17 17:06:15,846 DEBUG WorkspaceDataStore - ReadMergesToCheckin 0 ms

2012-07-17 17:06:15,846 INFO Serialization - Compressed 1639 bytes in 670 bytes. Time: 0 ms.

2012-07-17 17:06:15,856 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5)

2012-07-17 17:06:15,856 DEBUG BufferPool - -> Entering with name UncompressionPool (5)

2012-07-17 17:06:15,856 INFO Serialization - Uncompressed 304 bytes in 448 bytes. Time: 0 ms.

2012-07-17 17:06:15,856 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4)

2012-07-17 17:06:15,856 DEBUG BufferPool - <- Releasing with name UncompressionPool (4)

2012-07-17 17:06:15,856 DEBUG ClientSink - | TryCheckIn | proc 15 | 10 | 31763000

2012-07-17 17:06:15,856 INFO Performance - Checkin - Do - TryCheckin: 15 ms. Tree ready

2012-07-17 17:06:15,857 DEBUG WorkspaceDataStore - ReadMergesToCheckin 0 ms

2012-07-17 17:06:15,857 INFO Serialization - Compressed 8015 bytes in 2451 bytes. Time: 0 ms.

2012-07-17 17:06:15,867 DEBUG BufferPool - -> Entering with name SinkcompressionPool (5)

2012-07-17 17:06:15,867 DEBUG BufferPool - -> Entering with name UncompressionPool (5)

2012-07-17 17:06:15,867 INFO Serialization - Uncompressed 304 bytes in 448 bytes. Time: 0 ms.

2012-07-17 17:06:15,867 DEBUG BufferPool - <- Releasing with name SinkcompressionPool (4)

2012-07-17 17:06:15,868 DEBUG BufferPool - <- Releasing with name UncompressionPool (4)

2012-07-17 17:06:15,868 DEBUG ClientSink - | TryCheckIn | proc 16 | 10 | 31861352

2012-07-17 17:06:15,868 INFO Performance - Checkin - Do - TryCheckin: 16 ms. Tree ready

2012-07-17 17:06:15,868 DEBUG WorkspaceDataStore - ReadMergesToCheckin 0 ms

2012-07-17 17:06:15,869 INFO Serialization - Compressed 11310 bytes in 3141 bytes. Time: 0 ms.

2012-07-17 17:06:15,890 DEBUG ClientSink - | TryCheckIn | proc 15 | 10 | 32044840

2012-07-17 17:06:15,893 ERROR CmProxy - Error invoking method [TryCheckIn] [plastic://APP-SERVER:8087/ItemHandler] A merge is needed from changeset /main#5 to changeset /main#1 (the changeset you are currently loading) in order to checkin. The checkin operation cannot continue. It is necessary to solve the conflicts by merging your current workspace contents with the latest contents of the branch you are currently working on. Then, you can retry the checkin operation.

2012-07-17 17:06:15,902 DEBUG BuildChangesTreeForPath - Processing recursive children

2012-07-17 17:06:15,914 DEBUG WorkspaceDataStore - ReadMergesToCheckin 0 ms

2012-07-17 17:06:15,919 INFO Serialization - Compressed 6424 bytes in 2694 bytes. Time: 0 ms.

2012-07-17 17:06:15,934 DEBUG ClientSink - | CalculateMerge | proc 15 | 10 | 32884624

2012-07-17 17:06:15,934 ERROR CmProxy - Error invoking method [CalculateMerge] [plastic://APP-SERVER:8087/ItemHandler] Item 1275 could not be found in the tree. The new tree cannot be built.

2012-07-17 17:06:15,934 DEBUG Checkin - Error: Item 1275 could not be found in the tree. The new tree cannot be built.

2012-07-17 17:06:15,934 INFO Performance - Checkin - TOTAL: 421ms

2012-07-17 17:06:15,934 DEBUG Checkin - __ Checkin ends _______________________________

2012-07-17 17:06:55,476 ERROR plastic - Plastic SCM client version: 4.1.10.315

2012-07-17 17:06:55,476 ERROR plastic -

Error message: Item 1275 could not be found in the tree. The new tree cannot be built.

2012-07-17 17:06:55,479 DEBUG plastic -

StackTrace:

Server stack trace:

at Codice.CM.Server.TransactionInterceptor.CalculateMerge(MergeSource source)

at Codice.CM.Server.TriggerInterceptor.CalculateMerge(MergeSource mergeSource)

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.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.CalculateMerge(MergeSource mergeSource)

at aiy.a(WorkspaceInfo A_0, MergeSource A_1)

at k.a(MergeSource A_0, String A_1)

at bo.b(ae A_0, CmMergeNeededException A_1)

at bo.a(ae A_0, String A_1, Boolean A_2)

at a2.m(ae A_0)

at ia.a(ae A_0, a A_1)

at ia.a(ae A_0, a A_1)

at a2.o(ae A_0)

at ia.b(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)

...

====

[mipi3]

the workaround for this problem is to manually merge xlinked repositories to every main branch. Then update xlinks on the source and destination branches of the root repository to the newest ones. So in the end there will be only one pending merge link of the root repository.

We think that the problem was in wxlink that was referenced two times with different changsets. The main repository after merge and before checkin tree was something like this:

rep1:/main/b1
|
wxlink -> rep2:cs1:/main
wxlink -> rep3:main/b1
          |
         wxlink -> rep2:cs3:/main/b1

we tried to reproduce this error, but we got different errors with plastic crash. Maybe we were close.

[manu]

Hi mipi3,

I'm sorry but the scenario you are testing is not supported. You can't have the same repository mounted twice in your workspace. Sorry.

[mipi3]

Hi manu,

we hope this was the main problem. We will eliminate this second xlink and will watch the situation then.

It would be great if the warning about second xlink could appear before checkin or even earlier when second xlink appears (in our situation it appeared in already xlinked repository, so we didn't notice it).

[manu]

Yes... maybe we have also to specify it at the documentation or the command man page....

Sorry for the inconveniences.