reset file modification time when go back in time?

[dhruva]

Hi,
 Thank you for the detailed explanation you have provided. I still
have a fundamental doubt, why do we need time stamp information to go
across repositories through pull/push/clone?

For all SCM purposes, the ordering should be based strictly the
parent-child hierarchy and not based on time stamp. Apart from the
need (build related), where else do we need the time stamp
information? Once we have a list of time stamp requirement, maybe we
could think about the scope of the time stamp information
(local/outside repo visibility)


On 11/6/07, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> On 2007-11-06 14:33, dhruva <dhruvakm at gmail.com> wrote:
> >On 11/6/07, Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> >> It is all based on the false assumption that "timestamps only
> >> make sense locally".  They don't.  Timestamps are useful for
> >> tracking when something was committed too :/
> >
> > Well, then that extra information (file with time stamp data) can be
> > made available across repositories. We will then have to use a time
> > zone neutral format to store times.
>
> I don't see how "time zone neutral times" would help.  Consider this
> case (the left column is timestamps in a formar similat to 'UNIX seconds
> since the Epoch', which is timezone neutral):
>
> 10.000          A repository includes files 'a' and 'b'
> 10.100          Developer 1 clones the repository
> 10.120          Developer 2 clones the repository
> 10.205          Developer 1 commits fix affecting file 'a'
>                 in her local tree
> 10.206          Developer 2 commits fix affecting file 'a'
>                 in her local tree
> 10.207          Developer 2 commits fix affecting file 'b'
>                 in her local tree
> 10.300          Developer 1 pushes
> 10.305          Developer 2 tries to push, but fails (multiple heads)
> 10.306          Developer 2 pulls, and merges keeping the fix of
>                 developer 1 for the 'a' file
> 10.307          Developer 2 commits the merge locally, and pushes
>
> Now, what would you have the timestamp of 'a' be?  The final contents of
> the file are essentially the same as those committed by developer 1 at
> time 10.205, but they are also affected by the merge done by developer 2
> at time 10.306.

 When developer 2 pushes, since contents of 'a' is not changed with
respect to the parent repo, I presume (correct me if I am wrong) 'a'
will not be part of the changeset. The last modification to 'a' will
still be in the changeset pulled by developer 2 with the changes from
developer 1. Hence, the timestamp for file 'a' will be from the
changeset pushed by developer 1 with changes to 'a' (10.205).

 I completely agree making the timestamp information visible out of
the repo is extremely tricky. A top level solution to the scenario you
mentioned would be to have time stamp per changeset (and not on a per
file basis).

> Importing changesets created at a past date, with their full changelog
> header can also mess things up.  There is at least one patch I have
> submitted to Mercurial itself which was imported weeks after the date I
> made it, so the changeset says the timestamp was 3 weeks ago from its
> parent changeset!

Since we are using timestamps only to set the file's time stamp on
update, this really should not be a problem. The files in the parent
changeset will have a later time stamp than that of its children. Once
files are updated from the repo to file system (in editable format),
the hierarchy information really is not required.
If we do not see a need for timestamp info to be available out of the
repo, this problem will never arise. We need to make a time stamp
requirement list to decide on the visibility.

Please let me know if I am missing something very basic and taking
this discussion in the wrong direction.

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!