wnicholls Posted June 8, 2015 Report Share Posted June 8, 2015 This is somewhat astonishing and I'm not sure how to explain it - but it looks VERY serious. Behaviour started fairly promptly with upgrade to v5.4. Windows client, current version v5.4.16.663 server whatever was current at the same time. I have a workspace I've been using for several years. There are a few unversioned files in it but most folders contain items under source control. Is a Visual Studio 2012 project with some additional folders (such as SQL/, Docs/ .. ) All of a sudden it seems - although not exactly in front of my eyes, the Pending Changes view is showing *ALL* files as 'Added an private" - ie no longer under version control. But if I go into Changesets view I can see my recent history and Diff changeset (Ctrl-D) works as expect showing the files getting, well, changed. The pending changes view shows "Added and private items - 0 of 321 items selected" - screenshot - I wonder if this will come through? (didn't. try attached JPEG) (There are actually 1342 files in this subdirectory, so presumably all bin/ debug/ and .bak and so forth are being excluded as per the ignores file, I haven't double-checked this). In desperation this morning I tried renaming /source to /source_old, creating a new workspace in /source, checking out everything (ie Update Workspace). Then I xcopy-ed all the files (except .plastic folder) back over from source_old to ensure I had my latest changes and was able to check in. (this reset all the timestamps, but underlying Ctrl-D showed that unchanged files were unchanged). Guess what - about 6 hours later, I come back to Plastic GUI and it's back to everything unversioned again. Now I basically can't trust Plastic - which is a terrible place to be . Looks like a whopping bug in the GUI or something which corrupts workspaces. Any suggestions? Link to comment Share on other sites More sharing options...
wnicholls Posted June 8, 2015 Author Report Share Posted June 8, 2015 Trying JPEG attachment- screenshot as mentioned above. Link to comment Share on other sites More sharing options...
manu Posted June 8, 2015 Report Share Posted June 8, 2015 Hello, the only explanation to have all the workspace items as "private" is not having a ".plastic\plastic.wktree" file, or having it formatted to load the cset #0 (almost empty, will only load the root item). Can you check if you have that file when you face the issue? Plastic will never remove it. Do you have an anti-virus tool or any other protection tool that might be denying writing the file or removing it? Workarounding the issue in you case is straigt forward, run an update operation (or switch your branch to the latest cset in your working branch), your changed items will be renamed to .private.0 so you can search them and apply the changes manually. As I said it's just a workaround and I would like to know why you are facing the issue. Link to comment Share on other sites More sharing options...
wnicholls Posted June 8, 2015 Author Report Share Posted June 8, 2015 .plastic directory contains plastic.selector, plastic.wktree and plastic.workspace as expected. But selector is: repository "...." / path "/" br "/main" co "/main" and the workspace file name & GUID, which all matches what I"d expect However plastic.wktree is only 170 bytes; whereas similar files in other workspaces are 11k, 50k sort of thing. cm status reports cs:0@rep:... whereas other workspaces report eg cs:52@rep:... and list modified items So your statement "load cset#0" looks to be spot on. Avoiding the GUI for a moment, I tried "cm upd ." - this displayed this (sorry for anonymising, just being cautious!) Searching for changed items in the workspace... Downloading block of 2 files (36.49 KB) Copied e:\work\...n.cs Copied e:\work\p...portExport.cs Now as you predict, two private.0 files, and cm status reports cs:172 ; and if I copy the private.0 to the actual source files, cm status --all shows the changes completely as expected. plastic.wktree is now 48k; And in the GUI it now shows " Change items - 3 of 3 items selected" ( 3 being the two files and the subfolder they are in). Which I was able to check in successfully. Thanks manu - that gets me going again. I still don't know what caused this. We may be playing a waiting game to see if it happens again. At a random (but not totally unjustifiable) guess, it could be a workspace created under a previous plastic version, then used under 5.4 perhaps without an UPDATE first or something like that? Link to comment Share on other sites More sharing options...
manu Posted June 10, 2015 Report Share Posted June 10, 2015 Ok so it seems like the workspace has been removed because as you said you have a plastic.wktree file but it's the default one, the one that loads the cset#0, 170 bytes (a good plastic.wktree, in your scenario, has 48k) . The default plastic.wktree is written during the workspace creation, "cm mkwk" or using the GUI. So, how the workspace can be removed and regenerated? :S Are you using a continous integration system in your machine? Bamboo for example..... Any batch file issuing cm commands? Is the machine shared with someone else? Happy to know that at least you can move forward with the workaround but I'm really wondering why it's happening. I have an idea, you can enable both cm.exe and plastic.exe log, so at least we can track, if it happens again, if it's done using the plastic client. Here you can review how to enable them: https://www.plasticscm.com/documentation/technical-articles/kb-enabling-logging-for-plastic-scm-part-i.html Link to comment Share on other sites More sharing options...
wnicholls Posted June 26, 2015 Author Report Share Posted June 26, 2015 So it happened again! (Once again cm up . saved my bacon). Sadly didn't have logging turned on (do now!), but I do have a good lead I discovered this today, 26 Jun at about 16:40 .. plastic.wktree (170 bytes) default version is dated 24/06 at 2:27pm so I'm guessing that was when the problem occured. So what was I doing at 2:27pm two days ago? Looks like I came into work on Visual Studio after a bit of a break - probably after leaving it open overnight- and immediately switched projects. The first project's .sln file is timestamped 24/06/2015, 14:27:25 - and a hidden .v11.suo file i24/06/2015, 14:27:26 ; Then in the second project, the plastic.wktree is timestamped ... 24/06/2015, 14:27:27. A bunch of other files in that other project are timestamped 14:29, 14:30 ., 14:31 The first project is *NOT* under plastic control (it's all in subversion). The second project *IS*. I don't think the separate plastic GUI was running at the time, but two days ago , who knows? There may be other circumstances around this. For example * I access the plastic server via a VPN- perhaps the VPN connection was down at the time? (I usually leave it connected and it is very reliable, but occasionally it conflicts with other networking things, like using another customer's VPN). * I run Windows as a virtual machine (linux host) and could have suspended the VM overnight.. If the plastic client also went to sleep / lost its network connection, then it might have done these bad things when it was first accessed after resuming the VM. Never saw that before though and I suspend and resume most days. Going to see if I can reproduce the problem with logging on just now. Link to comment Share on other sites More sharing options...
wnicholls Posted June 26, 2015 Author Report Share Posted June 26, 2015 GOT IT! Steps to reproduce: Starting with Visual Studio ( VS professional 2012 : version 11.0.61030.00 update 4), Plastic SCM GUI ( 5.4.16.663 )both closed. VPN connection running. aaaand... PlasticSCM extension version 4.1 installed (Although the extension is labelled version 4.1, the only file I can find is C:\Program Files\PlasticSCM4\client\plasticscm-visualstudio.vsix (80MB, dated 18/5/2015 3:32pm) and I'm 99.999% sure I asked the Plastic client installer (when putting v5.4 on) to update the extension at the same time. Steps 1. Open Visual Studio 2. Select Project P Project P's workspace file is now 26/06/2015 05:26 p.m. 170 plastic.wktree - POW! Quit Visual Studio for good measure. Plastic log file is silent. It was last updated when I closed the GUI it prior to performing these tests. Don't know how to create a log file for the VS plugin. - in retrospect, a plasticVSextensibility.log.conf might have done it. Next test: In Visual studio, uninstalled the plastic extension. Opened VS, opened solution - message "The source control provider associated with this solution could not be found ..." (no surprise here) - Yes to remove bindings from projects. -> plastic.wktree is unaffected. If I run plasticscm-visualstudio.vsix now and open VS2012, it puts the "Plastic SCM For Visual Studio .. version 4.1" back, apparently. If I now open the project, the plastic.wktree file remains unaffected. How long that will last I don't know <g> ------------ The evidence may be destroyed as to the state beforehand - in particular, which "plastic SCM extensions for Visual Studio" was actually installed. But regardless, why is the plugin called version 4.1 when the overall plastic install is 5.4.something? Link to comment Share on other sites More sharing options...
wnicholls Posted June 26, 2015 Author Report Share Posted June 26, 2015 So far in a couple of minutes fooling around, haven't managed to corrupt workspace yet. I rightclicked on solution, Plastic SCM->Refresh Status; checked in the projects (.csproj files) which had changed. Close reopen VS a few times. It certainly looks to me at the moment that the VS plugin wasn't the right version, and perhaps is now (but... version 4.1?????????) See attached screenshot. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.