Why can I check out an added item? (VS2010)

[Soho]

I am wondering, why the context menu sometimes shows a "check out" option for added items.

Check images.

The first is a document as it appears in the VS2010 solution explorer.

The second is the context menu for that item.

The last is the items view in the stand alone GUI showing the item as being controlled and not checked out (which I think was the correct state, but it is easy to get confused).

[danipen]

Hi Soho,

It seems that the project containing the item "Forretningslogik.docx" is not bound in Visual Studio.

In order to check if the project is bound in Plastic SCM:

1) Click on Visual Studio main menu: "File" -> "Plastic SCM source control" -> "Change source control..."

2) In the "Change source control" dialog, look for the project and check that the status is "Bound".

Please, let me know if this solution works for you,

Best regards,

Daniel

[Soho]

It seems that the project containing the item "Forretningslogik.docx" is not bound in Visual Studio.

In order to check if the project is bound in Plastic SCM:

1) Click on Visual Studio main menu: "File" -> "Plastic SCM source control" -> "Change source control..."

2) In the "Change source control" dialog' date=' look for the project and check that the status is "Bound".

[/quote']

The document is located under a solution folder directly under the solution, not in a specific project. The solution is marked as bound in "Change source control...".

Also, if it was not bound, I shouldn't see the "+" sign and have a check out option in the context menu, correct?

We have a lot of issues with the VS2010, frankly it is barely usable, since you often don't know if your code is safe or not. This is a major problem since changing workspace branches, might override files. This is something we have experienced multiple times. Frequently changing workspace branch is a key feature of a Plastic development work routine, which is great, but the lack of trust in your files being safe with the VS2010 plugin is a huge problem.

I really like a lot of the Plastic concepts, but there are still some ugly flaws, mostly in the VS2010 plugin, that needs to be ironed out before I will go out and recommend Plastic to my peers. I hope my forum contributions will help you track down some of these issues.

[miller]

Hi Soho, I answered you in multiple threads, looks like we have to review solution folders implementation, the Plugin is rocket stable has been used by many people for long time "of course can have some minor issues" but nothing as the ones you are facing, but to be honest with you we introduced solution folders support lately and we don't use them, and I do believe it can be related here.

Miller

[Soho]

Hi,

I also find it plausible that the problem could be related to solution folders.

What I will do now is create a test-branch of our project where I strip the solution entirely from solution folders. I will report how it went.

That said, solution folders are to me a very natural way of organizing projects and documentation within solutions and a feature I really hope you will support.

When I think about it, I do recall problems with solution folders in the past. Actually, maybe it was an early version of TFS, that was troubled by this feature.

[Soho]

Hi, I have now made a solution folder stripped solution and it seemed to solve the duplicate project problem, but did not solve all the other strange stuff I have been reporting.

However, as I describe in my latest bug report, the VS2010 plugin seems to be in a very unstable state after a solution has been loaded, but before the first checkin dialog has been displayed.

So, my current stabilizing routine when opening a solution (with or without solution folders) is this:

Open the solution.

Right click the (apparently non-controlled) solution in the solution explorer. And choose "Check in".

Close the check in dialog without doing anything.

Now the plugin is much more stable.

I am quite surprised that no-one has reported this quite serious problem before. Perhaps it some other circumstances with our solution, that requires this workaround, but we can reproduce the stability / state problem consistently on all developer machines.