how do I preserve file modification times of unchanged files?

Asked by pkommoju

I have a need to preserve the modification of times unchanged file in the repository to left undisturbed by a commit to those files; and conversely to get the repository times on a branch/clone/checkout.

Is there a way to do this in the current version (2.0), if not, is there a plan to support it in the not too distant future? This is rather important feature for folks trying to move from the likes of CVS/SVN etc. We follow a rather centralized repository model so all those problems pointed out in a few other discussions do not actually pose a problem for our model of development.

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
Martin Pool
Solved:
Last query:
Last reply:
Revision history for this message
Martin Pool (mbp) said :
#1

Sorry can you try to explain more clearly what it is you want?

Revision history for this message
pkommoju (pkommoju) said :
#2

1) When I do a bzr branch/clone/checkout etc from a central repository
I want all files in the local branch to have exact file modification
timestamps (creation, access and modification times of the file) as
they are in the central repository.

2) When I commit a merge bundle I want the committed to get the
timestamps from the merge bundle instead of when the bundle is merged
an committed into the repository. I think this part is not as critical
as (1).

On 12/14/09, Martin Pool <email address hidden> wrote:
> Your question #94116 on Bazaar changed:
> https://answers.edge.launchpad.net/bzr/+question/94116
>
> Status: Open => Needs information
>
> Martin Pool requested for more information:
> Sorry can you try to explain more clearly what it is you want?
>
> --
> To answer this request for more information, you can either reply to
> this email or enter your reply at the following page:
> https://answers.edge.launchpad.net/bzr/+question/94116
>
> You received this question notification because you are a direct
> subscriber of the question.
>

--

Best Regards,
Prasad Kommoju

Revision history for this message
Best Martin Pool (mbp) said :
#3

1- This seems to be bug 245170?

2- Bazaar does not change the modification times when it commits files. Do you want it to?

Revision history for this message
pkommoju (pkommoju) said :
#4

(1) seems to be related the bug 245170 but 245170 seems a little specific to NTFS and lightweight checkouts. What I am looking for is for branch and checkout to preserve the modification times. It seems like this should be the default but a --preserve-times or some such options would do just fine.

I hope there is going to a generalized fix for 245170 within the next couple of releases.

(2) I wanted it to take the modification times in the merge directive but the times the files actually get are the time of the commit it self. They are usually not that far apart so whatever commit is currently doing is also acceptable.

Thank you very much for your time and interest in this matter.

Prasad Kommoju
<email address hidden>

Revision history for this message
John A Meinel (jameinel) said :
#5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pkommoju wrote:
> Question #94116 on Bazaar changed:
> https://answers.edge.launchpad.net/bzr/+question/94116
>
> Status: Answered => Solved
>
> pkommoju confirmed that the question is solved:
> (1) seems to be related the bug 245170 but 245170 seems a little
> specific to NTFS and lightweight checkouts. What I am looking for is for
> branch and checkout to preserve the modification times. It seems like
> this should be the default but a --preserve-times or some such options
> would do just fine.
>
> I hope there is going to a generalized fix for 245170 within the next
> couple of releases.

This is probably appropriate in some cases, but it generally is not the
most appropriate. Consider a case where I commit a version today. After
2 weeks you merge my work and trigger your build process.

If we created the files with the timestamp of my commit, it is likely
that your build process would see them as 2 weeks too old, and not
rebuild those files. (As most of them compare the timestamp of the file
with the timestamp of its output to see if there is anything to do.)

As such, *most* of the time it is more reasonable to modify files and
give them the current time.

Note that this also affects things like "bzr revert". If you made some
changes (timestamp right now), built the project, and then realized you
didn't like the changes so ran 'bzr revert'. At that point, your
proposal would revert the timestamps to *older* which would again cause
the build process to not rebuild.

I'm happy to have us include a flag to support your use case, I don't
think it should be the default. Primarily, bzr is about versioning
source code, so the default behaviors should be for integration with
those sorts of tool chains.

