want to store file's modification time during commit

I can confirm this on ubuntu linux hardy, bzr 1.3.1 using the bzr branch command.

It is a problem for the project I'm developing, because I want to deliver test files to the end user, and the file modification times of the test files are important to the functioning of the program - it processes them chronologically.

Everything else in my development and packaging toolchain seems to preserve file modification times (setuptools, tar, dpkg, etc), so bzr is the weak link in the chain, when I or others build a distribution from a branch other than my original trunk directory.

I guess I have to either always distribute from the original directory (not great for distributed development, and more risk of including unwanted files or changes) or deliver the files inside a zip archive or the like, and unpack them at install time.

Support for preserving file metadata like create and modification times would be useful in
many circumstances.

Modification times are far more portable and far less problematic than the permission and ownership metadata discussed in https://bugs.edge.launchpad.net/bzr/+bug/67589

Just upgraded from CVS to Bazaar, and although most things are far better (of course!) this is really annoying. CVS preserves file modification times and that happened to be pretty important for what I'm doing... even "bzr update" seems to change the modification times to the time of update rather than the actual time of modification.

We use Bazaar not only to store historical versions of project files, but also to manage a complex sync scenario involving online and offline users. Bazaar replaced our custom procedure based of a series of rsync calls, thats was working fine but very hard to manage. We found Bazaar very usefull and reliable.

But we have lost all our document history: modification time is an important file metadata and a lot of tools relies on it.
Worse, we lost the original timestamp on the initial commit: if you start using Bazaar on a new project or set of files, you can retry history information from the Bazaar metadata themself, not simple but feasible. But if you load a bazaar slot with a long history set of documents, there is no way (as I can see) to save the original timestamp of files.

BTW, a partial solution would be if we can have, at least, the last commit timestamp on each file, but this is not the case: using checkout or update, as stated, gives to all the files the same, current local computer time, that's makes no sense at all.

The fact that bzr doesn't support this is really a shock to me.

Bzr is slow. It should at least have nice features that faster VCSs have.
File modification times are important information. There is no arguing over it.

If it isn't preserved by default, bzr should provide an option to do so.

Seriously guys, why are we not doing this??

Note that for some use cases at least, there are ways to use bzr along with other software to preserve file modification times. See e.g.
http://joey.kitenet.net/code/etckeeper/

That may be able to serve as a model for how to add this to bzr.

No progress over it?

Who would be the best person to contact with regard to this?

On Wed, 2010-06-23 at 16:07 +0000, ℵ wrote:
> No progress over it?
>
> Who would be the best person to contact with regard to this?
I don't think there are any immediate plans for this. It should be
possible to write a plugin that stores this sort of metadata
in .bzrmeta/ and hooks into bzr core in various places to use a
different modification time.

Getting it supported in bzr core natively is significantly more work, as
it would involve changing the on-disk format.

Cheers,

Jelmer

Note that bug #488724 was fixed to address workflows involving building from sources via a Makefile.
Restoring modification time for files will break these workflows and we certainly don't want to make it
the default mode for bzr.

> Note that bug #488724 was fixed to address workflows involving building from sources via a Makefile.
> Restoring modification time for files will break these workflows and we certainly don't want to make it
> the default mode for bzr.

Restoring the original modification times of all files, source and generated, in the working tree would certainly not break make projects. On the contrary, it would cause make to figure out correctly which files were newer than which other ones.

> It should be
> possible to write a plugin that stores this sort of metadata
> in .bzrmeta/ and hooks into bzr core in various places to use a
> different modification time.

While someone is writing this hypothetical future plugin, they should store and restore file permissions and ACLs too. Thanks in advance :)

On Sun, Jun 27, 2010 at 1:38 PM, Andrew Schulman
<email address hidden> wrote:
>> Note that bug #488724  was fixed to address workflows involving building from sources via a Makefile.
>> Restoring modification time for files will break these workflows and we certainly don't want to make it
>> the default mode for bzr.
>
> Restoring the original modification times of all files, source and
> generated, in the working tree would certainly not break make projects.
> On the contrary, it would cause make to figure out correctly which files
> were newer than which other ones.

