[Solved] collab commit version number stuck at 501

Hi @zubz! In our effort to optimize the experience of the History Window we limited the number of commits that are returned in that window to 500. The count in that window is based solely on the number of revisions that are currently displayed, not necessarily their actual revision number. Rest assured that you are not losing any data. But because you hit the limit of the history window, all your latest commits will return as being commit 501.

If you ever need to go back to a commit that's older than 500 commits ago then you can still go to the Collaborate section of the Developer Dashboard and look through the Assets tab to download older versions of any of your assets. I hope that clears up the confusion.

 

So this starts to get into the nitty gritty of the change that happened. I'll do my best to explain.

So commits don't really have a number that we store with them. They do have a generated ID, but it's not a simple incremental number ID. They never actually had this. The editor was just counting the number of commits it knew about on the client side to generate those numbers. Since it's just a count and we limited the history return to 500 commits, the most recent commit is always number 501.

There was no client side logic change for this. This was done completely server side. The reason for the change was because we didn't have a limit on how much history to return to the editor. It just asked for the whole thing at once. This was very slow for users with very long commit histories. We figured the net pain of having to wait over a minute for your history to load every time would be greater than having to go to the dev dashboard website to deal with the rare case where you need a commit from over 500 commits ago.

This 500 value is set server side by us, but it is not set in stone and this limit is only in place for the call that says "Give me the entire history." In a near future editor release, the history window will have properly implemented pages (the same kind of pages you can see on the dev dashboard website now where it shows 100 commits at a time). Once this is out, there won't be a limit to the number of commits that are visible in the editor for versions of the editor with this paged feature.

Yes, it would make more sense to show 600-1100 instead or whatever, but if we could have made a client side change like that before imposing this limit, we would have just put in the pages feature instead to avoid the need to do that. Also if we can find other means of making this history call work a lot faster, we would be free to increase this limit to something much higher. Just keep in mind that if we did raise it, the same problem would still exist. If we raised the limit to 1000, then the most recent commit would be always number 1001 assuming that you have more than 1000 commits.

I hope that helps to explain the current situation and that it's only temporary until we get history pages in.

 

Sorry for the late reply. 2018.1 is the first editor version with the new paginated history window UI so you won't be limited to the latest 500 commits.

 

So just to reiterate, your project itself, on the server, has no limit to the number of commits and never had a limit to the number of commits.

The problem was that on older editor versions we had to limit how many commits the history window could display! That display limit will still be in effect on the older editor versions as they are working off of the old UI framework, making a backport of the new UI to them very difficult.

So if you have a project with way more than 500 commits but were on an older editor version and then upgraded to 2018.1, you'll see the ability to browse back to your first commits return.

 

Yes, there will be no limits in the history window for newer versions of the Editor.

 

Thank you for bringing that to our attention, @Iamsodarncool. I'll pass this along to the dev team.

 

Hey @Iamsodarncool how wide is your window when you see that? Does the problem go away if you make the window wider?

 

Noted, thanks for the video of the bug.