marioo Posted June 29, 2015 Report Share Posted June 29, 2015 Hello, I think I found a serious bug that may lead to losing some workspace changes. It seams that Plastic SCM considers files identical when their sizes and timestamps are identical. It seems to ignore their content in that case. I happened to notice this issue several times so far, but only now have I understood how to reproduce it. In Plastic SCM client preferences > Other options, I have checked the following options: 1. Compare file contents instead of timestamps when determining "Changed" status 2. Update operation sets repository timestamps on files. How to reproduce the bug: 1. Create a file named test.txt in a subdirectory of your workspace and add a content of "test1" to it. 2. Copy it to another directory of the workspace and change its content to "test2". Now there are two files named test.txt in your workspace, they have identical sizes, but different contents and different timestamps. 3. Check them in both at once, so that they are in the same changeset. 4. Delete them from your workspace, but then go to pending changes and undo the deletion (or update the workspace) to restore them. 5. Now the files are back in your workspace, and both have the same timestamps (because Plastic used changeset timestamps when getting the files from repository). At this point the files have identical sizes and timestamps, but different contents. 6. Copy one of the files to the directory of the other file to overwrite it. Now the files are totally identical, but when you go to Pending changes, Plastic SCM will not detect any changes (even though the overwritten file changed). When you modify the overwritten file manually to make its timestamp change, only then will pending changes include that file. I know at first sight this seems a low-importance issue, but I happened to release our app with invalid files because of that. Let me describe the circumstances. Our app is written in WPF and it uses external resource files (.xaml) that represent themes. The files are stored in separate theme folders, and their names and structures are identical in all those folders. They differ only in some properties defined in the files like Background="Black" or Background="White" in simplest cases. As you can see these two pieces of text are of the same length. When I change theme structure, I copy all .xaml files from one theme folder to another. This way I don't have to manually correct the structures in all themes. Then I go to pending changes and restore only theme-specific properties keeping the new structure as is. And this is when I noticed the bug - Plastic SCM did not show me changes of most files I overwrote in a theme folder. I will be grateful if you investigate and fix that. Thank you! Link to comment Share on other sites More sharing options...
manu Posted June 29, 2015 Report Share Posted June 29, 2015 I will be grateful if you investigate and fix that. Thank you! Count on it. I can reproduce it and we'll fix it asap. It's a pleasure to read your bug reports, always well written and providing all the details. Thanks! Link to comment Share on other sites More sharing options...
marioo Posted June 29, 2015 Author Report Share Posted June 29, 2015 No problem, thank you too! Link to comment Share on other sites More sharing options...
manu Posted July 14, 2015 Report Share Posted July 14, 2015 Hi! We have been reviewing this scenario. The only chance we have to identify those kind of changed items is calculating the hash for each item, notice here that the timestamp is the same for both files. Calculating the hash for a couple of files is not a problem but doing it for the entire wks takes time. Let me explain what Plastic does right now when you set the "Compare file contents instead of timestamps when determining "Changed" status" preference (I hate the name BTW, we need to change it and improve it because it's confusing). If a file is having the same timestamp as the one stored inside out metadata file (.plastic\plastic.wktree) plastic assumes is the same unchanged file. If the timestamp is not the same then it's directly shown as changed unless the "Compare file contents instead of timestamps when determining "Changed" status" preference is set, if it's set then Plastic calculates the hash and if it's not the same the file is set as changed. Sooooooooo, the problem is that if we check the hash for every single file the performance is going to be really bad. We can add a new preference to avoid damaging the "Compare file contents instead of timestamps when determining "Changed" status" preference performance but I'm not sure if anyone would use it since the calculation would be very slow. What do you think? Link to comment Share on other sites More sharing options...
marioo Posted July 14, 2015 Author Report Share Posted July 14, 2015 Hi Manu, Thank you for the explanation. I decided to switch off said preference for safety reasons, but now the pending changes view shows me unchanged files quite often. For example when I modify a file in VS and then undo my changes (Ctrl + Z). But I think I can live with it, this is not that annoying :-). The new preference you suggested (calculating hash for each file) is probably the most reliable solution, but if you think it will cause Plastic SCM to refresh pending changes for dozens of seconds in average, even I won't decide to use it :-). In that case there is no point to waste time implementing it. Link to comment Share on other sites More sharing options...
marioo Posted July 14, 2015 Author Report Share Posted July 14, 2015 Nevertheless, could you please explain me once again how exactly the "Compare file contents instead of..." preference affects checking differences? I will be grateful, because I'm not sure if I understood you correctly. I just want to be aware how exactly the feature works to use it mindfully. When this feature is inactive, and file timestamps are different than the ones stored in metadata, the file is considered changed, even if its content is unchanged, right? When the feature is active, and timestamps differ, the file is considered changed only if its hash differs as well, right? When the feature is active, and timestamps did not change, the file is considered unchanged (its hash is not calculated), right? Can I be sure that when I switch the preference off, I will never miss any changes, even if file timestamps and its size do not change? Thank you! Link to comment Share on other sites More sharing options...
manu Posted July 21, 2015 Report Share Posted July 21, 2015 Hi Marioo! When this feature is inactive, and file timestamps are different than the ones stored in metadata, the file is considered changed, even if its content is unchanged, right? Totally right. When the feature is active, and timestamps differ, the file is considered changed only if its hash differs as well, right? Right with minor considerations, we first check the file size (since it's faster), if it's different the file is considered changed, if the size is the same then we check the hash to determine if it's truly changed. When the feature is active, and timestamps did not change, the file is considered unchanged (its hash is not calculated), right? Right, if the timestamp is unchanged (your initial case) then the file is considered unchanged. Link to comment Share on other sites More sharing options...
marioo Posted July 21, 2015 Author Report Share Posted July 21, 2015 It's clear now. Thank you! Link to comment Share on other sites More sharing options...
manu Posted July 21, 2015 Report Share Posted July 21, 2015 Great! So at the end of the day I recommend you to keep the preference off, yes, you are going to see "false" positives, changed files that are not really changed but even if you check them in the server will undo them for you. Link to comment Share on other sites More sharing options...
marioo Posted July 23, 2015 Author Report Share Posted July 23, 2015 Great, I didn't know that. I had already switched the preference off, and I used to undo unchanged files manually. Thanks for the info. This will save my time . Link to comment Share on other sites More sharing options...
manu Posted August 3, 2015 Report Share Posted August 3, 2015 You are very welcome Mario. Best regards. Link to comment Share on other sites More sharing options...
gweronimo Posted September 29, 2015 Report Share Posted September 29, 2015 Related uservoice: https://plasticscm.uservoice.com/forums/15467-general/suggestions/9286734-new-preference-always-undo-unchanged-on-refresh Link to comment Share on other sites More sharing options...
manu Posted September 29, 2015 Report Share Posted September 29, 2015 Thanks for linking it. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.