Actually that is only true when you have a central clock; when you
have multiple clocks - and bzr has one clock per committing machine -
then its entirely possible - if not likely - that one user will commit
something which a previous commit claimed a newer date, and then the
file is seen to go backwards by make; not triggering a build and
making a terrible mess.

The current approach has the following properties:
 - times start out all the same (checkouts of generated files do not
do spurious builds)
 - all modifications by bzr move the timestamp forward, because local
system time is used (other users cannot break builds due to
timestamps).

ACL's etc would be nice, but are orthogonal IMO.

-Rob

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

Robert Collins wrote:
> On Sun, Jun 27, 2010 at 1:38 PM, Andrew Schulman
> <email address hidden> wrote:
>>> Note that bug #488724 was fixed to address workflows involving building from sources via a Makefile.
>>> Restoring modification time for files will break these workflows and we certainly don't want to make it
>>> the default mode for bzr.
>> Restoring the original modification times of all files, source and
>> generated, in the working tree would certainly not break make projects.
>> On the contrary, it would cause make to figure out correctly which files
>> were newer than which other ones.
>
> Actually that is only true when you have a central clock; when you
> have multiple clocks - and bzr has one clock per committing machine -
> then its entirely possible - if not likely - that one user will commit
> something which a previous commit claimed a newer date, and then the
> file is seen to go backwards by make; not triggering a build and
> making a terrible mess.

Even then:

 # modify foo.c
 make
 # oops, I don't like that anymore
 bzr revert
 make #no-op because now foo.c is older than your previous modification

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

iEYEARECAAYFAkwpAqcACgkQJdeBCYSNAAN7nwCfSU5YcKVj+/vHLqnwIGRnMAD1
zUkAn0HetPSRqCW28ZzxH58ouLhWwyZJ
=W3I0
-----END PGP SIGNATURE-----

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

Andrew Schulman wrote:
>> Note that bug #488724 was fixed to address workflows involving building from sources via a Makefile.
>> Restoring modification time for files will break these workflows and we certainly don't want to make it
>> the default mode for bzr.
>
> Restoring the original modification times of all files, source and
> generated, in the working tree would certainly not break make projects.
> On the contrary, it would cause make to figure out correctly which files
> were newer than which other ones.
>
>> It should be
>> possible to write a plugin that stores this sort of metadata
>> in .bzrmeta/ and hooks into bzr core in various places to use a
>> different modification time.
>
> While someone is writing this hypothetical future plugin, they should
> store and restore file permissions and ACLs too. Thanks in advance :)
>

BTW, did you look at 'etckeeper' which is a high level wrapper around a
few VCS tools and does store at least Unix permissions and I think
modification times (it might only do unix perms.)

John
=:->

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

iEYEARECAAYFAkwpA0wACgkQJdeBCYSNAAPWLgCg0dgkvbHrilEIHrQWMY+NE/Ol
u+gAoLCorA/7aYIl/GrmS8YHt30Mv1iK
=+XnS
-----END PGP SIGNATURE-----

Any progress on this? I would very much like to adopt BZR, but will not until there is an OPTION to preserve "mtime" as metadata in the repository, along with the file content. I have too many tools in my tool chain that are dependent on a file's timestamp, including my brain.

Tim

On Mon, Jan 31, 2011 at 03:52:12PM -0000, Tim Halvorsen wrote:
> Any progress on this? I would very much like to adopt BZR, but will not
> until there is an OPTION to preserve "mtime" as metadata in the
> repository, along with the file content. I have too many tools in my
> tool chain that are dependent on a file's timestamp, including my brain.
This will require a format change, it's not on the current agenda as far as I know.

It should be possible to work around it by writing a simple plugin that operates
in a fashion similar to e.g. etckeeper. Etckeeper hooks into Bazaar and keeps
a metadata file (".etckeeper") up to date with extra file metadata.

Cheers,

Jelmer

I agree - it probably is possible to write it myself. Obviously, I was hoping
to add to the number of votes that might motivate this work to be done in the
core product rather than as an add-on.

