Andreas Andersson

Wait just a minute! I pulled down C and D from the cloud to my local repo the day after, the 20th of October. At that time the clock on my local machine may just have been offset by -2 hours, If we add 2 to the local "Creation date" of C and D we end up with the timestamp they have on the cloud. I have a dual-boot setup on this machine for Linux and Windows. For some reason, my local clock have a -2 hour offset when I boot back into Windows after spending some time in Linux. The morning of the 20th I was working in Linux for a while, before I rebooted into Windows and synced C and D from the cloud. I'm guessing that plastic is calculating the difference between my local clock and the clouds clock (-2) and then burns that timestamp into the changesets. So even if I fix my local clock afterward the incorrect timestamps are still there, and Branch Explorer will be eternally confused in that area. I love it when a mystery gets solved, now we can drop this and move on with our lives /Andreas

Good morning, I have "Only Relevant" selected on the topmost cloud branch explorer, but not on the bottom local one. No other filters. Toggling "Only Relevant" on and off does not make a difference, the out of order changesets are still there. You may be on to something with the time. A-C originates from Sweden and D was checked in from France. We are all on CET. If we look at "Creation date" of the related changesets they are: ** Local ** A - 12:08:45 B - 13:21:28 C - 12:40:20 D - 13:19:49 ** Cloud ** A - 12:08:45 B - 13:21:28 C - 14:40:21 D - 15:19:50 All timestamps are from the same day, 19th of October. My local repos timestamp only match the cloud for the changesets I checked in (A and B), while C and D differs. If we sort the local changesets by time we end up with A, C,D and B. The very order that is shown in my local branch explorer. I think we can conclude that these timestamps are the reason for that. The question then becomes, how could the timestamps in my local repo be so wrong? Are they not copied down from the cloud when I sync from the cloud? Now, how is this affecting me? Practically it seems to work just fine. Since I started this thread I have continued working as normal, making child branches of main after D, pushing them to the cloud, and it all seems to work just fine. My local repo does not seem to be corrupt as I first feared. At this point it's mostly an intriguing mystery that is begging to be unravelled. Perhaps not the most important thing to spend time on for either of us Cheers, Andreas

Good morning, Sometimes, I delete changesets in my local repo, but always on sub-branches, never on main. I have not deleted anything in the time frame of these changesets, I don't remember when I did it last, but before A in any case. I doubt that any deletes have happened on the cloud though. Could a local delete that happened earlier than A above have had this effect? I forgot to say that ad-hoc-mouse-indicator-visibility is a branch I created locally before pushing it to the cloud. The branch called GG-1962 was created by someone else on my team, I pulled down it from the cloud at the same time that I synced my local main so that I saw B, C and D. /Andreas

Good morning, I have discovered a discrepancy between my local plastic repo compared to the upstream cloud repo it is set up to sync. Attached you find two screenshots from the branch explorer, the first one is from our cloud repo, the second one is from the local repo I have on my machine. I have labelled the relevant changesets with A, B, C and D. Let's assume that the cloud repo shows the correct picture, the order of the changesets are A, B, C, D. My local branch explorer shows another order, A, C, D, B. In my local repo, if I right click on the changesets and choose "Go to parent changeset" the order does in fact seem correct. parent of D is C, parent of C is B and finally parent of B is A. Does that mean that it's just the branch explorer view that is confused? Another symptom is that green bar up at the top, it say that I have -1 changesets to sync, when I have changeset B checked out. Could I have managed to sync the three branches in a peculiar order from the cloud to my local repo to end up in this state? Have my local repo been corrupted somehow? Do I dare use it to push new local branches to the cloud? For example I want to create a child branch of D locally, and check some stuff in, do I dare push that upstream? Oh yeah, I am using the legacy UI of Plastic SCM 11.0.16.7303 on Windows 10. The new UI shows the same A, C, D, B order (although I can only make branch explorer view my local repo from there). I will be grateful for any insight you might have. Cheers, Andreas

All right, good to know I haven't missed anything. Thank you Carlos.

Hi, Is it possible to set file permissions for files from a Windows machine? Preferably using the `cm` CLI. Say that a user on Windows wants to check in a shell-script, and that they want the +x flag recorded in plastic so that when a Linux or macOs user syncs the script it is ready to be used without running `chmod +x` manually. I know that NTFS is not aware of these flags, but it should be possible to read and edit the metadata plastic has on file permissions for files even on Windows. This may seem like an odd request, but living in a multi platform game studio it is not uncommon case. Cheers, Andreas

Hi, Plastic seems to be aware of file permissions, at least on Linux and macOs where it applies. I have found that if you first check out the file, and then `chmod +x` it then plastic will detect the change and bring include the flag when you check it in. When another user updates their workspace your changeset they will get the file with the `+x` flag. If I recall correctly it was a bit hard to see in the UI before it was checked in, but if you review a changeset after it has been checked in you will see a yellow info-bar over the diff view of each file that say Files are identical. Filesystem permissions changed from NOT_DEFINED to -r-xr-xr-x Hope this helps, Andreas