Version support for datastore/Progress
For reference, I've copied the timeline from the proposal.
- Application deadline
- Easter (sunday); UI mockup submitted for review by Design Team
- start of (university) term; announcement of accepted GSoC proposals
- submitted API draft for review by Development Team
- SugarCamp Europe 2009
- start of GSoC
- current code examined and understood; API, on-disk format and UI design chosen
- data store enhanced to be able to deal with versions (basic API)
- added (working) prev/next buttons to Journal details view
- added support for importing from existing data store
- added unit tests (and potentially regression tests), fixed all known bugs, submitted for review by Design Team
- GSoC midterm evaluation ("working and 90% done"); added indexing (e.g. using sqlite)
- code integrated upstream for increased exposure (testing!); started discussion on extended UI design (version tree etc.)
- end of (university) term
- end of GSoC
- Fedora 12 release; Sugar 0.86 release short time later?
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
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.
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
(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
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.