Existe alguma forma de corrigir uma data inválida no histórico (futuro) que está bagunçando a exibição do histórico?

Question

O computador de um colega fez coisas estranhas com a data há cerca de 10 anos, quando seu projeto estava começando a usar o Paratext com controle de versão mercurial (send/receive). As datas de cerca de 10 commits são exibidas como 2038 no Paratext, mas em outros softwares mercurial aparecem como 2095. Embora o número de revisão seja menor, parece que o Paratext exibe o histórico ordenando pela data, o que é realmente irritante neste caso. Alterar a data de um commit antigo em um repositório publicado parece impossível. Então, temos alguma solução, seja dentro do Paratext, com o TortoiseHg ou qualquer outra coisa, para se livrar desses commits inúteis? Eles são tão antigos que não acrescentam nada, mas não consigo me livrar deles.

imagem403×626 130 KB

imagem618×784 65 KB

A solução pareceria ser uma das seguintes:

1. Remover todo o histórico (indesejável, mas facilmente alcançável)
2. O Paratext altera sua ordem de classificação no menu de histórico para ser baseada no número de revisão, não na data (não vale a pena fazer isso apenas para um projeto)
3. Alguma mágica do hg para alterar os commits (publicados), seja usando rebase, collapse, evolve, histedit ou algo assim.

Escrevo isso aqui caso outros tenham um problema semelhante e também por causa de 2 pensamentos que podem se tornar solicitações de funcionalidade/desenvolvimento para a equipe do Paratext.

1. Me parece que as listagens de histórico no Paratext (especialmente comparar textos) são inúteis e potencialmente perigosas quando ordenadas por data, se houver a possibilidade de as datas de qualquer computador serem bagunçadas. O sistema mercurial subjacente tem uma forma de ordenar revisões independentemente da data do commit. O MacHg e o TortoiseHg exibem as revisões na ordem correta, ao mesmo tempo em que mostram
2. A interface atual para listar livros com um longo histórico de alterações fica bastante trabalhosa e poderia ser tornada mais útil para tentar rastrear alterações.

Então, há algum conselho sobre como posso ajudar a corrigir o projeto do meu colega? Alguém mais acha que uma solicitação de funcionalidade do Paratext para ajustar a ordem de classificação da exibição do histórico valeria a pena?

Tradução automática de English Mostrar original

Answer 1

rowbory:

3. Alguma mágica do hg para alterar os commits (publicados), seja usando rebase, collapse, evolve, histedit ou algo assim.

A modificação do histórico só faz sentido para conjuntos de alterações em rascunho. Portanto, a menos que se possa convencer um administrador S/R do Paratext a fazer as alterações para você no servidor S/R e coordenar com todos os usuários do projeto para que eles excluam suas cópias e, em seguida, façam S/R de uma cópia limpa depois, essa não é realmente uma opção segura.

Outra opção poderia ser uma solicitação de funcionalidade para:
4. Aprimorar a ferramenta “Convert Project” (ferramenta de administrador) do Paratext para corrigir automaticamente datas inválidas.

Tradução automática de English Mostrar original

Comments

Na minha opinião, esta é uma situação única o suficiente para que deva ser tratada externamente e não deva exigir que o PT seja reprogramado. Apenas meus 2 centavos.

Com base nas minhas próprias experimentações com mercurial, meu palpite é que você pode rebasear ou editar o histórico no mercurial, mas é provável que ele recalcule todos os hashes para os commits. Basicamente, você está bifurcando o projeto. Isso exigiria excluir o projeto do Registry e do computador de cada membro, e então compartilhá-lo novamente.

Tradução automática de English Mostrar original

---

Obrigado. Bom ter a confirmação. Essencialmente, o que eu esperava que fosse uma correção simples para mim fazer é, na verdade, um problema não trivial. Apenas acontece que é infeliz que o Paratext, ao contrário dos clientes mercurial, ordene pela data do commit em vez do ID da revisão.

Tradução automática de English Mostrar original

---

Uma coisa a ter em mente é que a ordem dos conjuntos de alterações (IDs de revisão) pode ser diferente para diferentes usuários. (Usar a data pelo menos torna as coisas consistentes para cada usuário). Além disso, se você tivesse um usuário que fizesse S/R com pouca frequência, as alterações que ele fez há muitos meses podem aparecer antes das alterações que outro usuário fez ontem. (se ordenado por ID de revisão)

Tradução automática de English Mostrar original