Difference between revisions of "Version support for datastore/Progress"

From Sugar Labs
Jump to navigation Jump to search
(create page, copy timeline from proposal)
 
(report on progress)
Line 37: Line 37:
  
 
== Progress ==
 
== Progress ==
 +
 +
=== 2009-05-16 ===
 +
[[Marketing Team/Events/MiniCamp Paris 2009|SugarCamp]] was great! I got to know a lot of
 +
the SugarLabs people - they're a cool bunch. :)
 +
 +
Time in general was too short to do anything more than getting to know each other,
 +
but Tomeu quickly showed me an old effort at introducing version support into data
 +
store that I didn't know about (both
 +
[http://git.sugarlabs.org/projects/sugar-datastore/repos/mainline/logs/version_prototype data store]
 +
and
 +
[http://dev.laptop.org/git/journal-activity/commit/?id=85ecee9bc094cd0f8f1bb7d7874ba7c7788eaafd Journal]).
 +
It looks quite interesting API-wise (simply adds another,
 +
optional parameter called <code>vid</code> that can be used to request a specific version).
 +
Also had some time with Bernie and he offered to set up a host for VMs
 +
(for our [http://buildbot.sugarlabs.org/ build bots]).
 +
 +
Unfortunately we also catched some virus in Paris, so I had to lay in bed for the next
 +
two weeks.
 +
 +
=== 2009-06-01 ===
 +
 +
Slowly getting up to speed again, diving a bit into data store code (both old and new)
 +
while fixing the build infrastructure (about the same time as we ran SugarCamp
 +
Gnome did some largish changes in [http://live.gnome.org/Jhbuild jhbuild] that broke our
 +
[[Development Team/Jhbuild|sugar-jhbuild]]).
 +
 +
Discussed some possible data store API changes with [[User:alsroot|alsroot]], but they
 +
didn't really interfere with my design and we decided to discuss them again after the
 +
version support is finished.
 +
 +
[[User:tomeu|Tomeu]] had the idea of treating the current <code>object_id</code>
 +
(distinguishing between instances of an activity) as a combined instance and version
 +
identifier and introducing a new
 +
"<code>super_object_id</code>" that does what <code>object_id</code> does now. The
 +
advantage would be that activities could transparently access old versions. If we'd
 +
introduce a <code>version_id</code> in parallel to <code>object_id</code> (the naive
 +
approach taken by the old implementation) an activity (or at least the framework)
 +
would need to remember and pass through the resumed <code>version_id</code> in order
 +
to use the corresponding branch on save.

Revision as of 17:57, 2 June 2009

Time line

For reference, I've copied the timeline from the proposal.

2009-04-03
Application deadline
2009-04-12
Easter (sunday); UI mockup submitted for review by Design Team
2009-04-20
start of (university) term; announcement of accepted GSoC proposals
2009-05-10
submitted API draft for review by Development Team
2009-05-16
SugarCamp Europe 2009
2009-05-23
start of GSoC
2009-05-31
current code examined and understood; API, on-disk format and UI design chosen
2009-06-07
data store enhanced to be able to deal with versions (basic API)
2009-06-14
added (working) prev/next buttons to Journal details view
2009-06-21
added support for importing from existing data store
2009-06-28
added unit tests (and potentially regression tests), fixed all known bugs, submitted for review by Design Team
2009-07-06
GSoC midterm evaluation ("working and 90% done"); added indexing (e.g. using sqlite)
2009-07-13
code integrated upstream for increased exposure (testing!); started discussion on extended UI design (version tree etc.)
2009-07-25
end of (university) term
2009-08-10
end of GSoC
2009-10-31
Fedora 12 release; Sugar 0.86 release short time later?

Progress

2009-05-16

SugarCamp was great! I got to know a lot of the SugarLabs people - they're a cool bunch. :)

Time in general was too short to do anything more than getting to know each other, but Tomeu quickly showed me an old effort at introducing version support into data store that I didn't know about (both data store and Journal). It looks quite interesting API-wise (simply adds another, optional parameter called vid that can be used to request a specific version). Also had some time with Bernie and he offered to set up a host for VMs (for our build bots).

Unfortunately we also catched some virus in Paris, so I had to lay in bed for the next two weeks.

2009-06-01

Slowly getting up to speed again, diving a bit into data store code (both old and new) while fixing the build infrastructure (about the same time as we ran SugarCamp Gnome did some largish changes in jhbuild that broke our sugar-jhbuild).

Discussed some possible data store API changes with alsroot, but they didn't really interfere with my design and we decided to discuss them again after the version support is finished.

Tomeu had the idea of treating the current object_id (distinguishing between instances of an activity) as a combined instance and version identifier and introducing a new "super_object_id" that does what object_id does now. The advantage would be that activities could transparently access old versions. If we'd introduce a version_id in parallel to object_id (the naive approach taken by the old implementation) an activity (or at least the framework) would need to remember and pass through the resumed version_id in order to use the corresponding branch on save.

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Version_support_for_datastore/Progress&oldid=30157"