timestamps and export

[Martin Pool]

On Sat, May 31, 2008 at 2:08 AM, James Westby <jw+debian at jameswestby.net> wrote:
> Hi all,
>
> There is a bug in the builddeb plugin that is caused by exporting
> the same branch twice at different times, and so getting two
> different tarballs.
>
> It may be possible to solve this a different way, but it may require
> changes to the export code. I would like to make it possible to
> specify a timestamp to the exporter, which, if given, would then be the
> timestamp set on all files.

This is a bit surprising to me - I was looking at the tarball export
code last week and it does see to make an effort to pass the timestamp
of the revision.  So this may just be a bug...

> I looked briefly at doing this, however there is an API compatiblity
> problem. An exporter is simply a function, so we cannot add a parameter
> as it would break any other exporters. If it were a class then I would
> add a new function and use a hasattr check to find if the timestamp
> could be passed.
>
> Would the preferred way to do this be to add a new registry for
> exporters that take the parameter and prefer this when searching
> for them? In this case should the deprecation warning be given when
> the exporter is registered or used?

I would think about changing that registry so that it can hold either
functions or classes, and then gradually move away from putting just
functions in there.  I would say that using just a function for a
public interface that may need to evolve has generally turned out to
be a mistake.

I don't think you should add a new registry.  Deprecations should
happen at registration time...

Also, at the moment the tarball exporting is partly done inside the
InventoryEntry iirc, and it should be separated into just the exporter
asking the tree for the necessary data.

-- 
Martin <http://launchpad.net/~mbp/>