Any way to fix a bad date in history (future) messing up the history display?

Question

A colleague’s computer did weird things to the date about 10 years ago as his project was getting started using Paratext with mercurial version control (send/receive). The dates of about 10 commits display as 2038 in Paratext but in other mercurial software show as 2095. Though the revision number is lower it seems Paratext displays history by sorting on the date and this is really annoying for this case. Changing the date of an old commit on a published repository seems impossible. So do we have any solutions whether within Paratext or with TortoiseHg or anything else, to get rid of these useless commits? They are so old that they don’t add anything, but I can’t seem to get rid of them.

image403×626 130 KB

image618×784 65 KB

The solution would seem to be one of

1. Remove all history (undesirable but easily achievable)
2. Paratext changes its sort order in the history menu to be based on revision number not date (not worth doing just for one project)
3. Some hg magic to change the (published) commits, whether using rebase, collapse, evolve, histedit or something.

I write this here in case others have a similar problem and also because of 2 thoughts which might form feature/dev requests for the paratext team.

1. It strikes me that the history listings in Paratext (especially compare texts) are unhelpful and potentially dangerous when ordered by date if there is a possibility of any computer dates ever being messed up. The underlying mercurial system has a way of ordering revisions independently of commit date. MacHg and TortoiseHg both display the revisions in the correct order, while also showing
2. The current UI for listing books with a long change history gets quite cumbersome and could possibly be made more useful for trying to track down changes.

So is there any advice about how I can help fix my colleague’s project? Anyone else think that a Paratext feature request to adjust the sort order of the history display might be worthwhile?

Answer 1

rowbory:

3. Some hg magic to change the (published) commits, whether using rebase, collapse, evolve, histedit or something.

History modification is really only sensible for draft change sets. So unless one can convince a Paratext S/R admin to made the changes for you on the S/R server and can coordinated with all users of the project to delete their copies and then S/R a clean copy after, this isn’t really a safe option.

Another option might be a feature request for:
4. Enhancing Paratext’s “Convert Project” (admin tool) to auto fix invalid dates.

Comments

IMO this is a unique enough situation that it should be dealt with externally and shouldn’t require PT to be reprogrammed. Just my 2 cents.

Based on my own experimentations with mercurial, my guess is that you can rebase or otherwise edit the history in mercurial, but that it will likely recalculate all the hashes for the commits. Basically you’re forking the project. That would require deleting the project from the Registry and from each member’s computer, then re-sharing it.

---

Thanks. Good to have the confirmation. Essentially what I had hoped would be a simple fix for me to do is in fact a non-trivial problem. It just turns out to be unfortunate that Paratext unlike mercurial clients orders by commit date rather than rev id.

---

One thing to keep in mind is that the changeset order (rev id’s) might be different for different users. (Using date at least makes things consistent for each user). Also if you had a user that S/R infrequently, then changes they did many months ago might appear before changes that another user did yesterday. (if order by rev id)