Jump to content

Changeset order mixed up in local vs cloud repo


Andreas Andersson

Recommended Posts

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

changeset-mixup-cloud.png

changeset-mixup-local.png

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...