Changes between Version 25 and Version 26 of TracTicketsCustomTimeFields

Timestamp:

Apr 21, 2010, 9:18:50 PM (14 years ago)

Author:

hoff.st@…

Comment:

mention rebase at Trac trunk r9478, paragraph on migration from date/time text fields added, some more text formatting

TracTicketsCustomTimeFields

@@ -34 +34 @@
  http://bitbucket.org/hasienda/custom-time/overview
 
-''base'': patches apply cleanly to Trac trunk r9443, cloned/pulled from rblank's Mercurial repository at bitbucket.org.[[BR]]
+''base'': patches apply cleanly to Trac trunk r~~9443~~9478, cloned/pulled from rblank's Mercurial repository at bitbucket.org.[[BR]]
 ''quality'': beta - code flaws should have not much effect, at least not to trac db, from now on only minor changes expected until stable release[[BR]]
 ''focus'': bug-fixes, working ticket change notification for both [TracNotification Trac Notification] system and [th:wiki:AnnouncerPlugin AnnouncerPlugin][[BR]]
@@ -61 +61 @@
   b. datetime.datetime values from user input for change-in-progress, directed to preview current custom time field changes
   c. old date/time strings, i.e. from previous use of custom text fields for date/time, directed to ticket changes list
-  d. any wired value, that is actually take care for as well, as long it has a string representation
+  d. any weird value, that is actually take care for as well, as long it has a string representation
  * ticket diff view for change history exposes raw values from db, should convert microseconds POSIX to pretty time stamp string
  * bad conversion of date/time value {{{None}}} to db string value {{{'None'}}} instead of {{{''}}}, gets overwritten with current date on next change, no date/time value deletion possible so far
@@ -75 +75 @@
 ==== Time stamp format ====
 There was no argument against storing time stamps as string to arrange with current type definition "string" for values in ticket_custom db table. But switching to microseconds time stamp format recently adopted for Trac internal time fields ''time'' and ''changetime'' seems to be better than sticking with the former Unix time stamp, even if I prepared support for fractions of seconds by converting custom timestamps to float before.
+
+==== Migrating from date/time strings ====
+I keep thinking of the case, where one already has a pile of date and wishes to switch to new date/time type now. Hope he/she finds it convenient that old values will be converted (silently) by current code, whenever a ticket is updated. But someone might come up with something like a db upgrade script for batch conversion/migration all a once. I think I'm not enough of a SQL guru to do that. So suggestions and contributions on the subject are very welcome.
 
 ==== Unit tests ====
@@ -109 +112 @@
  As adoption of code from [th:wiki:AnnouncerPlugin AnnouncerPlugin] is far from ready to replace current Ticket Notification, I feel the need to patch it as well. Right?
 
-==== Development trace ====
+==== Development traces ====
 Happened to have access to !SourceForge, so I choose to go and push code into a Mercurial repository there to enable collaboration based on a distributed VCS as per suggestion from IRC channel #trac at freenode.net.
  rblank offered to rebase my code on top of code from his own repository, so a least he would be able to rewiev more easily. I'll try it and combine this move with a trial on Mercurial patch queue.
   '''Done''', re-based on clone of rblank's Mercurial repository, all changes converted to patch series,[[BR]]cleared repository on Sourceforge, because previous work was to dirty and non-functional in early tests, I found that I forgot to ''--addremove'' after pull/merge and so missed new files as well as deletions
 
-Current development is based on Trac-0.12dev_~~r9115~~r9443 (see current state), testet with Python2.5 on ''Debian GNU/Linux'' stable. However it would be great to have it in trunk soon (trac-0.12.x?).
-  (cboos): that's way too old to base new development upon, especially for timestamp related development, as r9210 introduced a big change here (time are now stored as microseconds elapsed since epoch, as bigints).
-    Ah, well, thanks for the hint. We're at r9420 right now, any recommendation where to start from other than HEAD? 
-     (cboos): why not HEAD? Latest trunk should be fine. We're about to release a rc1 or a beta soon, so that might provide a stable basis.
-      The question was obsoleted by current development. And I'll continue to work hard to keep pace and match all reasonable demands ASAP.
-    I'll have to reinstall my test platform here and re-base changes then. However starting with standard unix time seconds was easier to debug for me (i.e. comparing to date +%s). And to_timestamp() messed up the date values converted from mxDatetime for some reason. I went for the included mxDatetime.Datetime.ticks() function to get good unix time seconds. So I may still need an own function to calculate unix time microseconds from unix time seconds.
-     Checked changes between r9115 and r9435, prepare for updates this weekend. Found 23 changesets that did modify files I touched by now. Sounds quite big. Try to figure out a way to do it save for now, postpone to do it clever with least effort later. Might want to use Mercurial Queues or the like, but I fell I don't understand all the consequences.
-      Halfway done, 11 merges are in the repository now, most importantly merged with the microseconds time stamp changeset r9210. In fact especially that changeset was not at all related to my modifications. I didn't touch my old function, that still uses ''to_datetime(ts)'' instead of the new ''from_utimestamp(ts)''. I don't use ''to_timestamp(dt)'', but the conversion from within class ''mxDateTime.!DateTime.ticks()''. However for the sake of clarity I think it will be good to shift to microseconds timestamps for custom timefields too. So this is on my !ToDo after finishing the whole merge marathon.
-       '''Done''', merged changes for custom time field support with SVN changes up to trac SVN changeset r9442.  
+Current development is based on Trac-0.12dev_~~r9115 r9443~~ r9478 (see current state), tested with Python2.5 on ''Debian GNU/Linux'' stable - 5.0, codename lenny. However it would be great to have it in trunk soon (trac-0.12.x?).
+ (cboos): that's way too old to base new development upon, especially for timestamp related development, as r9210 introduced a big change here (time are now stored as microseconds elapsed since epoch, as bigints).
+  Ah, well, thanks for the hint. We're at r9420 right now, any recommendation where to start from other than HEAD? 
+   (cboos): why not HEAD? Latest trunk should be fine. We're about to release a rc1 or a beta soon, so that might provide a stable basis.
+    The question was obsoleted by current development. And I'll continue to work hard to keep pace and match all reasonable demands ASAP.
+  I'll have to reinstall my test platform here and re-base changes then. However starting with standard unix time seconds was easier to debug for me (i.e. comparing to date +%s). And to_timestamp() messed up the date values converted from mxDatetime for some reason. I went for the included mxDatetime.Datetime.ticks() function to get good unix time seconds. So I may still need an own function to calculate unix time microseconds from unix time seconds.
+   Checked changes between r9115 and r9435, prepare for updates this weekend. Found 23 changesets that did modify files I touched by now. Sounds quite big. Try to figure out a way to do it save for now, postpone to do it clever with least effort later. Might want to use Mercurial Queues or the like, but I fell I don't understand all the consequences.
+    Halfway done, 11 merges are in the repository now, most importantly merged with the microseconds time stamp changeset r9210. In fact especially that changeset was not at all related to my modifications. I didn't touch my old function, that still uses ''to_datetime(ts)'' instead of the new ''from_utimestamp(ts)''. I don't use ''to_timestamp(dt)'', but the conversion from within class ''mxDateTime.!DateTime.ticks()''. However for the sake of clarity I think it will be good to shift to microseconds timestamps for custom timefields too. So this is on my !ToDo after finishing the whole merge marathon.
+     '''Done''', merged changes for custom time field support with SVN changes up to trac SVN changeset r9442.
+      Re-based on r9478 meanwhile, nothing to update inside my patches. Nice. Time to move on.
 
 == Alternative approaches ==