Note that if we had a '--preserve-times' or a '--set-timestamp' or
whatever flag, you could use "bzr alias merge=merge --preserve-times"
and then a plain 'bzr merge' would do what you wanted.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksnMQUACgkQJdeBCYSNAAPnQwCfaLvIGa7Y9v3vqCsRSCEb4cQb
++cAn0Pj5xYfSzJoKAVXLex0ZtpXf0Yu
=L5kv
-----END PGP SIGNATURE-----

Revision history for this message
pkommoju (pkommoju) said :
#6

John,

Thank you very much for going into such a detail.

Since there was a closely related bug already in your database, all I
could say, w.r.t (1) was that my problem is solved, with the hope that
there might be a solution in future.

I can see the commit/revert interaction with preserving times and how
it affects the following make, but at a different level, revert got me
a file as it existed in the past and I should expect all the
information to appear to never even changed -- file contents and
metadata. By giving a reverted file current times, the fact that the
file never changed in any way is lost. I would consider this loss of
information a more serious problem than a clean build after such
drastic actions as revert. But I could accept that what is critical in
these situations is somewhat subjective.

I am new to Bazaar but not to VCS in general but I am trying my
colleagues to adapt to Bazaar, who gave CVS a short trail almost a
decade and never bothered with any VCS since then. Every little
inconvenience on top of the biggest inconvenience of having to learn a
new tool creates more resistance. I guess quite a few CVS/SVN folks
would want an option to carry over the modification times from central
repo to local branch.

It would be really great if you could consider this use case as having
enough merit to warrant an enhancement to an already good tool.

On 12/14/09, John A Meinel <email address hidden> wrote:
> Your question #94116 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/94116
>
> John A Meinel posted a new comment:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> pkommoju wrote:
>> Question #94116 on Bazaar changed:
>> https://answers.edge.launchpad.net/bzr/+question/94116
>>
>> Status: Answered => Solved
>>
>> pkommoju confirmed that the question is solved:
>> (1) seems to be related the bug 245170 but 245170 seems a little
>> specific to NTFS and lightweight checkouts. What I am looking for is for
>> branch and checkout to preserve the modification times. It seems like
>> this should be the default but a --preserve-times or some such options
>> would do just fine.
>>
>> I hope there is going to a generalized fix for 245170 within the next
>> couple of releases.
>
> This is probably appropriate in some cases, but it generally is not the
> most appropriate. Consider a case where I commit a version today. After
> 2 weeks you merge my work and trigger your build process.
>
> If we created the files with the timestamp of my commit, it is likely
> that your build process would see them as 2 weeks too old, and not
> rebuild those files. (As most of them compare the timestamp of the file
> with the timestamp of its output to see if there is anything to do.)
>
> As such, *most* of the time it is more reasonable to modify files and
> give them the current time.
>
> Note that this also affects things like "bzr revert". If you made some
> changes (timestamp right now), built the project, and then realized you
> didn't like the changes so ran 'bzr revert'. At that point, your
> proposal would revert the timestamps to *older* which would again cause
> the build process to not rebuild.
>
> I'm happy to have us include a flag to support your use case, I don't
> think it should be the default. Primarily, bzr is about versioning
> source code, so the default behaviors should be for integration with
> those sorts of tool chains.
>
> Note that if we had a '--preserve-times' or a '--set-timestamp' or
> whatever flag, you could use "bzr alias merge=merge --preserve-times"
> and then a plain 'bzr merge' would do what you wanted.
>
> John
> =:->
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAksnMQUACgkQJdeBCYSNAAPnQwCfaLvIGa7Y9v3vqCsRSCEb4cQb
> ++cAn0Pj5xYfSzJoKAVXLex0ZtpXf0Yu
> =L5kv
> -----END PGP SIGNATURE-----
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
>

--

Best Regards,
Prasad Kommoju (RP),
Database Architect

CfMC Research Software
547 Howard Street
San Francisco, CA 94105
http://www.cfmc.com