If I had the support of the core team that such an enhancement could eventually
be merged back into the base tree, I might be motivated to work on it (e.g. if
it benefits just me, I'm not sure if its worth the time, but if it benefits many
people, I might be more interested in spending the time) -- is there support for
this?

Do you know anyone who might have already started working on such an plugin?

- Tim

________________________________
From: Jelmer Vernooij <email address hidden>
To: <email address hidden>
Sent: Mon, January 31, 2011 2:03:36 PM
Subject: Re: [Bug 245170] Re: want to store file's modification time during
commit

On Mon, Jan 31, 2011 at 03:52:12PM -0000, Tim Halvorsen wrote:
> Any progress on this? I would very much like to adopt BZR, but will not
> until there is an OPTION to preserve "mtime" as metadata in the
> repository, along with the file content. I have too many tools in my
> tool chain that are dependent on a file's timestamp, including my brain.
This will require a format change, it's not on the current agenda as far as I
know.

It should be possible to work around it by writing a simple plugin that operates

in a fashion similar to e.g. etckeeper. Etckeeper hooks into Bazaar and keeps
a metadata file (".etckeeper") up to date with extra file metadata.

Cheers,

Jelmer

--
You received this bug notification because you are a direct subscriber
of the bug.
https://bugs.launchpad.net/bugs/245170

Title:
  want to store file's modification time during commit

Status in Bazaar Version Control System:
  Confirmed

Bug description:
  Checkout should have an option to preserve the modification times of
  the files. At least in a lightweight checkout on Windows and NTFS
  shared over SMB, the checked out files get the time of the checkout as
  their modification time. I'm trying to use bzr to synchronize and
  backup files between my laptop and a file server. Other people can
  sometimes modify the files on the server while I'm working on the
  files on my laptop. I'm keeping the history on my laptop to save disk
  space on the server so I use a lightweight checkout. Having the
  original (and more meaningful) modification times on the server would
  be nice.

To unsubscribe from this bug, go to:
https://bugs.launchpad.net/bzr/+bug/245170/+subscribe

On 2 February 2011 15:34, Tim Halvorsen <email address hidden> wrote:
> I agree - it probably is possible to write it myself.  Obviously, I was hoping
> to add to the number of votes that might motivate this work to be done in the
> core product rather than as an add-on.
>
> If I had the support of the core team that such an enhancement could eventually
> be merged back into the base tree, I might be motivated to work on it (e.g. if
> it benefits just me, I'm not sure if its worth the time, but if it benefits many
> people, I might be more interested in spending the time) -- is there support for
> this?
>
> Do you know anyone who might have already started working on such an
> plugin?

I don't know of anyone who's already done it. I don't think this
should be on by default but we could probably find a clean way to put
it in core, and I do think it would be more discoverable and more
likely to be maintained by the core team and community if it was
there. If you're interested we can help you add the hooks etc that
will let it be turned on. Even in core it should be done through a
hook-based approach rather than patching all over the place.

Wow, this (lack support for file date/time preservation) is really disappointing :-(

I abandoned Git for this, among other reasons.

I was under the belief that Bazaar preserved file date/time info because that's what Wikipedia says here:

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Advanced_features

Can anyone on this list correct that error?

I would go back to Subversion, but I've experienced too many instances of project corruption in mixed Mac/Windows environments.

I understand the "multiple un-synchronized clocks" problem with date/time dependent build systems, and I would suggest that being date dependent is a weakness of the build system, not a problem for a VCS to handle. There are many environments where approximate date/time information is important. Directory sync as discussed above, writers/authors, web sites, among others.

I'm more than a little surprised to see that the DVCS community as a whole (Bazaar, Git, Mercurial) seems to share the idea that date/time metadata is better ignored or overwritten. When the real solution is probably in a combination of some form of master clock/forward only clock enforcement.

I know you can't please everyone, but for me, this feature was the big 'selling' point for Bazaar, it's expected in a central VCS system and would be valuable for those who are used to these systems.