[hg update] Wrong file date after an update. Is it a bug ?

[Kastner Masilko, Friedrich]

From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Mads Kiilerich
> William Ledoux wrote, On 10/02/2009 06:48 PM:
>> It could be used, for instance, to know immediatly if a file has been
>> changed before an other, or if a file from different clones at different
>> revisions has been changed between these revisions: without using the
>> history.
>>
>> Actually, "somebody" may be me.
>> I have my repository, with different dates for each file. And then I
>> commit (Revision 12), and then some new modifications, and I commit
>> again (rev 13). If I immediatly update to revision 12, I expect my
>> folder to be exactly as it was 10 seconds before, and instead of that I
>> losed all the modification dates.
>>
>> It seems weird to me.
>
> FWIW it seems weird to me that you rely so much on file system dates 
> when you have all the information available as immutable metadata in 
> Mercurial.
>
> Mercurials focus is source code management. If you say your usecase is 
> different from this then another behaviour than the one from plain 
> Mercurial might be more suitable for you. That is why you will have to 
> use an extension.
>
>> Thank you for the Timestamp extension. Maybe my english is not very
>> good, I understood that I had to specify each file i want to track the
>> modifications dates of. Am I wrong ?
>
> You are probably right. And yes, that might not be convenient for your 
> use case. So unless you or somebody else improves the extension 
> Mercurial might not be the perfect tool for you.

I think I should chime in here and explain the origin of TimestampExtension a bit.

The extension was born out of a quite unusual use-case. We use Mercurial at work
for all kinds of projects, one of them using an IDE that includes timestamps of
libraries in the project's main source. On starting up the IDE for this project,
it will complain about library changes whenever the timestamps changed for the
library files.

Therefore, I wrote the extension to keep only certain file's timestamps under
version control. Doing it for all files would mean to manage a big database, so
the extension's approach is not suitable for your use-case IMHO.

OTOH, I plan to improve the extension with a feature that Esben Skovenborg wrote
( http://bitbucket.org/esskov/hg_timestamp_update ) for another use-case: updating
all file's timestamps to the timestamp of the commit on update. Not sure if this
will help your case, though.

That said, you can of course use the TimestampExtension to get what you want. Just
pipe the manifest into .hgtimestamp with "hg manifest > .hgtimestamp", and issue
"hg timestamp -s". I'd be interested what the performance would be, though...

regards,
Fritz

Development Software Systems
Festo Gesellschaft m.b.H.
Linzer Strasse 227
A - 1140 Wien

Firmenbuch Wien
FN 38435y

Tel: +43(1)91075-198
Fax: +43(1)91075-282
www.festo.at

Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das Material von Ihrem Computer zu loeschen. 

This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this e-mail, please delete it and immediately notify the sender.