Jelmer Vernooij wrote:
> Jelmer Vernooij has proposed merging lp:~jelmer/bzr/export-use-tree-timestamp into lp:bzr.
>
> Requested reviews:
> bzr-core (bzr-core)
>
>
> This adds an extra argument ``use_tree_timestamp`` to the exporters, to use the commit time of the commit in which a file revision was introduced as the mtime when exporting. This is useful as a means of getting deterministic exports (i.e. the generated tarball from a particular revision is always the same).
>
> use_tree_timestamps is not the default for performance reasons, but the provided infrastructure is useful for bzr-builddeb.
>
Note that using 'tree.get_file_mtime()' for each file is a bit of a
shame. Specifically, the api doesn't really do any caching (and it isn't
very easy to do so).
If we wanted it to perform well, doing 1 pass over the inventory to find
revisions we will care about, doing another request to read all of those
revisions in 1 pass, should actually be pretty decent. (log can display
all revisions in generally a rather decent amount of time, this should
be no slower than that.)
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jelmer Vernooij wrote: timestamp` ` to the exporters, to use the commit time of the commit in which a file revision was introduced as the mtime when exporting. This is useful as a means of getting deterministic exports (i.e. the generated tarball from a particular revision is always the same).
> Jelmer Vernooij has proposed merging lp:~jelmer/bzr/export-use-tree-timestamp into lp:bzr.
>
> Requested reviews:
> bzr-core (bzr-core)
>
>
> This adds an extra argument ``use_tree_
>
> use_tree_timestamps is not the default for performance reasons, but the provided infrastructure is useful for bzr-builddeb.
>
Note that using 'tree.get_ file_mtime( )' for each file is a bit of a
shame. Specifically, the api doesn't really do any caching (and it isn't
very easy to do so).
If we wanted it to perform well, doing 1 pass over the inventory to find
revisions we will care about, doing another request to read all of those
revisions in 1 pass, should actually be pretty decent. (log can display
all revisions in generally a rather decent amount of time, this should
be no slower than that.)
John
=:->
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org/
VKG0ACgkQJdeBCY SNAAMtNQCgqkS8W /byYFqC3XpeK9Qe QCjV NfUFmqnOwEwuYYL DQ
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAku
fVcAmgNaJOolG9y
=b4zc
-----END PGP SIGNATURE-----