Appeal to respect the development history and time tracking

[Gregory Szorc]

On Tue, Aug 25, 2015 at 11:47 AM, Steve Borho <steve at borho.org> wrote:

> On 08/25, Arne Babenhauserheide wrote:
> > Am Dienstag, 25. August 2015, 07:26:45 schrieb Adrian Klaver:
> > > > At least add warning that all the date and time stamps of all files
> and
> > > > all directories would be destroyed _forever_ after using Mercurial
> SCM.
> > >
> > > What are you talking about?
> > >
> > > Or better yet, can you provide a coherent example?
> >
> > Even though I disagree with Mosc (especially on the apes thing), I can
> > provide an example:
> >
> > I use deft-mode[1] to organize my writings. It shows and filters text
> > files in a directory. For each file it shows the title (first line)
> > and the data, and it sorts by date.
> >
> > This weekend I had partial failure of the data on my system USB stick,
> > including that folder. Some files were lost, so I recloned the deft
> > directory -- and all files had the same date, so the ordering was wrong.
> >
> > I recovered very easily, though:
> >
> > hg up null
> > for i in {1..12}; do hg up ${i}00; done
> > hg up tip
> >
> > (I have ~1200 revisions in there)
> >
> > With that I had rising mtimes again.
> >
> > If I had wanted to spend more time, I could have updated to every
> > revisions, but I did not need exact ordering. Being mostly right was
> > OK :) (and USK sticks are horribly slow)
> >
> > If I had needed the exact time, I???d have used touch:
> >
> > for i in {1..1200}; do
> >   for j in $(hg log -r $i --template "{files}"); do
> >     touch --date "$(hg log -r tip --template "{date|isodate}")" $j;
> >   done
> > done
>
> I think it would be more efficient to iterate over `hg files` and call
> touch on each with the timstamp of its last commit.
>
> for j in $(hg files); do
>   touch $j --date "$(hg log -l1 $j --template "{date|isodate}")";
> done
>
> This could be wrapped into a 15 line extension as 'hg touch' or
> something similar.
>

Commit times are initially defined at the time of the original commit. By
default, if you rewrite history, the commit time is not refreshed. This can
result in commits from 2014 being pushed today. I can pretty much guarantee
that any repository with more than 1 author has commit times where the time
of commit N+1 is not always greater than commit N.

Also, commit times can be spoofed. See `hg commit --date`.

What you really would want to use is "push times." But that's not a concept
that exists in core Mercurial. Even if it did, you have to choose which
remote's times to use. Even if you did that, computer clocks aren't
reliable and are prone to skew and other weirdness. Yes, even on servers.

This feature cannot be implemented in a manner that would be reasonable.
The best Mercurial could do is set mtimes such that the times from commit
N+1 are newer than commit N. But the actual times would not correspond to
commit/push times. At that point, what's the point?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150825/eb3f14f1/attachment-0002.html>