* Lele Gaifax [Sat, 24 Jun 2006 13:42:37 +0200]:
> Hi,
Hey again,
> first of all, thanks a lot for the nice and clear test case. Then to
> provide even the fixes for bzr!
Sure, no problem. :)
> I was about to apply your patches, when I realized that a similar fix
> would reasonably be mirrored on other backends too.
Actually, I'm glad you didn't apply them, since I've been poking at the
code a bit further than bzr.py, and realized that it was probably
svn.py's fault, not bzr's, for providing an UTC datetime without marking
it as such. With a one-line patch to svn.py, the 01a patch is not
necessary.
I've noticed that, AFAICS, no source backend gives a proper timezone to
the changeset.date they create, which causes then headaches to target
backends, because of missing info.
My plan now is to go through the code, and change source backends to set
the timezone, and (if necessary) fix those target backends that had
workarounds in place for the lack of such info (eg., bzr.py after
applying my patch -- thankfully reverting that one won't be necessary. :)
[See "Implementation detail #1" below.]
> What about generalizing the concept
> [bzr:dummy]
> subdir = bzr
> timezone = UTC
> [svn:dummy]
> subdir = svn
> module = /
> repository = file:///tmp/tailor/dummy
> timezone = Europe/Madrid
> Both timezones would default to local one (basically what happens right
> now). By specifying one, the backend should perform the needed
> conversion to/from UTC (respectively for the source and the target backend).
> What do you think?
Yeah, makes sense, though not in every combination of role/VCS. I mean
that the 'timezone' option:
- makes sense in source backends only for VCS that store local
timestamps without storing timezone info (and I'd be surprised to
find a modern VCS that does that; maybe CVS... will look it up).
- makes sense in target backends only for VCS that can store timezone
info, like eg. bzr, but unlike eg. (TTBOMK) svn, which just stores
all dates in UTC, period.
[See "Implementation detail #2" below.]
The interesting bit is that, by implementing that, assigning different
timezones to different commits in a hook function, eg. a timezone per
committer, will instantly work. With respect to this:
> More, I'm not pleased about forcing use of an hook to fix the dst bit.
As seen, the hook will only be needed if different timezones for
different commits are wanted.
> I'm sad not having much spare time for tailor right now, but I'll try to
> figure out how your test could be integrated and generalized for other
> backends. That would be beautiful.
As I said, I'll be also looking into this in the following days, and
will hopefully come up with a patch for review, if you'd like.
* * *
Implementation details
----------------------
As, I guess, a hard dependency on the (fairly big) pytz library is not
wanted, I was planning on the following (suggestions welcome):
#1: for this part of the implementation (supplying tzinfo to datetime
in source backends), do not require pytz at all. Instead, bundle in
vcpx/tzinfo.py or so a simple implementation of a FixedOffset tzinfo
from pytz (license is BSD), and use only that. This makes sense
because VCS will store timezones as an offset wrt UTC, not with a name.
#2: for this second part (where users can specify the timezone they
want), require pytz if a timezone by name is specified (and note so in
the documentation), but also allow to specify it like 'timezone = -0500',
in which case pytz is not needed an the FixedOffset local implementation
is used.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Cujo - Popsicle
_______________________________________________
Tailor mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/tailor
